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

[Michael S. Tsirkin]

On Wed, Oct 17, 2018 at 12:01:37PM -0300, Eduardo Habkost wrote:
> On Wed, Oct 17, 2018 at 12:43:02PM +0200, Andrea Bolognani wrote:
> > On Tue, 2018-10-16 at 15:12 -0400, Laine Stump wrote:
> > > On 10/16/2018 01:02 PM, Daniel P. Berrangé wrote:
> > > > On Mon, Oct 15, 2018 at 03:14:04PM -0300, Eduardo Habkost wrote:
> > > > How about using only the major digit in the device names eg
> > > > 
> > > >   'virtio-blk-0.x'
> > > >   'virtio-blk-1.x'
> > > > 
> > > > to make it clearer that we cover 1.0 and 1.1 (and 1.2, etc
> > > > by the same device.
> > > 
> > > +1 from me on either "-1" or "-1.x", and a -1 on "-1.0" or "-modern".
> > 
> > Agreed on using the major version number rather than a non-specific
> > string, and since the number refers to the virtio protocol version
> > I would expect the result to be
> > 
> >   virtio-0-blk-pci
> >   virtio-1-blk-pci
> > 
> > and so on.
> > 
> > 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.
> 
> 
> >                           [...] Admittedly, I don't recall all the
> > details myself, but the point is that I would like to see the slot
> > type mentioned explicitly in the device name to avoid confusion, so
> > the above might end up looking more like
> > 
> >   virtio-0-blk-pci
> >   virtio-1-blk-pci
> >   virtio-1-blk-pcie
> > 
> > details myself, but the point is that I would like to see the slot
> > type mentioned explicitly in the device name to avoid confusion, so
> > the above might end up looking more like
> > 
> >   virtio-0-blk-pci
> >   virtio-1-blk-pci
> >   virtio-1-blk-pcie
> > 
> > with the last one very clearly not being usable on i440fx. I might
> > have gotten some details wrong in the example, but you get the idea.
> 
> 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.
> 
> e.g. both modern and transitional virtio devices can be plugged
> to Conventional PCI buses, but they have different PCI IDs.
> 
> 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.

I'd say just drop "1" completely then.  E.g. transitional and legacy
have same ID's, differences are internal and not interesting to users.
If spec comes up with a new type of device it will come up with a new
term for it, I am sure.

> > 
> > [...]
> > > > Apps using the new device model names would either make themselves
> > > > incompatible with older libvirt/QEMU, or they would increase their
> > > > code complexity & testing matrix by having to support both old & new
> > > > names. The usage would also harm migration to older hosts.
> > > > 
> > > > This just to be able to switch from i440fx to q35 for OS which don't
> > > > support virtio-1.0, but for such old OS, q35 isn't offering any
> > > > compelling features, so they might as well stick with the thing that
> > > > is known to work well.
> > > 
> > > The *current* compelling reason is to permit management apps to use Q35
> > > for "old" OSes that don't have a driver for virtio-1.0, (and especially
> > > *new* management apps that want to support only Q35 from the start), but
> > > there are other future advantages that will make us appreciate that this
> > > was done. For example, libosinfo currently reports separately that an
> > > supports virtio-0.9 devices and/or virtio-1.0 devices, but a management
> > > app would need to have extra logic to take account of the fact that the
> > > only way to get a virtio-0.9 device would be to place it on a
> > > conventional PCI bus; if qemu offers the two as separate devices then
> > > all the management app has to do is use the device that libosinfo tells
> > > it to use, and it will automatically be placed on the right kind of bus.
> > > (and I've heard from Eduardo that eventually we'll be able to learn the
> > > PCI ID of the devices from qmp introspection, so the management app will
> > > be able to just look for a device ID that is on both the qemu and the OS
> > > list, and use that).
> > > 
> > > Obviously using these devices will make it impossible to migrate a guest
> > > that uses them to an older host that doesn't have "new" qemu + libvirt,
> > > but if that's important to a management app, then they can just do
> > > things in the more complicated manner needed by the "combined" virtio
> > > device variants. (Again, if a management app is just being
> > > designed/written now, it can assume these new devices from the start and
> > > ignore the older combined device).
> > > 
> > > In the end, having a device that changed PCI ID depending on what kind
> > > of slot it was plugged into was an idea "too clever for its own good",
> > > should be avoided when new devices are added in the future, and we
> > > should at least provide an alternative that doesn't do that for existing
> > > devices.
> > 
> > Agreed, the current situation is kind of a mess and taking steps
> > towards solving it will pay off in the long term.
> > 
> > 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.
> 
> -- 
> Eduardo