On 13.12.2017 09:41, Roman Kagan wrote: > 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. > General question, what about Microsoft Windows guests? -- Thanks, David / dhildenb
