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

[Eduardo Habkost]

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 at redhat.com> wrote:
> 
> > On Mon, Nov 19, 2018 at 07:32:38PM +0100, Cornelia Huck wrote:
> > > On Mon, 19 Nov 2018 13:07:59 -0500
> > > "Michael S. Tsirkin" <mst at redhat.com> wrote:
> 
> > > > And I strongly believe command line users really really do not want all
> > > > this mess. Even adding "pci" is the name confuses people (what are the
> > > > other options?). For command line model=virtio is pretty much perfect.  
> > > 
> > > I'd argue that it's problematic on platforms where you have different
> > > options for virtio transports. What does "model=virtio" mean? Always
> > > virtio-pci, if available? Or rather virtio-<transport>, with
> > > <transport> being the best option for the machine?  
> > 
> > Most people don't care, for them it's "whatever works".
> > 
> > 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.)
> 
> 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...)

Yeah, sometimes we can't make everything work out of the box on
the default case.  But I think in this case we can make the QEMU
command-line a bit more usable if we just cover more recent OSes.

However, I wish this kind of usability magic didn't automatically
imposed us the burden of keeping guest ABI compatibility too.
Keeping ABI compatibility on the machine-friendly device types and
interfaces is already hard enough.

We already have aliases that automatically select a virtio device
type at qdev-monitor.c:qdev_alias_table[], and I don't know if
they are supposed to keep a stable guest ABI.

-- 
Eduardo