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.