Re: [PATCH 2/2] x86:kvm:hyperv: guest->host event signaling via eventfd

[Vitaly Kuznetsov <vkuznets@redhat.com>]

Roman Kagan <rkagan@virtuozzo.com> writes:

> On Wed, Dec 06, 2017 at 04:19:22PM +0100, Vitaly Kuznetsov wrote:
>> Roman Kagan <rkagan@virtuozzo.com> 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