On Wed, Aug 22, 2018 at 12:36:27PM +0200, Andrea Bolognani wrote: > On Tue, 2018-08-21 at 14:21 -0400, Laine Stump wrote: > > On 08/17/2018 06:35 AM, Andrea Bolognani wrote: > > > If we decide we want to explicitly spell out the options instead > > > of relying on QEMU changing behavior based on the slot type, which > > > is probably a good idea anyway, I think we should have > > > > > > virtio-0.9 => disable-legacy=no,disable-modern=no > > > virtio-1.0 => disable-legacy=yes,disable-modern=no > > > > > > There's basically no reason to have a device legacy-only rather > > > than transitional, and spelling out both options instead of only > > > one of them just seems more robust. > > > > I agree with both of those, but the counter-argument is that "virtio" > > already describes a transitional device like your proposal for > > virtio-0.9 (at least today), and it makes the versioned models less > > orthogonal. In the end, I could go either way... > > Yeah, Dan already made that argument and convinced me that we > should use virtio-0.9 for legacy only, virtio-1.0 for modern only > and plain virtio for no enforced behavior / transitional. I don't understand why we are optimizing the new system for the less useful use cases: I don't see a use case where virtio-0.9 (legacy-only) would be more useful than virtio-transitional. I don't see why anybody would prefer a legacy-only device instead of a transitional device. Even if your guest has only legacy drivers, it might be upgraded and get new drivers in the future. I don't see a use case where virtio-1.0 (modern-only) would be more useful than "virtio". If you are running i440fx, you get a transitional device with "virtio", and I don't see why anybody would prefer a modern-only device. If you are running Q35, you already get a modern-only device with "virtio". The most useful feature users need is the ability to ask for a transitional virtio device on Q35, and this use case is explicitly being left out of the proposal. Why? -- Eduardo -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
