From mboxrd@z Thu Jan  1 00:00:00 1970
From: Roman Kagan <rkagan@virtuozzo.com>
Subject: Re: [PATCH 2/2] x86:kvm:hyperv: guest->host event signaling via
 eventfd
Date: Wed, 6 Dec 2017 20:32:07 +0300
Message-ID: <20171206173207.GI2265@rkaganb.sw.ru>
References: <20171204190044.14125-1-rkagan@virtuozzo.com>
 <20171204190044.14125-3-rkagan@virtuozzo.com>
 <87tvx3lw91.fsf@vitty.brq.redhat.com>
 <20171206170038.GH2265@rkaganb.sw.ru>
 <87d13rlr4s.fsf@vitty.brq.redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
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: Vitaly Kuznetsov <vkuznets@redhat.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mail-he1eur01hn0224.outbound.protection.outlook.com ([104.47.0.224]:37232
        "EHLO EUR01-HE1-obe.outbound.protection.outlook.com"
        rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP
        id S1751362AbdLFRcX (ORCPT <rfc822;kvm@vger.kernel.org>);
        Wed, 6 Dec 2017 12:32:23 -0500
Content-Disposition: inline
In-Reply-To: <87d13rlr4s.fsf@vitty.brq.redhat.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

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