On Wed, Dec 06, 2017 at 04:19:22PM +0100, Vitaly Kuznetsov wrote: > Roman Kagan <rkagan@xxxxxxxxxxxxx> writes: > > > In Hyper-V, the fast guest->host notification mechanism is the > > SIGNAL_EVENT hypercall, with a single parameter of the connection ID to > > signal. > > (I may be missing something important...) > > I'm not sure how Windows does that but Linux Hyper-V drivers use > hard-coded VMBUS_EVENT_CONNECTION_ID (2) for all HVCALL_SIGNAL_EVENT > hypercalls. This is only true for VMBus protocol of w2008, where all channels use the same connection id, and use an additional "interrupt page" to sort out whose notification it is. Newer VMBus uses "dedicated interrupt" per channel, and Linux certainly does use that, too, if the hypervisor offers it. See vmbus_set_event(). > According to the spec, this id comes from HvConnectPort > hypercall which is executed by the root partition -- not sure how it's > supposed to be passed down to the guest. It comes in the channel offer. See vmbus_onoffer(). > So in case the situation in Windows is not any different the connection > ID parameter will always be 2 so we may as well just omit it) It is not different in Windows: the connection id varies there too. > Or, > alternatively, we can probably add both VMBUS_MESSAGE_CONNECTION_ID and > VMBUS_MONITOR_CONNECTION_ID to the mechanism... These two are not used with the SIGNAL_EVENT hypercall. Or are you suggesting to also handle the POST_MESSAGE hypercall in KVM? I don't see a compelling reason to do so, since this is a slow control mechanism and only used at setup/teardown, so handling it in userspace is good enough. Thanks, Roman.
