Re: [Qemu-devel] [PATCH] virtio: Provide version-specific variants of virtio PCI devices

[Andrea Bolognani]

On Wed, 2018-10-17 at 12:01 -0300, Eduardo Habkost wrote:
> On Wed, Oct 17, 2018 at 12:43:02PM +0200, Andrea Bolognani wrote:
> > The proposal doesn't directly address the interaction between virtio
> > protocol version and slot type. [...]
> 
> It does.  See the interface names added to each device type.

Sorry, I might be blind but I'm still not seeing it... I see a bunch
of *-pci devices and exactly zero *-pcie devices. See below.

[...]
> The difference between the devices is not just the bus type: it
> is a different type of device with different behavior.  Using the
> bus type to differentiate them would be misleading.

I'm not arguing that we should use the bus type *only* to
differentiate them, but rather that we should *also* differentiate
them by bus type; failing to do so will mean that...

> e.g. both modern and transitional virtio devices can be plugged
> to Conventional PCI buses, but they have different PCI IDs.

... even people who should be very familiar with the topic by now,
like you and me, will get it wrong from time to time, as Michael
helpfully pointed out ;)

> I'm considering doing this in v2:
> 
> * Remove the -0.9 device type, because nobody seems to need it
> * Add two device types:
>   * virtio-1-blk-pci-non-transitional
>   * virtio-1-blk-pci-transitional
> 
> This way, we:
> * Include only the major version of the spec (so
>   we don't require new device types for virtio 1.1, 1.2, etc),
> * Use terms that come from the Virtio spec itself, to avoid
>   ambiguity.

That's quite a mouthful :)

Anyway, whether a device or not is transitional should go next to
the spec version rather than at the end: this will also help with
consistency because we will need -device and -ccw variants of all
these, no?

Can we assume if and when virtio 2.0 comes around it will also have
both a pure variant and a transitional one which is compatible with
virtio 1.0? If so, I would suggest the names should be

  virtio-1-blk-pcie               (1.x only,     PCIe slot)
  virtio-1-transitional-blk-pci   (transitional, PCI  slot)
  virtio-1-transitional-blk-pcie  (transitional, PCIe slot)

[...]
> > At the same time, we should not fool ourselves into thinking it will
> > take less than *years* before applications such as virt-manager can
> > actually take advantage of the new devices without compromising their
> > support for old libvirt and QEMU versions too much.
> > 
> > So if we're doing this to rectify some questionable design choices
> > with the goal of having a better situation in the long run, then by
> > all means we should go ahead; but if we think this will allow us to
> > run RHEL 6 on q35 in the short term, then our efforts are probably
> > misguided.
> 
> Good point.  You might be right about oVirt and OpenStack, but
> I'm assuming at least some applications (maybe KubeVirt?) don't
> care about supporting old libvirt/QEMU versions and won't have
> that problem.

AFAIK oVirt and OpenStack have been bumping their requirements quite
aggressively with each subsequent release, so it might not take them
that much time to catch up; I was thinking more about applications
like virt-manager, gnome-boxes and libguestfs, which historically
have maintained compatibility with old libvirt/QEMU releases for the
longest time.

-- 
Andrea Bolognani / Red Hat / Virtualization