[PATCH for-9.0] docs/about: Mark the iaspc machine type as deprecated
ISAPC machine was introduced 25 years ago and it's a lot of time since such machine was around with real ISA only PC hardware practically defunct. Also it's slowly bit-rots (for example: I was able to boot RHEL6 on RHEL9 host in only TCG mode, while in KVM mode it hung in the middle of boot) Rather than spending time on fixing 'the oldest' no longer tested machine type, deprecate it so we can clean up QEMU code from legacy fixups and hopefully make it easier to follow. Folks who have to use ancient guest that requires ISAPC can still use older QEMU to play with it. Signed-off-by: Igor Mammedov <imammedo@redhat.com> --- docs/about/deprecated.rst | 7 +++++++ hw/i386/pc_piix.c | 1 + 2 files changed, 8 insertions(+) diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index 7b548519b5..5708296991 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -226,6 +226,13 @@ These old machine types are quite neglected nowadays and thus might have various pitfalls with regards to live migration. Use a newer machine type instead. +``isapc`` (since 9.0) +''''''''''''''''''''''''''''''''''''''''''''''''''''' + +These old machine type are quite neglected nowadays and thus might have +various pitfalls with regards to live migration. Use a newer machine type +instead. + Nios II ``10m50-ghrd`` and ``nios2-generic-nommu`` machines (since 8.2) ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c index 18ba076609..96f72384dd 100644 --- a/hw/i386/pc_piix.c +++ b/hw/i386/pc_piix.c @@ -921,6 +921,7 @@ static void isapc_machine_options(MachineClass *m) m->default_nic = "ne2k_isa"; m->default_cpu_type = X86_CPU_TYPE_NAME("486"); m->no_parallel = !module_object_class_by_name(TYPE_ISA_PARALLEL); + m->deprecation_reason = "old and unattended - use a newer version instead"; } DEFINE_PC_MACHINE(isapc, "isapc", pc_init_isa, -- 2.43.0
On 26 Mar 2024, at 18:21, Igor Mammedov <imammedo@redhat.com> wrote:
ISAPC machine was introduced 25 years ago and it's a lot of time since such machine was around with real ISA only PC hardware practically defunct. Also it's slowly bit-rots (for example: I was able to boot RHEL6 on RHEL9 host in only TCG mode, while in KVM mode it hung in the middle of boot)
Rather than spending time on fixing 'the oldest' no longer tested machine type, deprecate it so we can clean up QEMU code from legacy fixups and hopefully make it easier to follow.
Folks who have to use ancient guest that requires ISAPC can still use older QEMU to play with it.
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Ani Sinha <anisinha@redhat.com>
--- docs/about/deprecated.rst | 7 +++++++ hw/i386/pc_piix.c | 1 + 2 files changed, 8 insertions(+)
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index 7b548519b5..5708296991 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -226,6 +226,13 @@ These old machine types are quite neglected nowadays and thus might have various pitfalls with regards to live migration. Use a newer machine type instead.
+``isapc`` (since 9.0) +''''''''''''''''''''''''''''''''''''''''''''''''''''' + +These old machine type are quite neglected nowadays and thus might have +various pitfalls with regards to live migration. Use a newer machine type +instead. + Nios II ``10m50-ghrd`` and ``nios2-generic-nommu`` machines (since 8.2) '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c index 18ba076609..96f72384dd 100644 --- a/hw/i386/pc_piix.c +++ b/hw/i386/pc_piix.c @@ -921,6 +921,7 @@ static void isapc_machine_options(MachineClass *m) m->default_nic = "ne2k_isa"; m->default_cpu_type = X86_CPU_TYPE_NAME("486"); m->no_parallel = !module_object_class_by_name(TYPE_ISA_PARALLEL); + m->deprecation_reason = "old and unattended - use a newer version instead"; }
DEFINE_PC_MACHINE(isapc, "isapc", pc_init_isa, -- 2.43.0 _______________________________________________ Devel mailing list -- devel@lists.libvirt.org To unsubscribe send an email to devel-leave@lists.libvirt.org
s/iaspc/isapc/ in the subject On 26/03/2024 13.51, Igor Mammedov wrote:
ISAPC machine was introduced 25 years ago and it's a lot of time since such machine was around with real ISA only PC hardware practically defunct. Also it's slowly bit-rots (for example: I was able to boot RHEL6 on RHEL9 host in only TCG mode, while in KVM mode it hung in the middle of boot)
Rather than spending time on fixing 'the oldest' no longer tested machine type, deprecate it so we can clean up QEMU code from legacy fixups and hopefully make it easier to follow.
Folks who have to use ancient guest that requires ISAPC can still use older QEMU to play with it.
Signed-off-by: Igor Mammedov <imammedo@redhat.com> --- docs/about/deprecated.rst | 7 +++++++ hw/i386/pc_piix.c | 1 + 2 files changed, 8 insertions(+)
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index 7b548519b5..5708296991 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -226,6 +226,13 @@ These old machine types are quite neglected nowadays and thus might have various pitfalls with regards to live migration. Use a newer machine type instead.
+``isapc`` (since 9.0) +''''''''''''''''''''''''''''''''''''''''''''''''''''' + +These old machine type are quite neglected nowadays and thus might have
"This old machine type is ..." ?
+various pitfalls with regards to live migration. Use a newer machine type +instead.
I doubt that isapc could ever be used reliably for live migration, since it's an unversioned machine type, so I think it would be better to not mention live migration here. Thomas
Hi Igor, On 26/3/24 14:08, Thomas Huth wrote:
s/iaspc/isapc/ in the subject
On 26/03/2024 13.51, Igor Mammedov wrote:
ISAPC machine was introduced 25 years ago and it's a lot of time since such machine was around with real ISA only PC hardware practically defunct. Also it's slowly bit-rots (for example: I was able to boot RHEL6 on RHEL9 host in only TCG mode, while in KVM mode it hung in the middle of boot)
I'm quite opposed to this patch. QEMU models various very-old / defunct hardware. I'm pretty sure Bernhard and myself are OK to keep maintaining it, besides we are working in separating it from the i440fx+piix machine. Also, this machine is particularly interesting for my single-binary experiments. Where I agree is we should stop reporting "KVM on ISA/PC machine" as supported. Regards, Phil.
Rather than spending time on fixing 'the oldest' no longer tested machine type, deprecate it so we can clean up QEMU code from legacy fixups and hopefully make it easier to follow.
Folks who have to use ancient guest that requires ISAPC can still use older QEMU to play with it.
Signed-off-by: Igor Mammedov <imammedo@redhat.com> --- docs/about/deprecated.rst | 7 +++++++ hw/i386/pc_piix.c | 1 + 2 files changed, 8 insertions(+)
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index 7b548519b5..5708296991 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -226,6 +226,13 @@ These old machine types are quite neglected nowadays and thus might have various pitfalls with regards to live migration. Use a newer machine type instead. +``isapc`` (since 9.0) +''''''''''''''''''''''''''''''''''''''''''''''''''''' + +These old machine type are quite neglected nowadays and thus might have
"This old machine type is ..." ?
+various pitfalls with regards to live migration. Use a newer machine type +instead.
I doubt that isapc could ever be used reliably for live migration, since it's an unversioned machine type, so I think it would be better to not mention live migration here.
Thomas
On 26/03/2024 14.29, Philippe Mathieu-Daudé wrote:
Hi Igor,
On 26/3/24 14:08, Thomas Huth wrote:
s/iaspc/isapc/ in the subject
On 26/03/2024 13.51, Igor Mammedov wrote:
ISAPC machine was introduced 25 years ago and it's a lot of time since such machine was around with real ISA only PC hardware practically defunct. Also it's slowly bit-rots (for example: I was able to boot RHEL6 on RHEL9 host in only TCG mode, while in KVM mode it hung in the middle of boot)
I'm quite opposed to this patch. QEMU models various very-old / defunct hardware. I'm pretty sure Bernhard and myself are OK to keep maintaining it, besides we are working in separating it from the i440fx+piix machine. Also, this machine is particularly interesting for my single-binary experiments.
Where I agree is we should stop reporting "KVM on ISA/PC machine" as supported.
+1 See also: https://lists.gnu.org/archive/html/qemu-devel/2017-11/msg01367.html Thomas
On 26/3/24 14:37, Thomas Huth wrote:
On 26/03/2024 14.29, Philippe Mathieu-Daudé wrote:
Hi Igor,
On 26/3/24 14:08, Thomas Huth wrote:
s/iaspc/isapc/ in the subject
On 26/03/2024 13.51, Igor Mammedov wrote:
ISAPC machine was introduced 25 years ago and it's a lot of time since such machine was around with real ISA only PC hardware practically defunct. Also it's slowly bit-rots (for example: I was able to boot RHEL6 on RHEL9 host in only TCG mode, while in KVM mode it hung in the middle of boot)
I'm quite opposed to this patch. QEMU models various very-old / defunct hardware. I'm pretty sure Bernhard and myself are OK to keep maintaining it, besides we are working in separating it from the i440fx+piix machine. Also, this machine is particularly interesting for my single-binary experiments.
Where I agree is we should stop reporting "KVM on ISA/PC machine" as supported.
+1
Rough plan is to extract 'isapc' machine from PCMachineClass, having the latter becoming smth like PcPciMachineClass, on top of: https://lore.kernel.org/qemu-devel/20240305134221.30924-1-philmd@linaro.org/
See also:
https://lists.gnu.org/archive/html/qemu-devel/2017-11/msg01367.html
lol I didn't remember I posted a similar patch =)
On Tue, 26 Mar 2024 14:29:58 +0100 Philippe Mathieu-Daudé <philmd@linaro.org> wrote:
Hi Igor,
On 26/3/24 14:08, Thomas Huth wrote:
s/iaspc/isapc/ in the subject
On 26/03/2024 13.51, Igor Mammedov wrote:
ISAPC machine was introduced 25 years ago and it's a lot of time since such machine was around with real ISA only PC hardware practically defunct. Also it's slowly bit-rots (for example: I was able to boot RHEL6 on RHEL9 host in only TCG mode, while in KVM mode it hung in the middle of boot)
I'm quite opposed to this patch. QEMU models various very-old / defunct hardware. I'm pretty sure Bernhard and myself are OK to keep maintaining it, besides we are working in separating it from the i440fx+piix machine. Also, this machine is particularly interesting for my single-binary experiments.
it would not be fair to ask you or Bernard to deal with every case where ISAPC related code gets in a way, nor it's fair to ask other contributors to ensure that their patches don't break semi-working ISAPC or refactor code that relates to it. [ for example I'd like to refactor smbios parts in the image ACPI table builder, but the I'd have to do it for legacy part as well without means to verify that. Sure it can be done but at cost of extra time spent to rewrite something that would never be used and to find test env to verify touched code. ] However I look at it, isapc is burden at this point and it gets into a way of evolving. [downstream hat] while both of you do a wonderful job of separating some parts of the mess we have, it's a lot of churn which is not ideal when it comes to backporting patches. [emotional hat] Nowadays with modern containers tooling it's very easy to spawn old qemu environment to play with removed machines/features. quick few minutes example that lets me run isapc on old ubuntu without need to read how to build containers in 100 different ways: toolbox create --distro ubuntu --release 22.04 toolbox enter ubuntu-toolbox-22.04 toolbox enter ubuntu-toolbox-22.04 [user@toolbox ~]$ sudo apt update [user@toolbox ~]$ sudo apt install qemu-system-x86 [user@toolbox ~]$ qemu-system-i386 -M isapc -vnc :0 my_toy.qcow2 PS: I haven't had high hopes of this getting accepted, but I had to try. Though recent trend was that upstream QEMU were deprecating/dropping old machines/devices (even ones that kernel folks were using for testing) and it hasn't caused the end of universe (old qemu(s) sill exists and can be used for those cases).
Where I agree is we should stop reporting "KVM on ISA/PC machine" as supported.
Regards,
Phil.
Rather than spending time on fixing 'the oldest' no longer tested machine type, deprecate it so we can clean up QEMU code from legacy fixups and hopefully make it easier to follow.
Folks who have to use ancient guest that requires ISAPC can still use older QEMU to play with it.
Signed-off-by: Igor Mammedov <imammedo@redhat.com> --- docs/about/deprecated.rst | 7 +++++++ hw/i386/pc_piix.c | 1 + 2 files changed, 8 insertions(+)
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index 7b548519b5..5708296991 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -226,6 +226,13 @@ These old machine types are quite neglected nowadays and thus might have various pitfalls with regards to live migration. Use a newer machine type instead. +``isapc`` (since 9.0) +''''''''''''''''''''''''''''''''''''''''''''''''''''' + +These old machine type are quite neglected nowadays and thus might have
"This old machine type is ..." ?
+various pitfalls with regards to live migration. Use a newer machine type +instead.
I doubt that isapc could ever be used reliably for live migration, since it's an unversioned machine type, so I think it would be better to not mention live migration here.
Thomas
On Tue, Mar 26, 2024 at 05:16:32PM +0100, Igor Mammedov wrote:
On Tue, 26 Mar 2024 14:29:58 +0100 Philippe Mathieu-Daudé <philmd@linaro.org> wrote:
Hi Igor,
On 26/3/24 14:08, Thomas Huth wrote:
s/iaspc/isapc/ in the subject
On 26/03/2024 13.51, Igor Mammedov wrote:
ISAPC machine was introduced 25 years ago and it's a lot of time since such machine was around with real ISA only PC hardware practically defunct. Also it's slowly bit-rots (for example: I was able to boot RHEL6 on RHEL9 host in only TCG mode, while in KVM mode it hung in the middle of boot)
I'm quite opposed to this patch. QEMU models various very-old / defunct hardware. I'm pretty sure Bernhard and myself are OK to keep maintaining it, besides we are working in separating it from the i440fx+piix machine. Also, this machine is particularly interesting for my single-binary experiments.
it would not be fair to ask you or Bernard to deal with every case where ISAPC related code gets in a way, nor it's fair to ask other contributors to ensure that their patches don't break semi-working ISAPC or refactor code that relates to it.
[ for example I'd like to refactor smbios parts in the image ACPI table builder, but the I'd have to do it for legacy part as well without means to verify that. Sure it can be done but at cost of extra time spent to rewrite something that would never be used and to find test env to verify touched code. ]
Is SMBIOS even relevant for isapc ? IIUC, the first SMBIOS spec is from 1999, while PCI has been around since 1992. IOW, we shouldn't even be exposing SMBIOS with the isapc machine type. If we address that, then isapc has no impact on your ability to refactor SMBIOS code. With 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 :|
On Wed, 27 Mar 2024 10:49:43 +0000 Daniel P. Berrangé <berrange@redhat.com> wrote:
On Tue, Mar 26, 2024 at 05:16:32PM +0100, Igor Mammedov wrote:
On Tue, 26 Mar 2024 14:29:58 +0100 Philippe Mathieu-Daudé <philmd@linaro.org> wrote:
Hi Igor,
On 26/3/24 14:08, Thomas Huth wrote:
s/iaspc/isapc/ in the subject
On 26/03/2024 13.51, Igor Mammedov wrote:
ISAPC machine was introduced 25 years ago and it's a lot of time since such machine was around with real ISA only PC hardware practically defunct. Also it's slowly bit-rots (for example: I was able to boot RHEL6 on RHEL9 host in only TCG mode, while in KVM mode it hung in the middle of boot)
I'm quite opposed to this patch. QEMU models various very-old / defunct hardware. I'm pretty sure Bernhard and myself are OK to keep maintaining it, besides we are working in separating it from the i440fx+piix machine. Also, this machine is particularly interesting for my single-binary experiments.
it would not be fair to ask you or Bernard to deal with every case where ISAPC related code gets in a way, nor it's fair to ask other contributors to ensure that their patches don't break semi-working ISAPC or refactor code that relates to it.
[ for example I'd like to refactor smbios parts in the image ACPI table builder, but the I'd have to do it for legacy part as well without means to verify that. Sure it can be done but at cost of extra time spent to rewrite something that would never be used and to find test env to verify touched code. ]
Is SMBIOS even relevant for isapc ? IIUC, the first SMBIOS spec is from 1999, while PCI has been around since 1992.
Theoretically SMBIOS can still be used with isapc, (that's how I've tested factoring out legacy part by running RHEL6 in TCG mode) Whether it's used in practice somewhere else is unknown.
IOW, we shouldn't even be exposing SMBIOS with the isapc machine type. If we address that, then isapc has no impact on your ability to refactor SMBIOS code.
It's question of whether we are willing to do unthinkable, i.e. to break QEMU <-> guest ABI for isapc case by removing corresponding fwcfg entries. With migration ignored it shouldn't be a problem. Question is: does anyone care about migration with isapc? If not, I'd gladly axe smbios legacy parts in 9.1 But given how easy one can spawn old qemu environment to run something on isapc, we are loosing a chance to cleanup QEMU code base touching following m->option_rom_has_mr = true; m->rom_file_has_mr = false; pcmc->pci_enabled = false; pcmc->has_acpi_build = false; pcmc->smbios_defaults = false; pcmc->gigabyte_align = false; pcmc->smbios_legacy_mode = true; pcmc->has_reserved_memory = false; they are all marginal but in shared code, and removing them makes code a bit more easier to follow (especially when it comes to memory layout).
With regards, Daniel
On 27/03/2024 14.09, Igor Mammedov wrote:
On Wed, 27 Mar 2024 10:49:43 +0000 Daniel P. Berrangé <berrange@redhat.com> wrote:
On Tue, Mar 26, 2024 at 05:16:32PM +0100, Igor Mammedov wrote:
On Tue, 26 Mar 2024 14:29:58 +0100 Philippe Mathieu-Daudé <philmd@linaro.org> wrote:
Hi Igor,
On 26/3/24 14:08, Thomas Huth wrote:
s/iaspc/isapc/ in the subject
On 26/03/2024 13.51, Igor Mammedov wrote:
ISAPC machine was introduced 25 years ago and it's a lot of time since such machine was around with real ISA only PC hardware practically defunct. Also it's slowly bit-rots (for example: I was able to boot RHEL6 on RHEL9 host in only TCG mode, while in KVM mode it hung in the middle of boot)
I'm quite opposed to this patch. QEMU models various very-old / defunct hardware. I'm pretty sure Bernhard and myself are OK to keep maintaining it, besides we are working in separating it from the i440fx+piix machine. Also, this machine is particularly interesting for my single-binary experiments.
it would not be fair to ask you or Bernard to deal with every case where ISAPC related code gets in a way, nor it's fair to ask other contributors to ensure that their patches don't break semi-working ISAPC or refactor code that relates to it.
[ for example I'd like to refactor smbios parts in the image ACPI table builder, but the I'd have to do it for legacy part as well without means to verify that. Sure it can be done but at cost of extra time spent to rewrite something that would never be used and to find test env to verify touched code. ]
Is SMBIOS even relevant for isapc ? IIUC, the first SMBIOS spec is from 1999, while PCI has been around since 1992.
Theoretically SMBIOS can still be used with isapc, (that's how I've tested factoring out legacy part by running RHEL6 in TCG mode) Whether it's used in practice somewhere else is unknown.
IOW, we shouldn't even be exposing SMBIOS with the isapc machine type. If we address that, then isapc has no impact on your ability to refactor SMBIOS code.
It's question of whether we are willing to do unthinkable, i.e. to break QEMU <-> guest ABI for isapc case by removing corresponding fwcfg entries.
With migration ignored it shouldn't be a problem. Question is: does anyone care about migration with isapc?
isapc is not versioned, so it is not really usable with migration at all, I think. We should maybe even add a migration blocker for that machine to avoid that people try to migrate it. I just gave it also a quick try, and it currently seems to be broken anyway (aborts with "memory_region_set_alias_offset: Assertion `mr->alias' failed"). Thomas
On Wed, Mar 27, 2024 at 02:09:17PM +0100, Igor Mammedov wrote:
On Wed, 27 Mar 2024 10:49:43 +0000 Daniel P. Berrangé <berrange@redhat.com> wrote:
On Tue, Mar 26, 2024 at 05:16:32PM +0100, Igor Mammedov wrote:
On Tue, 26 Mar 2024 14:29:58 +0100 Philippe Mathieu-Daudé <philmd@linaro.org> wrote:
Hi Igor,
On 26/3/24 14:08, Thomas Huth wrote:
s/iaspc/isapc/ in the subject
On 26/03/2024 13.51, Igor Mammedov wrote:
ISAPC machine was introduced 25 years ago and it's a lot of time since such machine was around with real ISA only PC hardware practically defunct. Also it's slowly bit-rots (for example: I was able to boot RHEL6 on RHEL9 host in only TCG mode, while in KVM mode it hung in the middle of boot)
I'm quite opposed to this patch. QEMU models various very-old / defunct hardware. I'm pretty sure Bernhard and myself are OK to keep maintaining it, besides we are working in separating it from the i440fx+piix machine. Also, this machine is particularly interesting for my single-binary experiments.
it would not be fair to ask you or Bernard to deal with every case where ISAPC related code gets in a way, nor it's fair to ask other contributors to ensure that their patches don't break semi-working ISAPC or refactor code that relates to it.
[ for example I'd like to refactor smbios parts in the image ACPI table builder, but the I'd have to do it for legacy part as well without means to verify that. Sure it can be done but at cost of extra time spent to rewrite something that would never be used and to find test env to verify touched code. ]
Is SMBIOS even relevant for isapc ? IIUC, the first SMBIOS spec is from 1999, while PCI has been around since 1992.
Theoretically SMBIOS can still be used with isapc, (that's how I've tested factoring out legacy part by running RHEL6 in TCG mode) Whether it's used in practice somewhere else is unknown.
IOW, we shouldn't even be exposing SMBIOS with the isapc machine type. If we address that, then isapc has no impact on your ability to refactor SMBIOS code.
It's question of whether we are willing to do unthinkable, i.e. to break QEMU <-> guest ABI for isapc case by removing corresponding fwcfg entries.
There has never been any ABI stability requirement for 'isapc' as it is not a versioned machine type.
With migration ignored it shouldn't be a problem. Question is: does anyone care about migration with isapc? If not, I'd gladly axe smbios legacy parts in 9.1
Migration is irrelevant unless someone steps forward to commit to long term versioning of the machine type.
But given how easy one can spawn old qemu environment to
There are ways to get access to an old QEMU, but I would not call them easy when compared to using the QEMU that is shipped as standard by your distro. For a while a tried to maintain an archive of old QEMU versions built for modern distros and it was a surprisingly painful exercise. We tend to forget just how often QEMU's build gets broken by new compilers, or new glibc system header changes, or other 3rd party packages. Telling users to find an old QEMU is not an attractive proposition, except as a last resort. With 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 :|
On Wed, 27 Mar 2024 at 13:23, Daniel P. Berrangé <berrange@redhat.com> wrote:
On Wed, Mar 27, 2024 at 02:09:17PM +0100, Igor Mammedov wrote:
On Wed, 27 Mar 2024 10:49:43 +0000 Daniel P. Berrangé <berrange@redhat.com> wrote: It's question of whether we are willing to do unthinkable, i.e. to break QEMU <-> guest ABI for isapc case by removing corresponding fwcfg entries.
There has never been any ABI stability requirement for 'isapc' as it is not a versioned machine type.
With migration ignored it shouldn't be a problem. Question is: does anyone care about migration with isapc? If not, I'd gladly axe smbios legacy parts in 9.1
Migration is irrelevant unless someone steps forward to commit to long term versioning of the machine type.
But migration is also how we implement savevm/loadvm, which are useful even when the machine type is not versioned. So please don't put in migration blockers or similar that would break that. thanks -- PMM
On Wed, Mar 27, 2024 at 01:27:58PM +0000, Peter Maydell wrote:
On Wed, 27 Mar 2024 at 13:23, Daniel P. Berrangé <berrange@redhat.com> wrote:
On Wed, Mar 27, 2024 at 02:09:17PM +0100, Igor Mammedov wrote:
On Wed, 27 Mar 2024 10:49:43 +0000 Daniel P. Berrangé <berrange@redhat.com> wrote: It's question of whether we are willing to do unthinkable, i.e. to break QEMU <-> guest ABI for isapc case by removing corresponding fwcfg entries.
There has never been any ABI stability requirement for 'isapc' as it is not a versioned machine type.
With migration ignored it shouldn't be a problem. Question is: does anyone care about migration with isapc? If not, I'd gladly axe smbios legacy parts in 9.1
Migration is irrelevant unless someone steps forward to commit to long term versioning of the machine type.
But migration is also how we implement savevm/loadvm, which are useful even when the machine type is not versioned. So please don't put in migration blockers or similar that would break that.
Yep, that's valid use case within the scope of a single QEMU release. We just can't guarantee it across versions. Often it'll probably work but it is liable to break at times. With 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 :|
On 27/3/24 14:09, Igor Mammedov wrote:
On Wed, 27 Mar 2024 10:49:43 +0000 Daniel P. Berrangé <berrange@redhat.com> wrote:
On Tue, Mar 26, 2024 at 05:16:32PM +0100, Igor Mammedov wrote:
On Tue, 26 Mar 2024 14:29:58 +0100 Philippe Mathieu-Daudé <philmd@linaro.org> wrote:
Hi Igor,
On 26/3/24 14:08, Thomas Huth wrote:
s/iaspc/isapc/ in the subject
On 26/03/2024 13.51, Igor Mammedov wrote:
ISAPC machine was introduced 25 years ago and it's a lot of time since such machine was around with real ISA only PC hardware practically defunct. Also it's slowly bit-rots (for example: I was able to boot RHEL6 on RHEL9 host in only TCG mode, while in KVM mode it hung in the middle of boot)
I'm quite opposed to this patch. QEMU models various very-old / defunct hardware. I'm pretty sure Bernhard and myself are OK to keep maintaining it, besides we are working in separating it from the i440fx+piix machine. Also, this machine is particularly interesting for my single-binary experiments.
it would not be fair to ask you or Bernard to deal with every case where ISAPC related code gets in a way, nor it's fair to ask other contributors to ensure that their patches don't break semi-working ISAPC or refactor code that relates to it.
[ for example I'd like to refactor smbios parts in the image ACPI table builder, but the I'd have to do it for legacy part as well without means to verify that. Sure it can be done but at cost of extra time spent to rewrite something that would never be used and to find test env to verify touched code. ]
Is SMBIOS even relevant for isapc ? IIUC, the first SMBIOS spec is from 1999, while PCI has been around since 1992.
Theoretically SMBIOS can still be used with isapc, (that's how I've tested factoring out legacy part by running RHEL6 in TCG mode) Whether it's used in practice somewhere else is unknown.
IOW, we shouldn't even be exposing SMBIOS with the isapc machine type. If we address that, then isapc has no impact on your ability to refactor SMBIOS code.
It's question of whether we are willing to do unthinkable, i.e. to break QEMU <-> guest ABI for isapc case by removing corresponding fwcfg entries.
With migration ignored it shouldn't be a problem. Question is: does anyone care about migration with isapc? If not, I'd gladly axe smbios legacy parts in 9.1
But given how easy one can spawn old qemu environment to run something on isapc, we are loosing a chance to cleanup QEMU code base touching following
m->option_rom_has_mr = true; m->rom_file_has_mr = false; pcmc->pci_enabled = false; pcmc->has_acpi_build = false; pcmc->smbios_defaults = false; pcmc->gigabyte_align = false; pcmc->smbios_legacy_mode = true;
My plan is to split the legacy part of fw_cfg_build_smbios() out of it as fw_cfg_build_smbios_legacy().
pcmc->has_reserved_memory = false;
they are all marginal but in shared code, and removing them makes code a bit more easier to follow (especially when it comes to memory layout).
With regards, Daniel
Il mer 27 mar 2024, 14:09 Igor Mammedov <imammedo@redhat.com> ha scritto:
It's question of whether we are willing to do unthinkable, i.e. to break QEMU <-> guest ABI for isapc case by removing corresponding fwcfg entries.
It's not unthinkable since it's unversioned. we are loosing a chance to cleanup
QEMU code base touching following
m->option_rom_has_mr = true; m->rom_file_has_mr = false; pcmc->pci_enabled = false; pcmc->has_acpi_build = false; pcmc->smbios_defaults = false; pcmc->gigabyte_align = false; pcmc->smbios_legacy_mode = true; pcmc->has_reserved_memory = false;
Some of these can go away, for the others probably we can think of making isapc a direct subclass of X86MachineState. I would rather keep it because it's the only way to test userspace interrupt injection in KVM. Paolo they are all marginal but in shared code, and removing them
makes code a bit more easier to follow (especially when it comes to memory layout).
With regards, Daniel
On Tue, Mar 26, 2024 at 02:29:58PM +0100, Philippe Mathieu-Daudé wrote:
Hi Igor,
On 26/3/24 14:08, Thomas Huth wrote:
s/iaspc/isapc/ in the subject
On 26/03/2024 13.51, Igor Mammedov wrote:
ISAPC machine was introduced 25 years ago and it's a lot of time since such machine was around with real ISA only PC hardware practically defunct. Also it's slowly bit-rots (for example: I was able to boot RHEL6 on RHEL9 host in only TCG mode, while in KVM mode it hung in the middle of boot)
I'm quite opposed to this patch. QEMU models various very-old / defunct hardware. I'm pretty sure Bernhard and myself are OK to keep maintaining it, besides we are working in separating it from the i440fx+piix machine. Also, this machine is particularly interesting for my single-binary experiments.
Where I agree is we should stop reporting "KVM on ISA/PC machine" as supported.
isapc could arguably be restricted to just 32-bit CPU models, because we should not need it to support any feature that didn't exist prior to circa 1995. eg refuse to start with isapc, if 'lm' is present in the CPU model for example. With 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 :|
Am 26. März 2024 13:29:58 UTC schrieb "Philippe Mathieu-Daudé" <philmd@linaro.org>:
Hi Igor,
On 26/3/24 14:08, Thomas Huth wrote:
s/iaspc/isapc/ in the subject
On 26/03/2024 13.51, Igor Mammedov wrote:
ISAPC machine was introduced 25 years ago and it's a lot of time since such machine was around with real ISA only PC hardware practically defunct. Also it's slowly bit-rots (for example: I was able to boot RHEL6 on RHEL9 host in only TCG mode, while in KVM mode it hung in the middle of boot)
I'm quite opposed to this patch. QEMU models various very-old / defunct hardware. I'm pretty sure Bernhard and myself are OK to keep maintaining it, besides we are working in separating it from the i440fx+piix machine.
Yes, I'd rather keep maintaining the isapc machine and separating it from the i440fx machine seems like a good idea to me. I'm confident that we can work out a way that allows for moving forward the pc-pci machines while keeping the isapc machine from getting into the way too much. Best regards, Bernhard
Also, this machine is particularly interesting for my single-binary experiments.
Where I agree is we should stop reporting "KVM on ISA/PC machine" as supported.
Regards,
Phil.
Rather than spending time on fixing 'the oldest' no longer tested machine type, deprecate it so we can clean up QEMU code from legacy fixups and hopefully make it easier to follow.
Folks who have to use ancient guest that requires ISAPC can still use older QEMU to play with it.
Signed-off-by: Igor Mammedov <imammedo@redhat.com> --- docs/about/deprecated.rst | 7 +++++++ hw/i386/pc_piix.c | 1 + 2 files changed, 8 insertions(+)
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index 7b548519b5..5708296991 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -226,6 +226,13 @@ These old machine types are quite neglected nowadays and thus might have various pitfalls with regards to live migration. Use a newer machine type instead. +``isapc`` (since 9.0) +''''''''''''''''''''''''''''''''''''''''''''''''''''' + +These old machine type are quite neglected nowadays and thus might have
"This old machine type is ..." ?
+various pitfalls with regards to live migration. Use a newer machine type +instead.
I doubt that isapc could ever be used reliably for live migration, since it's an unversioned machine type, so I think it would be better to not mention live migration here.
Thomas
On 26/03/2024 12:51, Igor Mammedov wrote:
ISAPC machine was introduced 25 years ago and it's a lot of time since such machine was around with real ISA only PC hardware practically defunct. Also it's slowly bit-rots (for example: I was able to boot RHEL6 on RHEL9 host in only TCG mode, while in KVM mode it hung in the middle of boot)
Rather than spending time on fixing 'the oldest' no longer tested machine type, deprecate it so we can clean up QEMU code from legacy fixups and hopefully make it easier to follow.
Folks who have to use ancient guest that requires ISAPC can still use older QEMU to play with it.
Heh I've actually been using isapc over the past couple of weeks to fire up some old programs in a Windows 3 VM :) I'd really hate to see isapc disappear as there are a number of people from the retro crowd (such as myself) who fire up QEMU/KVM on various historical images, and whilst there are alternatives, there isn't really anything that touches QEMU performance-wise. This leads into the question as to how QEMU should handle less recent machines: I appreciate that from an enterprise perspective there is little interest, but there are plenty of hobbyists and historians who are. From my personal experience with SPARC/macppc machines I accept that they are not first-class citizens, and so my approach here is that I don't mind if patches break migration or command-line compatibility as long as I can still fire up the VM. Regressions do occur, but fortunately they don't tend to occur that often. I can see how there is a lot of legacy cruft around handling legacy command line options that could be improved by removing isapc, and I think that a lot of this is around preserving historical behaviour. How about splitting the isapc machine out of the generic PC init so that it can be used going forward with less command-line/migration compatibility guarantees, but also won't prevent subsequent tidy-ups/changes to the main PC machines going forward?
Signed-off-by: Igor Mammedov <imammedo@redhat.com> --- docs/about/deprecated.rst | 7 +++++++ hw/i386/pc_piix.c | 1 + 2 files changed, 8 insertions(+)
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index 7b548519b5..5708296991 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -226,6 +226,13 @@ These old machine types are quite neglected nowadays and thus might have various pitfalls with regards to live migration. Use a newer machine type instead.
+``isapc`` (since 9.0) +''''''''''''''''''''''''''''''''''''''''''''''''''''' + +These old machine type are quite neglected nowadays and thus might have +various pitfalls with regards to live migration. Use a newer machine type +instead. + Nios II ``10m50-ghrd`` and ``nios2-generic-nommu`` machines (since 8.2) '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c index 18ba076609..96f72384dd 100644 --- a/hw/i386/pc_piix.c +++ b/hw/i386/pc_piix.c @@ -921,6 +921,7 @@ static void isapc_machine_options(MachineClass *m) m->default_nic = "ne2k_isa"; m->default_cpu_type = X86_CPU_TYPE_NAME("486"); m->no_parallel = !module_object_class_by_name(TYPE_ISA_PARALLEL); + m->deprecation_reason = "old and unattended - use a newer version instead"; }
DEFINE_PC_MACHINE(isapc, "isapc", pc_init_isa,
ATB, Mark.
On Tue, 26 Mar 2024 13:30:48 +0000 Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> wrote:
On 26/03/2024 12:51, Igor Mammedov wrote:
ISAPC machine was introduced 25 years ago and it's a lot of time since such machine was around with real ISA only PC hardware practically defunct. Also it's slowly bit-rots (for example: I was able to boot RHEL6 on RHEL9 host in only TCG mode, while in KVM mode it hung in the middle of boot)
Rather than spending time on fixing 'the oldest' no longer tested machine type, deprecate it so we can clean up QEMU code from legacy fixups and hopefully make it easier to follow.
Folks who have to use ancient guest that requires ISAPC can still use older QEMU to play with it.
Heh I've actually been using isapc over the past couple of weeks to fire up some old programs in a Windows 3 VM :)
I'd really hate to see isapc disappear as there are a number of people from the retro crowd (such as myself) who fire up QEMU/KVM on various historical images, and whilst there are alternatives, there isn't really anything that touches QEMU performance-wise.
This leads into the question as to how QEMU should handle less recent machines: I appreciate that from an enterprise perspective there is little interest, but there are plenty of hobbyists and historians who are.
I'm not looking at it from enterprise point of view, but rather from developers/maintainers side.
From my personal experience with SPARC/macppc machines I accept that they are not first-class citizens, and so my approach here is that I don't mind if patches break migration or command-line compatibility as long as I can still fire up the VM. Regressions do occur, but fortunately they don't tend to occur that often.
I can see how there is a lot of legacy cruft around handling legacy command line options that could be improved by removing isapc, and I think that a lot of this is around preserving historical behaviour.
How about splitting the isapc machine out of the generic PC init so that it can be used going forward with less command-line/migration compatibility guarantees, but also won't prevent subsequent tidy-ups/changes to the main PC machines going forward?
it's not only command line, it polluting code all over pc machine (the recent example, I've touched smbios, where we have legacy mode only for ISAPC (since 2.0 machine has been deprecated/removed)). Yep, it should be possible to extract ISA machine at cost of some duplication and let it slowly continue decay. But it's thanks-less task and shared code would still remian the issue. Old QEMU can be used for testing at the cost of few minutes to create container without much hassle, see my other reply to Philippe.
Signed-off-by: Igor Mammedov <imammedo@redhat.com> --- docs/about/deprecated.rst | 7 +++++++ hw/i386/pc_piix.c | 1 + 2 files changed, 8 insertions(+)
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst index 7b548519b5..5708296991 100644 --- a/docs/about/deprecated.rst +++ b/docs/about/deprecated.rst @@ -226,6 +226,13 @@ These old machine types are quite neglected nowadays and thus might have various pitfalls with regards to live migration. Use a newer machine type instead.
+``isapc`` (since 9.0) +''''''''''''''''''''''''''''''''''''''''''''''''''''' + +These old machine type are quite neglected nowadays and thus might have +various pitfalls with regards to live migration. Use a newer machine type +instead. + Nios II ``10m50-ghrd`` and ``nios2-generic-nommu`` machines (since 8.2) '''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c index 18ba076609..96f72384dd 100644 --- a/hw/i386/pc_piix.c +++ b/hw/i386/pc_piix.c @@ -921,6 +921,7 @@ static void isapc_machine_options(MachineClass *m) m->default_nic = "ne2k_isa"; m->default_cpu_type = X86_CPU_TYPE_NAME("486"); m->no_parallel = !module_object_class_by_name(TYPE_ISA_PARALLEL); + m->deprecation_reason = "old and unattended - use a newer version instead"; }
DEFINE_PC_MACHINE(isapc, "isapc", pc_init_isa,
ATB,
Mark.
On Tue, Mar 26, 2024 at 01:30:48PM +0000, Mark Cave-Ayland wrote:
Heh I've actually been using isapc over the past couple of weeks to fire up some old programs in a Windows 3 VM :)
I'm wondering why these use cases can't simply use the 'pc' machine type? The early pci chipsets of the 90-ies have been designed in a backward-compatible manner, with devices such as the IDE controller being mapped to the standard ISA ioports. So even an historic OS which does not know what PCI is can run on that hardware, by simply talking to devices using the standard ISA io ports ... take care, Gerd
On 27/03/2024 07:09, Gerd Hoffmann wrote:
On Tue, Mar 26, 2024 at 01:30:48PM +0000, Mark Cave-Ayland wrote:
Heh I've actually been using isapc over the past couple of weeks to fire up some old programs in a Windows 3 VM :)
I'm wondering why these use cases can't simply use the 'pc' machine type?
The early pci chipsets of the 90-ies have been designed in a backward-compatible manner, with devices such as the IDE controller being mapped to the standard ISA ioports. So even an historic OS which does not know what PCI is can run on that hardware, by simply talking to devices using the standard ISA io ports ...
Hmmm that's a fair point: I think the pc machine has a PCI-ISA bridge included, so ISA devices can be plugged in as needed. The reason I ended up on that configuration was because I ended up chasing down a regression, and wanted to quickly eliminate things such as ACPI. ATB, Mark.
Am 28. März 2024 14:09:52 UTC schrieb Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>:
On 27/03/2024 07:09, Gerd Hoffmann wrote:
On Tue, Mar 26, 2024 at 01:30:48PM +0000, Mark Cave-Ayland wrote:
Heh I've actually been using isapc over the past couple of weeks to fire up some old programs in a Windows 3 VM :)
I'm wondering why these use cases can't simply use the 'pc' machine type?
The early pci chipsets of the 90-ies have been designed in a backward-compatible manner, with devices such as the IDE controller being mapped to the standard ISA ioports. So even an historic OS which does not know what PCI is can run on that hardware, by simply talking to devices using the standard ISA io ports ...
Hmmm that's a fair point: I think the pc machine has a PCI-ISA bridge included, so ISA devices can be plugged in as needed. The reason I ended up on that configuration was because I ended up chasing down a regression, and wanted to quickly eliminate things such as ACPI.
In theory you could pass `-M acpi=off` to not instantiate the PIIX4 ACPI function, essentially turning the Frankenstein-PIIX4 SB into a PIIX3. However, this also removes SMI registers used by SeaBIOS to handle SMM setup which may create unwanted side effects. On a real PIIX3, these registers are located in the ISA function. I wonder if it made sense to implement that for greater compatibility. What do you think? Gerd, what do you think w.r.t. SeaBIOS? Best regards, Bernhard
ATB,
Mark.
On Fri, Mar 29, 2024 at 10:19:09AM +0000, Bernhard Beschow wrote:
In theory you could pass `-M acpi=off` to not instantiate the PIIX4 ACPI function, essentially turning the Frankenstein-PIIX4 SB into a PIIX3. However, this also removes SMI registers used by SeaBIOS to handle SMM setup which may create unwanted side effects.
SeaBIOS will simply not use SMM in that case.
On a real PIIX3, these registers are located in the ISA function. I wonder if it made sense to implement that for greater compatibility.
What do you think? Gerd, what do you think w.r.t. SeaBIOS?
Well, SMM support isn't that important I think. It was introduced to make switches to 32-bit mode more robust. Entering SMM mode stores the *complete* x86 processor state (which is impossible to do in other ways), so with SMM it's possible to switch back into whatever state the processor has been before entering 32-bit mode. Some storage drivers (virtio, ahci) switch into 32-bit mode so they can reach the mmio registers they need. Some storage drivers (ide) don't, in that case SMM doesn't change anything. I'm not aware of any problems actually fixed by adding SMM support in seabios. I suspect the guest OS-es new enough to support ahci or virtio are also new enough to not not call BIOS interfaces from non-standard processor modes. take care, Gerd
participants (10)
-
Ani Sinha -
Bernhard Beschow -
Daniel P. Berrangé -
Gerd Hoffmann -
Igor Mammedov -
Mark Cave-Ayland -
Paolo Bonzini -
Peter Maydell -
Philippe Mathieu-Daudé -
Thomas Huth