Re: [libvirt] [Qemu-devel] clean/simple Q35 support in libvirt+QEMU for guest OSes that don't support virtio-1.0
On Fri, Aug 17, 2018 at 12:35:11PM +0200, Andrea Bolognani wrote:
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 :)
I mean from an upstream POV we still support RHEL-6 fine in i440fx,
so there's no reason to particularly care about RHEL-6 with q35
upstream. It is only downstream decision to try to force it to
use q35, despite it not working right today.
> > 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.
From a testing POV it is desirable to be able to have legacy-only.
There is also possibility that guest OS impl 1.0 in a buggy manner,
so forcing legacy only is desirable.
The existing device still already provides a transitional option
on i440fx, and on Q35 if you do explicit placement in a PCI slot.
So I don't think there's a good reason to have a second transitional
device type, especially if we're naming it virtio-0.9, it is rather
misleading if it would be in fact able to run virtio-1.0 mode.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|