[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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 redhat com> 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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]