[PATCH] deprecation: x86 default machine types
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. + Backend options --------------- -- 2.35.1
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. 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. Overall I'm just not seeing enough benefit to justify the disruption we'll cause by making this change to existing system emulator binaries. 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 :|
* 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. Ideally I'd like to make that easy; e.g. auto creating some of the PCIe busses.
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. Dave
Overall I'm just not seeing enough benefit to justify the disruption we'll cause by making this change to existing system emulator binaries.
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
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.
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 :|
* 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
participants (4)
-
Daniel P. Berrangé -
Dr. David Alan Gilbert -
Dr. David Alan Gilbert (git)
-
Paolo Bonzini