On Wed, Jan 16, 2019 at 12:45:43PM -0200, Eduardo Habkost wrote: > On Wed, Jan 16, 2019 at 02:37:22PM +0000, Daniel P. Berrangé wrote: > > On Wed, Jan 16, 2019 at 03:31:49PM +0100, Andrea Bolognani wrote: > > > On Wed, 2019-01-16 at 12:44 +0000, Daniel P. Berrangé wrote: > > > > On Wed, Jan 16, 2019 at 01:29:13PM +0100, Andrea Bolognani wrote: > > > > > On Wed, 2019-01-16 at 11:39 +0000, Daniel P. Berrangé wrote: > > > > > > In the > > > > > > future they may add properties to, or change the defaults on, the > > > > > > -transitional or -non-transitional devices only, associated with > > > > > > new machine type versions. If libvirt forever uses the old devices, > > > > > > then we loose ability to take advantage of that. > > > > > > > > > > Regardless of what libvirt ends up doing, from the QEMU user point > > > > > of view I think it would be very surprising if eg. virtio-blk-pci > > > > > plugged into a PCIe slot behaved differently from > > > > > virtio-blk-pci-non-transitional plugged into the very same slot, or > > > > > if virtio-net-pci,disable-legacy=false,disable-modern=false behaved > > > > > differently from virtio-net-pci-transitional regardless of the slot > > > > > it's plugged into, so moving away from that consistency should be a > > > > > non-goal IMHO. > > > > > > > > [...] > > > > > > > > In this message Eduardo said virtio-blk-pci,disable-legacy and > > > > virtio-blk-pci-non-transitional are only compatible with the > > > > pc-4.0 machine types and earlier. There's no compat guarantee > > > > of compat for future machine types: > > > > > > > > https://lists.gnu.org/archive/html/qemu-devel/2018-11/msg03762.html > > > > > > > > If we didn't use the new QEMU device models right now, we could end > > > > up trapped forever. The safe futureproof approach is to always use > > > > the new devices models if available, and use disable-legacy for old > > > > QEMU versions only, which we know will have old machine types for > > > > which the compat guarantee is available. > > > > > > Well, let's see if Eduardo is willing to reconsider the policy on > > > compatibility between virtio-*-pci-{,non-}transitional and plain > > > virtio-*-pci going forward based on the principle-of-least-surprise > > > rationale outlined above :) > > > > I think we should use the new devices no matter what. Libvirt generally > > always strives to follow the latest QEMU best practice, even when new & > > old way of doing something are functionally identical. Eventually we > > would drop support for QEU < 4.0 and the old way would go away entirely. > > It would also allow us to deprecate the old devices, which would > be welcome. Always using the new devices when available would be > my recommendation. I don't really see QEMU upstream deprecating the old devices any time. There is sooooo much documentation that refers to them that will never be fixed. 99% of users won't get any benefit from using the new devices either, so there's no compelling reason to update their existing configs or docs. They're not going to be a huge maint burden to QEMU devs either given its just a toggle of a few props. I might see a downstream distro deprecating them at some point though, since they have a much tighter controlled usage scenario than upstream. > But I don't want to create unnecessary obstacles for libvirt, so > if there's a real benefit in promising compatibility between both > device types, we can still promise that on the QEMU side. I don't think there's an obstacle for libvirt, as I don't see any compelling reason to avoid the new devices when we have QEMU >= 4.0. > Breaking compatibility on purpose is very unlikely, and the most > likely accidents could be detected by > tests/acceptance/virtio_version.py. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
