[PATCH] deprecation: x86 default machine types

[Daniel P. Berrangé]

On Wed, Mar 02, 2022 at 07:38:52PM +0000, Dr. David Alan Gilbert wrote:
> * Daniel P. Berrangé (berrange at redhat.com) wrote:
> > On Tue, Mar 01, 2022 at 07:54:32PM +0000, Dr. David Alan Gilbert (git) wrote:
> > > From: "Dr. David Alan Gilbert" <dgilbert at redhat.com>
> > > 
> > > Declare the intent to require a machine type to be specified on x86
> > > system emulation.
> > > 
> > > Signed-off-by: Dr. David Alan Gilbert <dgilbert at redhat.com>
> > > ---
> > >  docs/about/deprecated.rst | 8 ++++++++
> > >  1 file changed, 8 insertions(+)
> > > 
> > > diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
> > > index 85773db631..143c60d105 100644
> > > --- a/docs/about/deprecated.rst
> > > +++ b/docs/about/deprecated.rst
> > > @@ -324,6 +324,14 @@ machine is hardly emulated at all (e.g. neither the LCD nor the USB part had
> > >  been implemented), so there is not much value added by this board. Use the
> > >  ``ref405ep`` machine instead.
> > >  
> > > +x86 default machine type
> > > +''''''''''''''''''''''''
> > > +
> > > +x86 currently defaults to the ```pc``` machine type which is based on the very
> > > +old ```i440fx``` chipset.  This default will be removed and the user will be
> > > +required to specify a machine type explicitly using -M; users are encouraged to
> > > +switch to the not quite as old ```q35``` machine types.
> > 
> > This will have no impact on anyone using libvirt as a mgmt app,
> > because it will explicitly set 'pc' if the user doesn't request
> > a machine type.
> > 
> > It will, however, break a huge number of users who don't use
> > libvirt or a similar mgmt app.
> > 
> > 'q35' is not a drop in replacement for 'pc', and even though
> > it is slightly newer, the features it brings are not likely
> > to be important enough for most users who aren't using a mgmt
> > app to care about switching.
> 
> I can see it having advantages for those who do things like PCIe pass
> through of graphics cards.
> However, my main concern is that there's a split happening where
> downstream we're working primarily on q35 but a lot of people still use
> i440fx; eventually that split will mean the i440fx users will have a
> pretty bad experience instability/features.
> So I'd like to encourage them onto a35.

We've still got quite significant testing coverage of i440fx and outside
of PCI-Express much logic is shared with q35. Right now at least i440fx
feels mature and stable, while q35 is still showing significant
instability with PCI-Express and hotplug in particular. I'd hoppe at
least the combination of maturity of our plain PCI code and testing
coverage would address risk of significant regressions in i440fx even
when attention is on q35. 

> > In the ongoing work to introduce a completely new system
> > emulator binary that is exclusively runtime QMP configured,
> > the machine type will almost certainly be mandatory, without
> > affecting existing users. That would also apply consistently
> > across all target arches.
> 
> I'm assuming that will also cause the disruption to those end users.

The difference is that people would opt-in to usage of the new system
binaries. So existing users, scripts and documentation won't be impacted
unless they decide to switch - at least as long as we keep the old
system emulators around. If did eventually decide to remove the old
binaries, then there would be disruption but that's more of a clean
break with the past.

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 :|