* Daniel P. Berrangé (berra...@redhat.com) wrote: > On Tue, Feb 15, 2022 at 04:25:33PM +0000, Dr. David Alan Gilbert (git) wrote: > > From: "Dr. David Alan Gilbert" <dgilb...@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 / dgilb...@redhat.com / Manchester, UK
