On Wed, 2019-01-16 at 11:39 +0000, Daniel P. Berrangé wrote: > On Wed, Jan 16, 2019 at 12:31:04PM +0100, Andrea Bolognani wrote: > > On Tue, 2019-01-15 at 16:56 +0000, Daniel P. Berrangé wrote: > > > A transitional device is 100% identical to the existing device > > > types, so we can simply not add the "-transitional" suffix for > > > old QEMU. The only difference is the way libvirt does PCI bus > > > placement of the transitional device - we'd never use PCIe. > > > > > > A non-transitional device is identical to the existing device > > > types, but with disable-legacy=true set. > > > > Again, the relationship between existing and new devices is not > > quite this straighforward because of the reasons I outlined in > > > > https://www.redhat.com/archives/libvir-list/2019-January/msg00514.html > > When told to use virtio-transitional for a device, libvirt would > only plug it into a PCI slot, never a PCI-X slot. Given this > constraint, it is functionally identical / interchangable with > the existing device. Right, but you didn't spell out the constraint the first time around, thus making your (broader) statement that a "transitional device is 100% identical to the existing device" incorrect :) > > But the idea of using disable-{legacy,modern} instead of the new > > virtio-*-{non,}-transitional devices is one I had already suggested > > in > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1614127 > > > > so I'm obviously on board with it :) > > > > > QEMU guarantees this compatibility of the different devices, > > > but only for machine types < pc-i440fx-4.0.0 / pc-q35-4.0.0. > > > So we should none the less make sure we use the modern device > > > names for any QEMU which genuinely supports them. > > > > As I already mentioned in the bug report linked above, I'm not > > quite convinced that's the case, and I don't see why we wouldn't > > just use the options and basically ignore the QEMU-level devices, > > as the former approach would work on old QEMU releases as well as > > recent ones with no drawback I can think of. > > The QEMU maintainers were against the idea of us doing that. I don't recall any QEMU developer specifically saying that, but that might be just a case of my memory sucking :) CC'ing Eduardo so he can weigh in. > 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. > Indeed if QEMU maintainers wanted us to use the disable-legacy/modern > features long term, there would be no point in them even adding the > new device types in the first place. Yeah, after commenting on the bug report mentioned above I indeed started thinking that we could have gotten away with not adding those devices. They might still be useful to people running QEMU directly, though. > We should only ever use the disable- flags if the new devices do > not exist in QEMU. Wouldn't that potentially cause issues when migrating from QEMU < 4.0.0, where we'd use disable-*, to QEMU >= 4.0.0, where we'd use *-{,non}transitional instead? I guess not if the changes in device behavior are gated by the machine type version. -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
