On Wed, Dec 13, 2017 at 10:35:40AM +0100, David Hildenbrand wrote: > 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? Well, we haven't tried intercepting this hypercall in Windows guests on the real Hyper-V to see if they ever use non-zero flag number. On our implementation of VMBus in QEMU, based on the protocol deduced from the Linux guest drivers, the Windows guests abide by the same rules. At least it was enough to get VMBus scsi, network, and util devices working. Roman.
