Re: [libvirt] [PATCH for-4.0 v2] virtio: Provide version-specific variants of virtio PCI devices

On Mon, 2018-11-19 at 14:14 -0500, Michael S. Tsirkin wrote: > On Mon, Nov 19, 2018 at 07:56:38PM +0100, Cornelia Huck wrote: > > On Mon, 19 Nov 2018 13:42:58 -0500 "Michael S. Tsirkin" <mst(a)redhat.com&gt; wrote: > > > We have this assumption that if we force a choice then people will > > > choose the right thing but in practice they will do what we all do, play > > > with it until it kind of works and leave well alone afterwards. > > > That's at best - at worst give up and use an easier tool. > > > > That implies that we (the developers) need to care and make sure that > > "model=virtio" gets them the best possible transport (i.e. on s390x, > > that would be ccw unless the user explicitly requests pci; I'm not sure > > what the situation with mmio is -- probably "use pci whenever > > possible"?) I think that's what libvirt already gives us today (I hope.) The interface at the libvirt level is exactly "model=virtio", with that ultimately translating to virtio-*-pci or virtio-*-ccw or virtio-*-device or whatever else based on the architecture, machine type and other information about the guest. > > What makes it messy on the pci side is that the "best option" actually > > depends on what kind of guest the user wants to run (if the guest is > > too old, you're stuck with transitional; if you want to reap the > > benefits of PCIe, you need non-transitional...) > > Well it works now - connect it to a bus and it figures out whether it > should do transitional or not. You can force transitional in PCIe anyway > but then you are limited to about 15 devices - probably sufficient for > most people ... That's not how it works, though: current virtio-*-pci devices will be transitional (and thus support older guest OS) or not based on the kind of slot you plug them into. >From the management point of view that's problematic, because libvirt (which takes care of the virtual hardware, including assigning PCI addresses to devices) has no knowledge of the guest OS running on said hardware, and management apps (which know about the guest OS and can figure out its capabilities using libosinfo) don't want to be in the business of assigning PCI addresses themselves. Having separate transitional and non-transitional variants solves the issue because now management apps can query libosinfo to figure out whether the guest OS supports non-transitional virtio devices, and based on that they can ask libvirt to use either the transitional or non-transitional variant; from that, libvirt will be able to choose the correct slot for the device. None of the above quite works if we have a single variant that morphs based on the slot, as we have today.

-- Andrea Bolognani / Red Hat / Virtualization