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