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 :) -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
