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

[Eduardo Habkost]

On Wed, Aug 22, 2018 at 03:57:20PM +0100, Daniel P. Berrangé wrote:
> On Wed, Aug 22, 2018 at 11:18:28AM -0300, Eduardo Habkost wrote:
> > On Wed, Aug 22, 2018 at 02:44:40PM +0100, Daniel P. Berrangé wrote:
[...]
> > > An explicit virtio-transitional device is still two separate
> > > devices pretending to be the same thing, but magically changing
> > > their identity at runtime. We've already got that situation with
> > > existing device models, and I'm loathe to see us add 2nd device
> > > model with that same behaviour, just for sake of having a slightly
> > > different PCI bus placement strategy to support outdated guest OS.
> > 
> > Your seem to be describing what the current "virtio" device is:
> > it becomes a non-transitional (modern-only) Virtio device on some
> > cases, and becomes a transitional Virtio device on other cases.
> > It is two devices pretending to be the same thing.  That's
> > exactly what I would like applications to get rid of.
> > 
> > Now, the above is really not an accurate description of
> > transitional Virtio devices.  A transitional Virtio device is
> > something clearly specified in the Virtio spec, and it just means
> > a device that supports two types of drivers.  It's not different
> > from a x86_64 CPU that can run 32-bit OSes.
> > 
> > See:
> > http://docs.oasis-open.org/virtio/virtio/v1.0/cs04/virtio-v1.0-cs04.html#x1-60001
> > http://docs.oasis-open.org/virtio/virtio/v1.0/cs04/virtio-v1.0-cs04.html#x1-3090004
> 
> When I say a device pretending to be 2 different devices, I'm
> generally referring to the fact that a single QEMU device model
> can expose two different PCI device IDs depending on how it is
> configured and/or placed.

Understood.  Then you are not describing transitional Virtio, you
are just describing QEMU's disable-legacy=auto behavior (which is
the default).


> 
> > > > > 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.
> > > 
> > > Even if someone is willing to implement it in libvirt, we have to
> > > consider the cost of supporting it in both libvirt and applications
> > > using libvirt and the complexity it adds to our story about the
> > > docs / best practices for configuring guests.
> > > 
> > > Even though I do kind of like the virtio-0.9/virtio-1.0 device model
> > > as concepts, I'm yet to be convinced that implementing them in libvirt
> > > and then also in all the downstream applications (oVirt, OpenStack,
> > > virt-manager, cockpit, etc) is actually worth the cost.
> > > 
> > > There's little compelling reason to care about running outdated OS
> > > like RHEL-6 on Q35 in general. The motivation behind it is just
> > > coming from an artifically created problem downstream, by wishing
> > > to drop the i440fx machine at some still undeteremined point in the
> > > future. By the time that future comes, RHEL-6 may well even be
> > > end of life making the entire exercise a pointless.
> > 
> > I'm all for making a cost/benefit analysis, but I don't think you
> > are taking into account the costs of keeping the confusing
> > semantics of existing "virtio" devices.
> > 
> > If you still want to refuse to provide a sane way to configure
> > transitional Virtio devices, I really won't care.  But I believe
> > the interface you are trying to keep is actually the one you are
> > criticizing ("two separate devices pretending to be the same
> > thing, but magically changing their identity at runtime").
> 
> Yeah, I guess I should make a distinction between what I would
> do if it was a clean slate, and what we should do given our existing
> practice.
> 
> If we had a clean slate I would not like to see our current impl
> done.  Given that it already exists, however, we're stuck with
> that forever. So the question is whether implementing any of
> the alternative options is a net benefit for libvirt & mgmt apps
> overall. My gut feeling is that despite the downsides of the
> current impl, it is not worth trying todo something different.

Fair enough.

> 
> The thing that has really tipped my mind this way is that even
> if we provide new device models, mgmt apps will be loathe to
> actually use them because it will prevent live migration of
> those guests to hosts with older libvirt.

This might be an issue for some apps, but is it going to happen
in practice?  Don't they all need mechanisms to flip a switch and
enable features that require newer host software, already?

> 
> So my feeling is we should do the work to enable use of Q35
> by default in mgmt apps, for guest OS where it is known to
> work correctly today. Every other OS should just stick with
> i440fx as we already know that works for them today and Q35
> doesn't offer legacy OS compelling enough benefits to switch.

I'd still prefer if libvirt provided a saner configuration
mechanism, and let libosinfo and management apps decide what
works best for them.

If it helps, I can send QEMU patches to make
virtio-0.9/virtio-1.0-non-transitional/virtio-1.0-transitional
appear as different device types.  libvirt would then be able to
check if the device type implements "pci-express-device" or
"conventional-pci-device", instead of adding device-specific
placement logic.

-- 
Eduardo