From mboxrd@z Thu Jan  1 00:00:00 1970
From: Vitaly Kuznetsov <vkuznets@redhat.com>
Subject: Re: [PATCH 2/2] x86:kvm:hyperv: guest->host event signaling via eventfd
Date: Wed, 06 Dec 2017 18:09:55 +0100
Message-ID: <87d13rlr4s.fsf@vitty.brq.redhat.com>
References: <20171204190044.14125-1-rkagan@virtuozzo.com>
        <20171204190044.14125-3-rkagan@virtuozzo.com>
        <87tvx3lw91.fsf@vitty.brq.redhat.com>
        <20171206170038.GH2265@rkaganb.sw.ru>
Mime-Version: 1.0
Content-Type: text/plain
Cc: kvm@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>,
        Radim =?utf-8?B?S3LEjW3DocWZ?= <rkrcmar@redhat.com>,
        "Denis V. Lunev" <den@openvz.org>
To: Roman Kagan <rkagan@virtuozzo.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mx1.redhat.com ([209.132.183.28]:53810 "EHLO mx1.redhat.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1752274AbdLFRJ6 (ORCPT <rfc822;kvm@vger.kernel.org>);
        Wed, 6 Dec 2017 12:09:58 -0500
In-Reply-To: <20171206170038.GH2265@rkaganb.sw.ru> (Roman Kagan's message of
        "Wed, 6 Dec 2017 20:00:39 +0300")
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

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