Roman Kagan <rkagan@xxxxxxxxxxxxx> writes: > 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(). > Ah, right, thanks! > >> 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. Yes, it is good enough but the new mechanism's name look generic enough: KVM_HYPERV_EVENTFD and it is unclear why only SIGNAL_EVENT is handled. -- Vitaly
