Re: [PATCH 3/3] x86: Switch to q35 as the default machine type

[Dr. David Alan Gilbert]

* Daniel P. Berrangé (berrange@redhat.com) wrote:
> On Tue, Feb 15, 2022 at 04:25:33PM +0000, Dr. David Alan Gilbert (git) wrote:
> > From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
> > 
> > The 'q35' machine type series has been around for a few years now, and
> > is getting heavily used downstream without many problems;  lets flip
> > to using it as the default.
> 
> I don't think I'd claim 'without many problems'.  In RHEL while 'q35'
> is recommended, it explicitly isn't the default because it would havbe
> created compatibility problems for applications. Every non-trivial
> application needs to make code changes to cope with 'q35' if they're
> using 'i440fx' today.  Apps that Red Hat ships, either in RHEL or as
> add-on products, have been updated, but it was certainly not painfree
> and took considerable time for OpenStack at least. I worry about how
> ready the broader QEMU consumers are to work with 'q35' as an opt-in,
> let alone as a default.

How many of these consumers do all of:
  a) Don't specify the machine type
  b) and try and do hotplug etc

> PCI is the really big ticket item here. If keeping the same command
> line none of the PCI devices added will be hotpluggable because
> they'll all be put in the root complex as integrated end points,
> whether PCI or PCIe devices.
> 
> To allow for hot-unplug, any cold plugged PCIe devices need to be
> placed in unique pcie-root-port (one root port per device). The
> PCI devices meanwhile have to be put into a pci-bridge, which is
> in turn plugged into a pcie-to-pci-bridge.  QEMU doesn't do this
> placement by default so nothing is hot-unpluggable.
> 
> To allow for hot-plug, it is needed to pre-create many pcie-root-port
> devices - one for each device to be plugged.

I'm tempted to modify q35 to create a bunch of root ports by default
and then tweak the placement to pick them;  that would have no effect
on libvirt users but would make simple command line use easy again.

> Libvirt tried to make this a little easier by putting cold plugged
> devices into a place that allows them to be hot-unplugged.
> 
> On the libvirt side, there's also the need to know about sata vs
> ide. That ones fun because at the QEMU level we still refer to it
> as 'ide' throughout, even though q35 is implementing sata. 
> 
> There was one other notable difference that impacted apps, but I
> can't remember what it was offhand.

There be dragons, but I can't remember where :-)

> 
> > While it is of course newer and shinier than it's old i440fx cousin,
> > the main reasons are:
> 
> s/newer and shinier/slightly less ancient and obsolete/ ;-P
> 
> >   * PCIe support
> >   * No default floppy or IDE
> >   * More modern defaults for NIC
> >   * Better OVMF support
> 
> These are fine reasons for recommending apps to prefer use of 'q35'
> on an opt-in basis.
> 
> Given the semantic differences from 'i440fx', changing the default
> machine type has effects that are equivalent to breaking command
> line syntax compatibility, which is something we've always tried
> to avoid.

I'm not sure where to draw the line; it's always been legal for
new versions of machine types to have different slightly different
behaviour; for example it would be reasonable for a new version to use
up a PCIe bus slot/address that was previously unused and thus break
your command line that was trying to stuff another device in there.

To my mind, as long as -M pc  puts everything back the way it was, I
wasn't too worried about that breakage.

Dave

> 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 :|
> 
-- 
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK