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@xxxxxxxxxx> 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@xxxxxxxxxx> 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
