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

[Markus Armbruster <armbru@redhat.com>]

Eduardo Habkost <ehabkost@redhat.com> 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.

>                                                               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 strenously disagree.  This is first and foremost about correcting a
design mistake we made.

>>                                    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.

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.