qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] deprecation: x86 default machine types


From: Dr. David Alan Gilbert
Subject: Re: [PATCH] deprecation: x86 default machine types
Date: Thu, 3 Mar 2022 18:59:51 +0000
User-agent: Mutt/2.1.5 (2021-12-30)

* Daniel P. Berrangé (berrange@redhat.com) wrote:
> On Wed, Mar 02, 2022 at 07:38:52PM +0000, Dr. David Alan Gilbert wrote:
> > * Daniel P. Berrangé (berrange@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@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@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. 

OK, lets drop this for now.

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

So I guess that when this happens people will be pushed to the new
binaries and the old ones will degrade reasonably fast.

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]