On Wed, Aug 22, 2018 at 01:26:01PM +0100, Daniel P. Berrangé wrote:
On Wed, Aug 22, 2018 at 09:01:35AM -0300, Eduardo Habkost wrote:
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?
You can already get a transitional device on Q35, albeit with manual placement. Adding flags for magic placement for the existing devices is not something that is suitable for the XML. The ability to get legacy-only, or modern-only doesn't exist today in any way, so that would be a valid new feature.
Transitional devices and modern-only devices are different kinds of devices. Making the guest see a different type of device depending on where it's plugged is why we got into this mess, why would we recommend applications to rely on this behavior? That's why I like your virtio-0.9/virtio-1.0 proposal. I just don't see why you think virtio-transitional should be out of it.
Honestly though, the longer this discussion goes on, the more I think the answer is just "do nothing". All this time spent on discussion, and future time spent on implementing new logic in apps, is merely to support running RHEL-6 on Q35. I think we should just say that RHEL-6 should use i440fx forever and be done with it.
I'm not sure if you are saying that we (Red Hat) shouldn't spend time implementing it, or that the libvirt upstream project should reject the patches if somebody implements it. I would understand the former, but not the latter. -- Eduardo