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.
