On Wed, Dec 06, 2017 at 06:09:55PM +0100, Vitaly Kuznetsov wrote: > Roman Kagan <rkagan@xxxxxxxxxxxxx> writes: > > On Wed, Dec 06, 2017 at 04:19:22PM +0100, Vitaly Kuznetsov wrote: > >> 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. Because SIGNAL_EVENT matches the eventfd semantics while POST_MESSAGE doesn't. Because POST_MESSAGE is, well, about posting messages. It bears up to 256 bytes of data which need to be copyied aside before returning to the guest and then delivered somehow to the userspace for processing. Roman.
