PR 211000 was reported (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211000) to track the patch.

Please use the new version of the fix: https://reviews.freebsd.org/D5778

removed the unnecessary braces as kib suggested.

I improved the patch as kib suggested.

In D5739#122559, @kib wrote:

The idea is correct, but implementation is arguably not. TUNABLE_XXX_FETCH() keeps the variable unchanged if the env var is not present. The correct logic would be

textmode = vm_guest != VM_GUEST_NO;
TUNABLE_INT_FETCH("hw.vga.textmode", &textmode);

This would give the desired behaviour of enabling textmode by default for guests only, but also allowing user to override it as she wants.

I made a new patch according to kib's suggestion:
https://reviews.freebsd.org/D5739

In D5727#122540, @kib wrote:

In D5727#122488, @sepherosa_gmail.com wrote:

Hmm, will it be too late? :) I am not sure whether the vm_guest is set or not there. If it is not set there yet, maybe we can factor out the VM guest detection code give it an MI API and use it in the vga_init().

I really hope that it is not. identcpu() is performed very early since some other fundamental parts of the kernel startup, like initial page tables configuration, depend on the identified CPU features. But I did not verified the order for vt_vga.

In D5727#122354, @kib wrote:

In D5727#122342, @decui_microsoft.com wrote:

In D5727#122322, @royger wrote:

It's been some time since I've tested this on Xen, but there was a difference between using hw.vga.textmode or not. It's not like 1 line per second, but it used to be noticeable.

Can you please confirm Xen also conforms to "CPUID(EAX==1).ECX.bit31 == 1" ? I can update my patch to cover all the hypervisors conforming to this?

See identify_hypervisor() in x86/identcpu.c.

Wouldn't it be less hackish to make the decision in vt_vga.c:vga_init() in kernel, without creating fake kenv var ?

Yes, that may be less hackish.

a small coding style change -- use brace for the return value of running_on_hypervisor()

In D5727#122322, @royger wrote:

It's been some time since I've tested this on Xen, but there was a difference between using hw.vga.textmode or not. It's not like 1 line per second, but it used to be noticeable.

In D5727#122310, @royger wrote:

Hm, it might we worth to do this for all hypervisors and not only HyperV, this can be easily done by checking the hypervisor bit in CPUID.

fix tab/space indentation and function declaration's style.

In D5715#122002, @sepherosa_gmail.com wrote:

In D5715#122001, @howard0su_gmail.com wrote:

In D5715#121996, @sepherosa_gmail.com wrote:

Yeah, the more NICs you have the higher chance you got this panic.

My worry is, now that the code sleeps in the globally shared taskqueue_thread. I'd suggest to create two vmbus taskqueues, instead of sharing the global taskqueue_fast/taskqueue_thread. Though that should be done in another patch.

You can not sleep on taskqueue_fast, so only the places on taskqueue_thread need change.

I'd prefer to have our own taskqueues for the mgmt stuffs, i.e. the msg and channel offers, so we could do malloc(WAITOK) and sleep as we wish.

LGTM

LGTM

I'm Ok without the KASSERT.

Add const and KASSERT too?
Just to make sure people can't pass a too small buf size by mistake (the exact buf size needed here is 37).

LGTM

LGTM

In D5254#120056, @howard0su_gmail.com wrote:

Shall we commit this without changing the IDT name?

LGTM

I'm afraid atomic_thread_fence_seq_cst() here has a potential issue in the case of UP kernel: it is downgraded to a compiler barrier only, which is incorrect here, because the shared memory here is between the host virtual CPU and the UP guest virtual CPU -- at least 2 CPUs are involved (we assume the guest/host virtual CPUs are running on different physical CPUs)

LGTM

LGTM

In D4802#105424, @sepherosa_gmail.com wrote:

Looks fine to me. Though I have some questions about the channel accessing w/o lock/refcnt.

Yeah, there is an issue when (a device is being hot-removed, or the driver is being unloaded) AND there is a pending event in the channel.

LGTM

LGTM

LGTM

In D4814#103342, @royger wrote:

I don't mind committing this, but is it really worth it? I mean, with 16MB you are always on the safe side, and it's not like 1MB of memory is a huge deal this days...

LGTM.

Please goto https://reviews.freebsd.org/D4852 for the new version.

looks good to me.

In VmbusProcessChannelEvent(), hv_vmbus_g_connection.channels[relid] still lacks the necessary protection, and in vmbus_channel_on_offer_rescind(), hv_vmbus_g_connection.channels[relid] is not reset to NULL, but I think we can address these in another patch.

hv_vmbus_g_connection.channels = malloc(sizeof(unsigned long) * HV_CHANNEL_MAX_COUNT,

sizeof(unsigned long) should be sizeof(hv_vmbus_channel *).

Looks good to me.

The patch is good to me.

Hi Xin, Thanks for committing this patch!

In D4596#99078, @royger wrote:

I've also realized that you are registering the software interrupts without the INTR_MPSAFE flag (see line ~498 of hv_vmbus_drv_freebsd.c), which means that vmbus_msg_swintr will never run concurrently on different CPUs, is this intended?

In D4596#99078, @royger wrote:

LGTM (although I know nothing about HyperV internals).

AFAICT from your description, you cannot run the handlers from vmbus_msg_swintr because some of them expect a reply, and this reply won't be delivered because the previous message hasn't been marked as 'done'. Is there any reason why you don't simply copy the message, mark it as done and then launch the handler from vmbus_msg_swintr?

In D4595#99073, @royger wrote:

LGTM. This made me wonder, is there some kind of canonical source for the HyperV headers? Or it's mostly ad-hoc for each OS?

Thanks for reviewing the patch. I don't know about such a source. Xin Li should know the history of the drivers better than me.

In D4595#99077, @royger wrote:

Forgot to mention, on FreeBSD you don't have to add a Signed-off-by tag to commit messages.

In D4611#99051, @howard0su_gmail.com wrote:

Please check hv_rf_receive_indicate_status in hv_rndis_filter.c, which has callback from hypervisor about media status. i believe we need integrate with this change so that we can report the correct status

And we need use something like EARLY_DRIVER_MODULE to make sure hyper-v timer is used as the default event timer, when the VM is running on Hyper-V.

Please goto https://reviews.freebsd.org/D4676 for the new version of the patch.

Bascially the patch seems good to me.

In D4258#93899, @royger wrote:

In D4258#93148, @decui_microsoft.com wrote:

In D4258#93144, @royger wrote:

AFAICT I think you are missing a:

seldrain(&hv_kvp_selinfo);

In hv_kvp_dev_close before setting kvp_globals.dev_accessed = false.

Why? At most only 1 daemon is expected to open the dev file /dev/hv_kvp_dev. When the daemon is invoking close() and the execution enters the kernel funntion hv_kvp_dev_close(), we know the daemon is running, so I don't think we need to wake the daemon up?

Sorry for the delay, yesterday was a public holiday here. I agree that you make a special use of this device, so there's no risk in avoiding the seldrain in the close routine (because hv_kvp_selinfo is not going to be freed).

The same applies to hv_kvp_dev_destroy AFAICT, since you kill the thread and don't free the hv_kvp_selinfo struct there's no risk.

Roger.

Thanks a lot for the explanation, Roger!

In D4258#93148, @decui_microsoft.com wrote:

In D4258#93144, @royger wrote:

AFAICT I think you are missing a:

seldrain(&hv_kvp_selinfo);

In hv_kvp_dev_close before setting kvp_globals.dev_accessed = false.

Why? At most only 1 daemon is expected to open the dev file /dev/hv_kvp_dev. When the daemon is invoking close() and the execution enters the kernel funntion hv_kvp_dev_close(), we know the daemon is running, so I don't think we need to wake the daemon up?

Hi Roger, may I have your reply on this?

In D4258#93144, @royger wrote:

AFAICT I think you are missing a:

seldrain(&hv_kvp_selinfo);

In hv_kvp_dev_close before setting kvp_globals.dev_accessed = false.

Why? At most only 1 daemon is expected to open the dev file /dev/hv_kvp_dev. When the daemon is invoking close() and the execution enters the kernel funntion hv_kvp_dev_close(), we know the daemon is running, so I don't think we need to wake the daemon up?

The patch has been in the status of Accepted for 6 days, but I didn't see it appear in the head of the svn repository.