On 08/17/2018 06:35 AM, 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 :) > >>> 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. > I agree with both of those, but the counter-argument is that "virtio" already describes a transitional device like your proposal for virtio-0.9 (at least today), and it makes the versioned models less orthogonal. In the end, I could go either way... The problem I can see with the virtio-1.0 model name is that if management applications start putting that into their XML (even though "virtio" would yield a working guest), the guests will be unable to migrate to another machine that has the same version of qemu, but an older libvirt that doesn't understand the virtio-1.0 model number. If that's acceptable, then management apps can being always specifying the version for virtio whether it's old or new. If not, then they should continue to use plain "virtio" unless they specifically need to force virtio-0.9. An additional task for this is that I've noticed that libvirt's domain capabilities info only contains info for devices of type disk, graphics, video, and hostdev. So even if oVirt learns from libosinfo that a particular guest OS only supports virtio-0.9 netdevs (from libosinfo's POV this means that it shows support for "virtio-net, but not "virtio1.0-net", it currently has no way of determining if the version of libvirt it's working with supports the "virtio-0.9" model of an interface device (or the "virtio-1.0 model - see above). So we'll need to add sections to the domain capabilities info for all devices that have both virtio-0.9 and virtio-1.0 support (everything but gpu and input, right?) Is anything else needed (other than the code in the management apps) to make this workable? -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
