Re: [libvirt] [Qemu-devel] clean/simple Q35 support in libvirt+QEMU for guest OSes that don't support virtio-1.0

Eduardo Habkost <ehabkost(a)redhat.com&gt; writes: > 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, Every time we make -device FOO result in a different device depending on context, device configuration or placement, it eventually joins our collection of Very Bad Ideas. Different PCI device IDs are a clear indicator of device difference. Instances of this class of Very Bad Ideas I've addressed myself: * I deprecated "ivshmem" in favor of "ivshmem-plain" and "ivshmem-doorbell". * I split "ide-drive" into of "ide-hd" and "ide-cd" (deprecation wasn't fashionable back then) * I split "scsi-disk" into "scsi-hd" and "scsi-cd" (likewise) One time pain, long term gain.

We should consider addressing virtio devices, too: deprecate the chameleon device models an adequate grace period.

>> 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 strenously disagree. This is first and foremost about correcting a design mistake we made. > 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. I would be willing to listen a reasoned argument why correcting the design mistake is not worthwhile. I'm unwilling to listen to more downstream blaming. Please stop it.