Re: [libvirt] [Qemu-devel] clean/simple Q35 support in libvirt+QEMU for guest OSes that don't support virtio-1.0
On Fri, 2018-08-17 at 10:29 +0100, Daniel P. Berrangé wrote:
On Thu, Aug 16, 2018 at 06:20:29PM -0400, Laine Stump wrote:
> 5) Some guest OSes that we still want to support (and which would
> otherwise work okay on a Q35 virtual machine) have virtio drivers too
> old to support virtio-1.0 (CentOS6 and RHEL6 are examples of such OSes),
> but due to the chain of reasons listed above, the "standard" config for
> a Q35 guest generated by libvirt doesn't support virtio-0.9, hence
> doesn't support these guest OSes.
Note when talking about "support" you're really saying it from the
downstream vendor, specifically RHEL, POV. From upstream or Fedora POV
essentially all x86 OS ever made are in scope for running under QEMU
if suitable virtual hardware models have been provided. QEMU doesn't
maintain any whitelist of "supported" OS that differs from what is
technically capable of being run, in the way downstream vendors do.
Well, at least in the case of RHEL 6, "not supported" means that it
will not boot at all on q35 with the default guest topology created
by libvirt, so that's not really a downstream-only problem :)
> a) we don't really need the virtio-1.0 model, since
that's what you
> currently get anyway when you ask for "virtio" on Q35 (and on 440fx,
> "virtio" gives you transitional, which works for everybody).
At some point we might have a virtio-2.0 and find ourselves in a
similar problem again. IMHO it is preferrable to have both explicit
versioned models, and discourage use of the magical 'virtio' model from
mgmt apps. Use libosinfo to identify which virtio model is supported
for the OS in question and use that explicitly. Only use the magical
'virtio' model if there's no information about what version the OS
supports.
Agreed.
> c) Even if it's possible to force a device on an Express
slot into
> transitional mode, this is extremely wasteful of io port space, so
> libvirt should consider virtio-0.9 devices to be legacy PCI, and thus
> plug them into legacy PCI slots. And once we're doing this, it's
> unnecessary to add any extra option to the qemu commandline to force
> legacy support (i.e. transitional mode), as that is what QEMU already
> does when the device is connected to a legacy PCI slot.
Yes, it should plug them into legacy PCI slots by default, but if a
mgmt app has done explicit placement itself, it should honour that
even if it means wasting IO space.
This is consistent with what already happens with PCI addresses: a
PCIe device will never be assigned to a PCI slot automatically, but
the user can still force that to happen by providing the PCI address
themselves.
> C) inside libvirt, the implementation of the
"virtio-0.9" model is
> identical to "virtio", except that the VIR_PCI_CONNECT_TYPE flags for
> these devices contain VIR_PCI_CONNECT_TYPE_PCI rather than
> VIR_PCI_CONNECT_TYPE_PCIE, resulting in those devices being assigned to
> a legacy PCI slot, and thus they would be transitional mode by default.
For 'virtio-0.9' libvirt should set "disable-modern=yes" in QEMU args
For 'virtio-1.0' libvirt should set "disable-legacy=yes" in QEMU args
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.
--
Andrea Bolognani / Red Hat / Virtualization