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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
