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

[Roman Kagan <rkagan@virtuozzo.com>]

On Tue, Dec 12, 2017 at 07:20:52PM +0100, David Hildenbrand wrote:
> On 12.12.2017 19:18, Roman Kagan wrote:
> > On Tue, Dec 12, 2017 at 05:29:02PM +0100, David Hildenbrand wrote:
> >> On 12.12.2017 17:22, Paolo Bonzini wrote:
> >>> On 12/12/2017 17:07, Roman Kagan wrote:
> >> (although it would be good to have another look at the hyperv specific
> >> conn_id handling)
> > 
> > Are you talking about this weird flag_no part of the hypercall parameter
> > which we add to the conn_id?
> > 
> > Yes this is something I'm not quite comfortable with: we've never seen
> > it being anything but 0, and Linux guest drivers ignore its existence
> > altogether (and there seem to be no fields in the vmbus protocol
> > structures to let the guest know of the allowed numbers there).
> > 
> > So I may be misinterpreting the spec; and it may be prudent just to
> > reject all flag_no != 0 hypercalls until we actually start seeing ones,
> > and then research how to handle them correctly.  What do you think?
> 
> Could be done, but if it isn't too much trouble, let's try to get it
> right from the beginning.
> 
> Can you point me at the spec so I can verify?

Sure.  The Hyper-V spec is

https://github.com/Microsoft/Virtualization-Documentation/raw/master/tlfs/Hypervisor%20Top%20Level%20Functional%20Specification%20v5.0b.pdf

Hope you can read Microsoftish better than me.  The relevant part is
chapter 11, "Inter-Partition Communication"; the hypercall itself is
described in "11.11.2 HvSignalEvent".

However, the VMBus guest drivers in Linux use only a limited subset of
those.  In particular, the concept of ports seems completely unused, the
connections appear pre-established, and the parent partition informs the
guest of the connection to signal for a specific channel via a u32 field
in the channel offer message.
(See drivers/hv/channel_mgmt.c:vmbus_onoffer for how the connection_id
from the offer is recorded, and drivers/hv/connection.c:vmbus_set_event
for how it's used for signaling.)

So I'm tempted to think this extra flag number is just the usual
overdesign, and I'd better require it to be zero.  This is certainly the
case for all the VMBus devices currently supported by the Linux guest
drivers, so we should be good with it too.

Roman.