[PATCH v2 0/2] isapc: remove support for -cpu host and -cpu max

[PATCH v2 0/2] isapc: remove support for -cpu host and -cpu max

[Mark Cave-Ayland]

This series removes support for -cpu host and -cpu max from the isapc
machine as suggested by Igor, and then updates the "Backwards compatibility"
section of the documentation to reflect both this and the recently
introduced 32-bit x86 CPU restriction.

Signed-off-by: Mark Cave-Ayland <mark.caveayland@nutanix.com>

v2:
- Add documentation change suggested by Markus


Mark Cave-Ayland (2):
  hw/i386/isapc.c: remove support for -cpu host and -cpu max
  docs/about/deprecated.rst: document new restrictions for isapc CPU
    models

 docs/about/deprecated.rst | 13 +++++++++++++
 hw/i386/isapc.c           | 27 ---------------------------
 2 files changed, 13 insertions(+), 27 deletions(-)

-- 
2.43.0

[PATCH v2 1/2] hw/i386/isapc.c: remove support for -cpu host and -cpu max

[Mark Cave-Ayland]

Following recent discussions on the mailing list, it has been decided
that instead of mapping -cpu host and -cpu max to a suitable 32-bit x86 CPU,
it is preferable to disallow them and use the existing valid_cpu_types
validation logic so that an error is returned to the user instead.

Signed-off-by: Mark Cave-Ayland <mark.caveayland@nutanix.com>
---
 hw/i386/isapc.c | 27 ---------------------------
 1 file changed, 27 deletions(-)

diff --git a/hw/i386/isapc.c b/hw/i386/isapc.c
index 44f4a44672..6c35a397df 100644
--- a/hw/i386/isapc.c
+++ b/hw/i386/isapc.c
@@ -41,31 +41,6 @@ static void pc_init_isa(MachineState *machine)
     DriveInfo *hd[MAX_IDE_BUS * MAX_IDE_DEVS];
     int i;
 
-    /*
-     * There is a small chance that someone unintentionally passes "-cpu max"
-     * for the isapc machine, which will provide a much more modern 32-bit
-     * CPU than would be expected for an ISA-era PC. If the "max" cpu type has
-     * been specified, choose the "best" 32-bit cpu possible which we consider
-     * be the pentium3 (deliberately choosing an Intel CPU given that the
-     * default 486 CPU for the isapc machine is also an Intel CPU).
-     */
-    if (!strcmp(machine->cpu_type, X86_CPU_TYPE_NAME("max"))) {
-        machine->cpu_type = X86_CPU_TYPE_NAME("pentium3");
-        warn_report("-cpu max is invalid for isapc machine, using pentium3");
-    }
-
-    /*
-     * Similarly if someone unintentionally passes "-cpu host" for the isapc
-     * machine then display a warning and also switch to the "best" 32-bit
-     * cpu possible which we consider to be the pentium3. This is because any
-     * host CPU will already be modern than this, but it also ensures any
-     * newer CPU flags/features are filtered out for older guests.
-     */
-    if (!strcmp(machine->cpu_type, X86_CPU_TYPE_NAME("host"))) {
-        machine->cpu_type = X86_CPU_TYPE_NAME("pentium3");
-        warn_report("-cpu host is invalid for isapc machine, using pentium3");
-    }
-
     if (machine->ram_size > 3.5 * GiB) {
         error_report("Too much memory for this machine: %" PRId64 " MiB, "
                      "maximum 3584 MiB", machine->ram_size / MiB);
@@ -162,8 +137,6 @@ static void isapc_machine_options(MachineClass *m)
         X86_CPU_TYPE_NAME("pentium2"),
         X86_CPU_TYPE_NAME("pentium3"),
         X86_CPU_TYPE_NAME("qemu32"),
-        X86_CPU_TYPE_NAME("max"),
-        X86_CPU_TYPE_NAME("host"),
         NULL
     };
     PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
-- 
2.43.0

Re: [PATCH v2 1/2] hw/i386/isapc.c: remove support for -cpu host and -cpu max

[Markus Armbruster]

Mark Cave-Ayland <mark.caveayland@nutanix.com> writes:

> Following recent discussions on the mailing list, it has been decided
> that instead of mapping -cpu host and -cpu max to a suitable 32-bit x86 CPU,
> it is preferable to disallow them and use the existing valid_cpu_types
> validation logic so that an error is returned to the user instead.
>
> Signed-off-by: Mark Cave-Ayland <mark.caveayland@nutanix.com>
> ---
>  hw/i386/isapc.c | 27 ---------------------------
>  1 file changed, 27 deletions(-)
>
> diff --git a/hw/i386/isapc.c b/hw/i386/isapc.c
> index 44f4a44672..6c35a397df 100644
> --- a/hw/i386/isapc.c
> +++ b/hw/i386/isapc.c
> @@ -41,31 +41,6 @@ static void pc_init_isa(MachineState *machine)
>      DriveInfo *hd[MAX_IDE_BUS * MAX_IDE_DEVS];
>      int i;
>  
> -    /*
> -     * There is a small chance that someone unintentionally passes "-cpu max"
> -     * for the isapc machine, which will provide a much more modern 32-bit
> -     * CPU than would be expected for an ISA-era PC. If the "max" cpu type has
> -     * been specified, choose the "best" 32-bit cpu possible which we consider
> -     * be the pentium3 (deliberately choosing an Intel CPU given that the
> -     * default 486 CPU for the isapc machine is also an Intel CPU).
> -     */
> -    if (!strcmp(machine->cpu_type, X86_CPU_TYPE_NAME("max"))) {
> -        machine->cpu_type = X86_CPU_TYPE_NAME("pentium3");
> -        warn_report("-cpu max is invalid for isapc machine, using pentium3");
> -    }
> -
> -    /*
> -     * Similarly if someone unintentionally passes "-cpu host" for the isapc
> -     * machine then display a warning and also switch to the "best" 32-bit
> -     * cpu possible which we consider to be the pentium3. This is because any
> -     * host CPU will already be modern than this, but it also ensures any
> -     * newer CPU flags/features are filtered out for older guests.
> -     */
> -    if (!strcmp(machine->cpu_type, X86_CPU_TYPE_NAME("host"))) {
> -        machine->cpu_type = X86_CPU_TYPE_NAME("pentium3");
> -        warn_report("-cpu host is invalid for isapc machine, using pentium3");
> -    }
> -
>      if (machine->ram_size > 3.5 * GiB) {
>          error_report("Too much memory for this machine: %" PRId64 " MiB, "
>                       "maximum 3584 MiB", machine->ram_size / MiB);
> @@ -162,8 +137,6 @@ static void isapc_machine_options(MachineClass *m)
>          X86_CPU_TYPE_NAME("pentium2"),
>          X86_CPU_TYPE_NAME("pentium3"),
>          X86_CPU_TYPE_NAME("qemu32"),
> -        X86_CPU_TYPE_NAME("max"),
> -        X86_CPU_TYPE_NAME("host"),
>          NULL
>      };
>      PCMachineClass *pcmc = PC_MACHINE_CLASS(m);

This reverts the "smart" part of recent

commit e1e2909f8e74051a34a044940f90d4650b6e784a
Author: Mark Cave-Ayland <mark.caveayland@nutanix.com>
Date:   Thu Aug 28 12:09:44 2025 +0100

    hw/i386/pc_piix.c: restrict isapc machine to 32-bit CPUs
    
    The isapc machine represents a legacy ISA PC with a 486 CPU. Whilst it is
    possible to specify any CPU via -cpu on the command line, it makes no
    sense to allow modern 64-bit CPUs to be used.
    
    Restrict the isapc machine to the available 32-bit CPUs, taking care to
    handle the case where if a user inadvertently uses either -cpu max or
    -cpu host then the "best" 32-bit CPU is used (in this case the pentium3).
    
    Signed-off-by: Mark Cave-Ayland <mark.caveayland@nutanix.com>
    Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
    Link: https://lore.kernel.org/r/20250828111057.468712-2-mark.caveayland@nutanix.com
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

and keeps the dumb part.  Matches the commit message.

Reviewed-by: Markus Armbruster <armbru@redhat.com>

Re: [PATCH v2 1/2] hw/i386/isapc.c: remove support for -cpu host and -cpu max

[Daniel P. Berrangé]

On Fri, Sep 26, 2025 at 01:36:25PM +0200, Markus Armbruster wrote:
> Mark Cave-Ayland <mark.caveayland@nutanix.com> writes:
> 
> > Following recent discussions on the mailing list, it has been decided
> > that instead of mapping -cpu host and -cpu max to a suitable 32-bit x86 CPU,
> > it is preferable to disallow them and use the existing valid_cpu_types
> > validation logic so that an error is returned to the user instead.
> >
> > Signed-off-by: Mark Cave-Ayland <mark.caveayland@nutanix.com>
> > ---
> >  hw/i386/isapc.c | 27 ---------------------------
> >  1 file changed, 27 deletions(-)
> >
> > diff --git a/hw/i386/isapc.c b/hw/i386/isapc.c
> > index 44f4a44672..6c35a397df 100644
> > --- a/hw/i386/isapc.c
> > +++ b/hw/i386/isapc.c
> > @@ -41,31 +41,6 @@ static void pc_init_isa(MachineState *machine)
> >      DriveInfo *hd[MAX_IDE_BUS * MAX_IDE_DEVS];
> >      int i;
> >  
> > -    /*
> > -     * There is a small chance that someone unintentionally passes "-cpu max"
> > -     * for the isapc machine, which will provide a much more modern 32-bit
> > -     * CPU than would be expected for an ISA-era PC. If the "max" cpu type has
> > -     * been specified, choose the "best" 32-bit cpu possible which we consider
> > -     * be the pentium3 (deliberately choosing an Intel CPU given that the
> > -     * default 486 CPU for the isapc machine is also an Intel CPU).
> > -     */
> > -    if (!strcmp(machine->cpu_type, X86_CPU_TYPE_NAME("max"))) {
> > -        machine->cpu_type = X86_CPU_TYPE_NAME("pentium3");
> > -        warn_report("-cpu max is invalid for isapc machine, using pentium3");
> > -    }
> > -
> > -    /*
> > -     * Similarly if someone unintentionally passes "-cpu host" for the isapc
> > -     * machine then display a warning and also switch to the "best" 32-bit
> > -     * cpu possible which we consider to be the pentium3. This is because any
> > -     * host CPU will already be modern than this, but it also ensures any
> > -     * newer CPU flags/features are filtered out for older guests.
> > -     */
> > -    if (!strcmp(machine->cpu_type, X86_CPU_TYPE_NAME("host"))) {
> > -        machine->cpu_type = X86_CPU_TYPE_NAME("pentium3");
> > -        warn_report("-cpu host is invalid for isapc machine, using pentium3");
> > -    }
> > -
> >      if (machine->ram_size > 3.5 * GiB) {
> >          error_report("Too much memory for this machine: %" PRId64 " MiB, "
> >                       "maximum 3584 MiB", machine->ram_size / MiB);
> > @@ -162,8 +137,6 @@ static void isapc_machine_options(MachineClass *m)
> >          X86_CPU_TYPE_NAME("pentium2"),
> >          X86_CPU_TYPE_NAME("pentium3"),
> >          X86_CPU_TYPE_NAME("qemu32"),
> > -        X86_CPU_TYPE_NAME("max"),
> > -        X86_CPU_TYPE_NAME("host"),
> >          NULL
> >      };
> >      PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
> 
> This reverts the "smart" part of recent
> 
> commit e1e2909f8e74051a34a044940f90d4650b6e784a
> Author: Mark Cave-Ayland <mark.caveayland@nutanix.com>
> Date:   Thu Aug 28 12:09:44 2025 +0100
> 
>     hw/i386/pc_piix.c: restrict isapc machine to 32-bit CPUs
>     
>     The isapc machine represents a legacy ISA PC with a 486 CPU. Whilst it is
>     possible to specify any CPU via -cpu on the command line, it makes no
>     sense to allow modern 64-bit CPUs to be used.
>     
>     Restrict the isapc machine to the available 32-bit CPUs, taking care to
>     handle the case where if a user inadvertently uses either -cpu max or
>     -cpu host then the "best" 32-bit CPU is used (in this case the pentium3).

What is written here made sense from the POV of use of isapc with
qemu-system-x86_64, but in qemu-system-i686, both 'max' and 'host'
where already 32-bit CPUs IIUC. Both this original patch and
the new patch block them from being used in qemu-system-i686
which feels wrong given the justification above.


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

Re: [PATCH v2 1/2] hw/i386/isapc.c: remove support for -cpu host and -cpu max

[Mark Cave-Ayland]

On 26/09/2025 13:39, Daniel P. Berrangé wrote:

> On Fri, Sep 26, 2025 at 01:36:25PM +0200, Markus Armbruster wrote:
>> Mark Cave-Ayland <mark.caveayland@nutanix.com> writes:
>>
>>> Following recent discussions on the mailing list, it has been decided
>>> that instead of mapping -cpu host and -cpu max to a suitable 32-bit x86 CPU,
>>> it is preferable to disallow them and use the existing valid_cpu_types
>>> validation logic so that an error is returned to the user instead.
>>>
>>> Signed-off-by: Mark Cave-Ayland <mark.caveayland@nutanix.com>
>>> ---
>>>   hw/i386/isapc.c | 27 ---------------------------
>>>   1 file changed, 27 deletions(-)
>>>
>>> diff --git a/hw/i386/isapc.c b/hw/i386/isapc.c
>>> index 44f4a44672..6c35a397df 100644
>>> --- a/hw/i386/isapc.c
>>> +++ b/hw/i386/isapc.c
>>> @@ -41,31 +41,6 @@ static void pc_init_isa(MachineState *machine)
>>>       DriveInfo *hd[MAX_IDE_BUS * MAX_IDE_DEVS];
>>>       int i;
>>>   
>>> -    /*
>>> -     * There is a small chance that someone unintentionally passes "-cpu max"
>>> -     * for the isapc machine, which will provide a much more modern 32-bit
>>> -     * CPU than would be expected for an ISA-era PC. If the "max" cpu type has
>>> -     * been specified, choose the "best" 32-bit cpu possible which we consider
>>> -     * be the pentium3 (deliberately choosing an Intel CPU given that the
>>> -     * default 486 CPU for the isapc machine is also an Intel CPU).
>>> -     */
>>> -    if (!strcmp(machine->cpu_type, X86_CPU_TYPE_NAME("max"))) {
>>> -        machine->cpu_type = X86_CPU_TYPE_NAME("pentium3");
>>> -        warn_report("-cpu max is invalid for isapc machine, using pentium3");
>>> -    }
>>> -
>>> -    /*
>>> -     * Similarly if someone unintentionally passes "-cpu host" for the isapc
>>> -     * machine then display a warning and also switch to the "best" 32-bit
>>> -     * cpu possible which we consider to be the pentium3. This is because any
>>> -     * host CPU will already be modern than this, but it also ensures any
>>> -     * newer CPU flags/features are filtered out for older guests.
>>> -     */
>>> -    if (!strcmp(machine->cpu_type, X86_CPU_TYPE_NAME("host"))) {
>>> -        machine->cpu_type = X86_CPU_TYPE_NAME("pentium3");
>>> -        warn_report("-cpu host is invalid for isapc machine, using pentium3");
>>> -    }
>>> -
>>>       if (machine->ram_size > 3.5 * GiB) {
>>>           error_report("Too much memory for this machine: %" PRId64 " MiB, "
>>>                        "maximum 3584 MiB", machine->ram_size / MiB);
>>> @@ -162,8 +137,6 @@ static void isapc_machine_options(MachineClass *m)
>>>           X86_CPU_TYPE_NAME("pentium2"),
>>>           X86_CPU_TYPE_NAME("pentium3"),
>>>           X86_CPU_TYPE_NAME("qemu32"),
>>> -        X86_CPU_TYPE_NAME("max"),
>>> -        X86_CPU_TYPE_NAME("host"),
>>>           NULL
>>>       };
>>>       PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
>>
>> This reverts the "smart" part of recent
>>
>> commit e1e2909f8e74051a34a044940f90d4650b6e784a
>> Author: Mark Cave-Ayland <mark.caveayland@nutanix.com>
>> Date:   Thu Aug 28 12:09:44 2025 +0100
>>
>>      hw/i386/pc_piix.c: restrict isapc machine to 32-bit CPUs
>>      
>>      The isapc machine represents a legacy ISA PC with a 486 CPU. Whilst it is
>>      possible to specify any CPU via -cpu on the command line, it makes no
>>      sense to allow modern 64-bit CPUs to be used.
>>      
>>      Restrict the isapc machine to the available 32-bit CPUs, taking care to
>>      handle the case where if a user inadvertently uses either -cpu max or
>>      -cpu host then the "best" 32-bit CPU is used (in this case the pentium3).
> 
> What is written here made sense from the POV of use of isapc with
> qemu-system-x86_64, but in qemu-system-i686, both 'max' and 'host'
> where already 32-bit CPUs IIUC. Both this original patch and
> the new patch block them from being used in qemu-system-i686
> which feels wrong given the justification above.

I tried stepping through with -cpu host/-cpu max on qemu-system-i386 and 
it's a bit confusing: I think we end up with some kind of custom AMD 
vendor CPU but with LM disabled. I can't easily see a way to understand 
what features are currently enabled?

I must admit I'm struggling to see the usefulness of -cpu host/-cpu max 
for isapc given that older OSs can be quite picky when it comes to hardware.


ATB,

Mark.

Re: [PATCH v2 1/2] hw/i386/isapc.c: remove support for -cpu host and -cpu max

[Daniel P. Berrangé]

On Fri, Sep 26, 2025 at 02:49:00PM +0100, Mark Cave-Ayland wrote:
> On 26/09/2025 13:39, Daniel P. Berrangé wrote:
> 
> > On Fri, Sep 26, 2025 at 01:36:25PM +0200, Markus Armbruster wrote:
> > > Mark Cave-Ayland <mark.caveayland@nutanix.com> writes:
> > > 
> > > > Following recent discussions on the mailing list, it has been decided
> > > > that instead of mapping -cpu host and -cpu max to a suitable 32-bit x86 CPU,
> > > > it is preferable to disallow them and use the existing valid_cpu_types
> > > > validation logic so that an error is returned to the user instead.
> > > > 
> > > > Signed-off-by: Mark Cave-Ayland <mark.caveayland@nutanix.com>
> > > > ---
> > > >   hw/i386/isapc.c | 27 ---------------------------
> > > >   1 file changed, 27 deletions(-)
> > > > 
> > > > diff --git a/hw/i386/isapc.c b/hw/i386/isapc.c
> > > > index 44f4a44672..6c35a397df 100644
> > > > --- a/hw/i386/isapc.c
> > > > +++ b/hw/i386/isapc.c
> > > > @@ -41,31 +41,6 @@ static void pc_init_isa(MachineState *machine)
> > > >       DriveInfo *hd[MAX_IDE_BUS * MAX_IDE_DEVS];
> > > >       int i;
> > > > -    /*
> > > > -     * There is a small chance that someone unintentionally passes "-cpu max"
> > > > -     * for the isapc machine, which will provide a much more modern 32-bit
> > > > -     * CPU than would be expected for an ISA-era PC. If the "max" cpu type has
> > > > -     * been specified, choose the "best" 32-bit cpu possible which we consider
> > > > -     * be the pentium3 (deliberately choosing an Intel CPU given that the
> > > > -     * default 486 CPU for the isapc machine is also an Intel CPU).
> > > > -     */
> > > > -    if (!strcmp(machine->cpu_type, X86_CPU_TYPE_NAME("max"))) {
> > > > -        machine->cpu_type = X86_CPU_TYPE_NAME("pentium3");
> > > > -        warn_report("-cpu max is invalid for isapc machine, using pentium3");
> > > > -    }
> > > > -
> > > > -    /*
> > > > -     * Similarly if someone unintentionally passes "-cpu host" for the isapc
> > > > -     * machine then display a warning and also switch to the "best" 32-bit
> > > > -     * cpu possible which we consider to be the pentium3. This is because any
> > > > -     * host CPU will already be modern than this, but it also ensures any
> > > > -     * newer CPU flags/features are filtered out for older guests.
> > > > -     */
> > > > -    if (!strcmp(machine->cpu_type, X86_CPU_TYPE_NAME("host"))) {
> > > > -        machine->cpu_type = X86_CPU_TYPE_NAME("pentium3");
> > > > -        warn_report("-cpu host is invalid for isapc machine, using pentium3");
> > > > -    }
> > > > -
> > > >       if (machine->ram_size > 3.5 * GiB) {
> > > >           error_report("Too much memory for this machine: %" PRId64 " MiB, "
> > > >                        "maximum 3584 MiB", machine->ram_size / MiB);
> > > > @@ -162,8 +137,6 @@ static void isapc_machine_options(MachineClass *m)
> > > >           X86_CPU_TYPE_NAME("pentium2"),
> > > >           X86_CPU_TYPE_NAME("pentium3"),
> > > >           X86_CPU_TYPE_NAME("qemu32"),
> > > > -        X86_CPU_TYPE_NAME("max"),
> > > > -        X86_CPU_TYPE_NAME("host"),
> > > >           NULL
> > > >       };
> > > >       PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
> > > 
> > > This reverts the "smart" part of recent
> > > 
> > > commit e1e2909f8e74051a34a044940f90d4650b6e784a
> > > Author: Mark Cave-Ayland <mark.caveayland@nutanix.com>
> > > Date:   Thu Aug 28 12:09:44 2025 +0100
> > > 
> > >      hw/i386/pc_piix.c: restrict isapc machine to 32-bit CPUs
> > >      The isapc machine represents a legacy ISA PC with a 486 CPU. Whilst it is
> > >      possible to specify any CPU via -cpu on the command line, it makes no
> > >      sense to allow modern 64-bit CPUs to be used.
> > >      Restrict the isapc machine to the available 32-bit CPUs, taking care to
> > >      handle the case where if a user inadvertently uses either -cpu max or
> > >      -cpu host then the "best" 32-bit CPU is used (in this case the pentium3).
> > 
> > What is written here made sense from the POV of use of isapc with
> > qemu-system-x86_64, but in qemu-system-i686, both 'max' and 'host'
> > where already 32-bit CPUs IIUC. Both this original patch and
> > the new patch block them from being used in qemu-system-i686
> > which feels wrong given the justification above.
> 
> I tried stepping through with -cpu host/-cpu max on qemu-system-i386 and
> it's a bit confusing: I think we end up with some kind of custom AMD vendor
> CPU but with LM disabled. I can't easily see a way to understand what
> features are currently enabled?
> 
> I must admit I'm struggling to see the usefulness of -cpu host/-cpu max for
> isapc given that older OSs can be quite picky when it comes to hardware.

But x86 CPU vendors go to ridiculous levels of complexity to retain
historical back compat over many decades. If anything, I'd be surprised
about the opposite - an OS that didn't work with -cpu max.


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

Re: [PATCH v2 1/2] hw/i386/isapc.c: remove support for -cpu host and -cpu max

[Mark Cave-Ayland]

On 26/09/2025 14:55, Daniel P. Berrangé wrote:

> On Fri, Sep 26, 2025 at 02:49:00PM +0100, Mark Cave-Ayland wrote:
>> On 26/09/2025 13:39, Daniel P. Berrangé wrote:
>>
>>> On Fri, Sep 26, 2025 at 01:36:25PM +0200, Markus Armbruster wrote:
>>>> Mark Cave-Ayland <mark.caveayland@nutanix.com> writes:
>>>>
>>>>> Following recent discussions on the mailing list, it has been decided
>>>>> that instead of mapping -cpu host and -cpu max to a suitable 32-bit x86 CPU,
>>>>> it is preferable to disallow them and use the existing valid_cpu_types
>>>>> validation logic so that an error is returned to the user instead.
>>>>>
>>>>> Signed-off-by: Mark Cave-Ayland <mark.caveayland@nutanix.com>
>>>>> ---
>>>>>    hw/i386/isapc.c | 27 ---------------------------
>>>>>    1 file changed, 27 deletions(-)
>>>>>
>>>>> diff --git a/hw/i386/isapc.c b/hw/i386/isapc.c
>>>>> index 44f4a44672..6c35a397df 100644
>>>>> --- a/hw/i386/isapc.c
>>>>> +++ b/hw/i386/isapc.c
>>>>> @@ -41,31 +41,6 @@ static void pc_init_isa(MachineState *machine)
>>>>>        DriveInfo *hd[MAX_IDE_BUS * MAX_IDE_DEVS];
>>>>>        int i;
>>>>> -    /*
>>>>> -     * There is a small chance that someone unintentionally passes "-cpu max"
>>>>> -     * for the isapc machine, which will provide a much more modern 32-bit
>>>>> -     * CPU than would be expected for an ISA-era PC. If the "max" cpu type has
>>>>> -     * been specified, choose the "best" 32-bit cpu possible which we consider
>>>>> -     * be the pentium3 (deliberately choosing an Intel CPU given that the
>>>>> -     * default 486 CPU for the isapc machine is also an Intel CPU).
>>>>> -     */
>>>>> -    if (!strcmp(machine->cpu_type, X86_CPU_TYPE_NAME("max"))) {
>>>>> -        machine->cpu_type = X86_CPU_TYPE_NAME("pentium3");
>>>>> -        warn_report("-cpu max is invalid for isapc machine, using pentium3");
>>>>> -    }
>>>>> -
>>>>> -    /*
>>>>> -     * Similarly if someone unintentionally passes "-cpu host" for the isapc
>>>>> -     * machine then display a warning and also switch to the "best" 32-bit
>>>>> -     * cpu possible which we consider to be the pentium3. This is because any
>>>>> -     * host CPU will already be modern than this, but it also ensures any
>>>>> -     * newer CPU flags/features are filtered out for older guests.
>>>>> -     */
>>>>> -    if (!strcmp(machine->cpu_type, X86_CPU_TYPE_NAME("host"))) {
>>>>> -        machine->cpu_type = X86_CPU_TYPE_NAME("pentium3");
>>>>> -        warn_report("-cpu host is invalid for isapc machine, using pentium3");
>>>>> -    }
>>>>> -
>>>>>        if (machine->ram_size > 3.5 * GiB) {
>>>>>            error_report("Too much memory for this machine: %" PRId64 " MiB, "
>>>>>                         "maximum 3584 MiB", machine->ram_size / MiB);
>>>>> @@ -162,8 +137,6 @@ static void isapc_machine_options(MachineClass *m)
>>>>>            X86_CPU_TYPE_NAME("pentium2"),
>>>>>            X86_CPU_TYPE_NAME("pentium3"),
>>>>>            X86_CPU_TYPE_NAME("qemu32"),
>>>>> -        X86_CPU_TYPE_NAME("max"),
>>>>> -        X86_CPU_TYPE_NAME("host"),
>>>>>            NULL
>>>>>        };
>>>>>        PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
>>>>
>>>> This reverts the "smart" part of recent
>>>>
>>>> commit e1e2909f8e74051a34a044940f90d4650b6e784a
>>>> Author: Mark Cave-Ayland <mark.caveayland@nutanix.com>
>>>> Date:   Thu Aug 28 12:09:44 2025 +0100
>>>>
>>>>       hw/i386/pc_piix.c: restrict isapc machine to 32-bit CPUs
>>>>       The isapc machine represents a legacy ISA PC with a 486 CPU. Whilst it is
>>>>       possible to specify any CPU via -cpu on the command line, it makes no
>>>>       sense to allow modern 64-bit CPUs to be used.
>>>>       Restrict the isapc machine to the available 32-bit CPUs, taking care to
>>>>       handle the case where if a user inadvertently uses either -cpu max or
>>>>       -cpu host then the "best" 32-bit CPU is used (in this case the pentium3).
>>>
>>> What is written here made sense from the POV of use of isapc with
>>> qemu-system-x86_64, but in qemu-system-i686, both 'max' and 'host'
>>> where already 32-bit CPUs IIUC. Both this original patch and
>>> the new patch block them from being used in qemu-system-i686
>>> which feels wrong given the justification above.
>>
>> I tried stepping through with -cpu host/-cpu max on qemu-system-i386 and
>> it's a bit confusing: I think we end up with some kind of custom AMD vendor
>> CPU but with LM disabled. I can't easily see a way to understand what
>> features are currently enabled?
>>
>> I must admit I'm struggling to see the usefulness of -cpu host/-cpu max for
>> isapc given that older OSs can be quite picky when it comes to hardware.
> 
> But x86 CPU vendors go to ridiculous levels of complexity to retain
> historical back compat over many decades. If anything, I'd be surprised
> about the opposite - an OS that didn't work with -cpu max.

It's not the CPU vendor I'd be worried about, but the OS vendor who may 
for example execute CPUID and become confused if it returns an AMD 
vendor ID instead of an Intel vendor ID.

What do you think is the best way forward? I'm still not convinced of 
the utility of -cpu host/-cpu max for isapc, so what if instead of 
mapping them to the pentium3 CPU we follow the standard deprecation path 
and emit a warning on startup, and then remove them from valid_cpu_types 
in 2 releases time? The advantage to this approach is that if people are 
actually using -cpu host/-cpu max with the isapc machine then they would 
at least file an issue in Gitlab and make us aware of it.


ATB,

Mark.

Re: [PATCH v2 1/2] hw/i386/isapc.c: remove support for -cpu host and -cpu max

[Daniel P. Berrangé]

On Fri, Sep 26, 2025 at 04:01:23PM +0100, Mark Cave-Ayland wrote:
> On 26/09/2025 14:55, Daniel P. Berrangé wrote:
> 
> > On Fri, Sep 26, 2025 at 02:49:00PM +0100, Mark Cave-Ayland wrote:
> > > On 26/09/2025 13:39, Daniel P. Berrangé wrote:
> > > 
> > > > On Fri, Sep 26, 2025 at 01:36:25PM +0200, Markus Armbruster wrote:
> > > > > Mark Cave-Ayland <mark.caveayland@nutanix.com> writes:
> > > > > 
> > > > > > Following recent discussions on the mailing list, it has been decided
> > > > > > that instead of mapping -cpu host and -cpu max to a suitable 32-bit x86 CPU,
> > > > > > it is preferable to disallow them and use the existing valid_cpu_types
> > > > > > validation logic so that an error is returned to the user instead.
> > > > > > 
> > > > > > Signed-off-by: Mark Cave-Ayland <mark.caveayland@nutanix.com>
> > > > > > ---
> > > > > >    hw/i386/isapc.c | 27 ---------------------------
> > > > > >    1 file changed, 27 deletions(-)
> > > > > > 
> > > > > > diff --git a/hw/i386/isapc.c b/hw/i386/isapc.c
> > > > > > index 44f4a44672..6c35a397df 100644
> > > > > > --- a/hw/i386/isapc.c
> > > > > > +++ b/hw/i386/isapc.c
> > > > > > @@ -41,31 +41,6 @@ static void pc_init_isa(MachineState *machine)
> > > > > >        DriveInfo *hd[MAX_IDE_BUS * MAX_IDE_DEVS];
> > > > > >        int i;
> > > > > > -    /*
> > > > > > -     * There is a small chance that someone unintentionally passes "-cpu max"
> > > > > > -     * for the isapc machine, which will provide a much more modern 32-bit
> > > > > > -     * CPU than would be expected for an ISA-era PC. If the "max" cpu type has
> > > > > > -     * been specified, choose the "best" 32-bit cpu possible which we consider
> > > > > > -     * be the pentium3 (deliberately choosing an Intel CPU given that the
> > > > > > -     * default 486 CPU for the isapc machine is also an Intel CPU).
> > > > > > -     */
> > > > > > -    if (!strcmp(machine->cpu_type, X86_CPU_TYPE_NAME("max"))) {
> > > > > > -        machine->cpu_type = X86_CPU_TYPE_NAME("pentium3");
> > > > > > -        warn_report("-cpu max is invalid for isapc machine, using pentium3");
> > > > > > -    }
> > > > > > -
> > > > > > -    /*
> > > > > > -     * Similarly if someone unintentionally passes "-cpu host" for the isapc
> > > > > > -     * machine then display a warning and also switch to the "best" 32-bit
> > > > > > -     * cpu possible which we consider to be the pentium3. This is because any
> > > > > > -     * host CPU will already be modern than this, but it also ensures any
> > > > > > -     * newer CPU flags/features are filtered out for older guests.
> > > > > > -     */
> > > > > > -    if (!strcmp(machine->cpu_type, X86_CPU_TYPE_NAME("host"))) {
> > > > > > -        machine->cpu_type = X86_CPU_TYPE_NAME("pentium3");
> > > > > > -        warn_report("-cpu host is invalid for isapc machine, using pentium3");
> > > > > > -    }
> > > > > > -
> > > > > >        if (machine->ram_size > 3.5 * GiB) {
> > > > > >            error_report("Too much memory for this machine: %" PRId64 " MiB, "
> > > > > >                         "maximum 3584 MiB", machine->ram_size / MiB);
> > > > > > @@ -162,8 +137,6 @@ static void isapc_machine_options(MachineClass *m)
> > > > > >            X86_CPU_TYPE_NAME("pentium2"),
> > > > > >            X86_CPU_TYPE_NAME("pentium3"),
> > > > > >            X86_CPU_TYPE_NAME("qemu32"),
> > > > > > -        X86_CPU_TYPE_NAME("max"),
> > > > > > -        X86_CPU_TYPE_NAME("host"),
> > > > > >            NULL
> > > > > >        };
> > > > > >        PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
> > > > > 
> > > > > This reverts the "smart" part of recent
> > > > > 
> > > > > commit e1e2909f8e74051a34a044940f90d4650b6e784a
> > > > > Author: Mark Cave-Ayland <mark.caveayland@nutanix.com>
> > > > > Date:   Thu Aug 28 12:09:44 2025 +0100
> > > > > 
> > > > >       hw/i386/pc_piix.c: restrict isapc machine to 32-bit CPUs
> > > > >       The isapc machine represents a legacy ISA PC with a 486 CPU. Whilst it is
> > > > >       possible to specify any CPU via -cpu on the command line, it makes no
> > > > >       sense to allow modern 64-bit CPUs to be used.
> > > > >       Restrict the isapc machine to the available 32-bit CPUs, taking care to
> > > > >       handle the case where if a user inadvertently uses either -cpu max or
> > > > >       -cpu host then the "best" 32-bit CPU is used (in this case the pentium3).
> > > > 
> > > > What is written here made sense from the POV of use of isapc with
> > > > qemu-system-x86_64, but in qemu-system-i686, both 'max' and 'host'
> > > > where already 32-bit CPUs IIUC. Both this original patch and
> > > > the new patch block them from being used in qemu-system-i686
> > > > which feels wrong given the justification above.
> > > 
> > > I tried stepping through with -cpu host/-cpu max on qemu-system-i386 and
> > > it's a bit confusing: I think we end up with some kind of custom AMD vendor
> > > CPU but with LM disabled. I can't easily see a way to understand what
> > > features are currently enabled?
> > > 
> > > I must admit I'm struggling to see the usefulness of -cpu host/-cpu max for
> > > isapc given that older OSs can be quite picky when it comes to hardware.
> > 
> > But x86 CPU vendors go to ridiculous levels of complexity to retain
> > historical back compat over many decades. If anything, I'd be surprised
> > about the opposite - an OS that didn't work with -cpu max.
> 
> It's not the CPU vendor I'd be worried about, but the OS vendor who may for
> example execute CPUID and become confused if it returns an AMD vendor ID
> instead of an Intel vendor ID.

IIRC/IIUC, AMD sold i486 CPUs with CPUID present in the ISA era, so I
would have thought anything checking vendor ID should expect to see
more than just Intel ?

> What do you think is the best way forward? I'm still not convinced of the
> utility of -cpu host/-cpu max for isapc, so what if instead of mapping them
> to the pentium3 CPU we follow the standard deprecation path and emit a
> warning on startup, and then remove them from valid_cpu_types in 2 releases
> time? The advantage to this approach is that if people are actually using
> -cpu host/-cpu max with the isapc machine then they would at least file an
> issue in Gitlab and make us aware of it.

If we want to deprecate it the formal route, that's fine.

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

Re: [PATCH v2 1/2] hw/i386/isapc.c: remove support for -cpu host and -cpu max

[Mark Cave-Ayland]

On 26/09/2025 16:12, Daniel P. Berrangé wrote:

> On Fri, Sep 26, 2025 at 04:01:23PM +0100, Mark Cave-Ayland wrote:
>> On 26/09/2025 14:55, Daniel P. Berrangé wrote:
>>
>>> On Fri, Sep 26, 2025 at 02:49:00PM +0100, Mark Cave-Ayland wrote:
>>>> On 26/09/2025 13:39, Daniel P. Berrangé wrote:
>>>>
>>>>> On Fri, Sep 26, 2025 at 01:36:25PM +0200, Markus Armbruster wrote:
>>>>>> Mark Cave-Ayland <mark.caveayland@nutanix.com> writes:
>>>>>>
>>>>>>> Following recent discussions on the mailing list, it has been decided
>>>>>>> that instead of mapping -cpu host and -cpu max to a suitable 32-bit x86 CPU,
>>>>>>> it is preferable to disallow them and use the existing valid_cpu_types
>>>>>>> validation logic so that an error is returned to the user instead.
>>>>>>>
>>>>>>> Signed-off-by: Mark Cave-Ayland <mark.caveayland@nutanix.com>
>>>>>>> ---
>>>>>>>     hw/i386/isapc.c | 27 ---------------------------
>>>>>>>     1 file changed, 27 deletions(-)
>>>>>>>
>>>>>>> diff --git a/hw/i386/isapc.c b/hw/i386/isapc.c
>>>>>>> index 44f4a44672..6c35a397df 100644
>>>>>>> --- a/hw/i386/isapc.c
>>>>>>> +++ b/hw/i386/isapc.c
>>>>>>> @@ -41,31 +41,6 @@ static void pc_init_isa(MachineState *machine)
>>>>>>>         DriveInfo *hd[MAX_IDE_BUS * MAX_IDE_DEVS];
>>>>>>>         int i;
>>>>>>> -    /*
>>>>>>> -     * There is a small chance that someone unintentionally passes "-cpu max"
>>>>>>> -     * for the isapc machine, which will provide a much more modern 32-bit
>>>>>>> -     * CPU than would be expected for an ISA-era PC. If the "max" cpu type has
>>>>>>> -     * been specified, choose the "best" 32-bit cpu possible which we consider
>>>>>>> -     * be the pentium3 (deliberately choosing an Intel CPU given that the
>>>>>>> -     * default 486 CPU for the isapc machine is also an Intel CPU).
>>>>>>> -     */
>>>>>>> -    if (!strcmp(machine->cpu_type, X86_CPU_TYPE_NAME("max"))) {
>>>>>>> -        machine->cpu_type = X86_CPU_TYPE_NAME("pentium3");
>>>>>>> -        warn_report("-cpu max is invalid for isapc machine, using pentium3");
>>>>>>> -    }
>>>>>>> -
>>>>>>> -    /*
>>>>>>> -     * Similarly if someone unintentionally passes "-cpu host" for the isapc
>>>>>>> -     * machine then display a warning and also switch to the "best" 32-bit
>>>>>>> -     * cpu possible which we consider to be the pentium3. This is because any
>>>>>>> -     * host CPU will already be modern than this, but it also ensures any
>>>>>>> -     * newer CPU flags/features are filtered out for older guests.
>>>>>>> -     */
>>>>>>> -    if (!strcmp(machine->cpu_type, X86_CPU_TYPE_NAME("host"))) {
>>>>>>> -        machine->cpu_type = X86_CPU_TYPE_NAME("pentium3");
>>>>>>> -        warn_report("-cpu host is invalid for isapc machine, using pentium3");
>>>>>>> -    }
>>>>>>> -
>>>>>>>         if (machine->ram_size > 3.5 * GiB) {
>>>>>>>             error_report("Too much memory for this machine: %" PRId64 " MiB, "
>>>>>>>                          "maximum 3584 MiB", machine->ram_size / MiB);
>>>>>>> @@ -162,8 +137,6 @@ static void isapc_machine_options(MachineClass *m)
>>>>>>>             X86_CPU_TYPE_NAME("pentium2"),
>>>>>>>             X86_CPU_TYPE_NAME("pentium3"),
>>>>>>>             X86_CPU_TYPE_NAME("qemu32"),
>>>>>>> -        X86_CPU_TYPE_NAME("max"),
>>>>>>> -        X86_CPU_TYPE_NAME("host"),
>>>>>>>             NULL
>>>>>>>         };
>>>>>>>         PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
>>>>>>
>>>>>> This reverts the "smart" part of recent
>>>>>>
>>>>>> commit e1e2909f8e74051a34a044940f90d4650b6e784a
>>>>>> Author: Mark Cave-Ayland <mark.caveayland@nutanix.com>
>>>>>> Date:   Thu Aug 28 12:09:44 2025 +0100
>>>>>>
>>>>>>        hw/i386/pc_piix.c: restrict isapc machine to 32-bit CPUs
>>>>>>        The isapc machine represents a legacy ISA PC with a 486 CPU. Whilst it is
>>>>>>        possible to specify any CPU via -cpu on the command line, it makes no
>>>>>>        sense to allow modern 64-bit CPUs to be used.
>>>>>>        Restrict the isapc machine to the available 32-bit CPUs, taking care to
>>>>>>        handle the case where if a user inadvertently uses either -cpu max or
>>>>>>        -cpu host then the "best" 32-bit CPU is used (in this case the pentium3).
>>>>>
>>>>> What is written here made sense from the POV of use of isapc with
>>>>> qemu-system-x86_64, but in qemu-system-i686, both 'max' and 'host'
>>>>> where already 32-bit CPUs IIUC. Both this original patch and
>>>>> the new patch block them from being used in qemu-system-i686
>>>>> which feels wrong given the justification above.
>>>>
>>>> I tried stepping through with -cpu host/-cpu max on qemu-system-i386 and
>>>> it's a bit confusing: I think we end up with some kind of custom AMD vendor
>>>> CPU but with LM disabled. I can't easily see a way to understand what
>>>> features are currently enabled?
>>>>
>>>> I must admit I'm struggling to see the usefulness of -cpu host/-cpu max for
>>>> isapc given that older OSs can be quite picky when it comes to hardware.
>>>
>>> But x86 CPU vendors go to ridiculous levels of complexity to retain
>>> historical back compat over many decades. If anything, I'd be surprised
>>> about the opposite - an OS that didn't work with -cpu max.
>>
>> It's not the CPU vendor I'd be worried about, but the OS vendor who may for
>> example execute CPUID and become confused if it returns an AMD vendor ID
>> instead of an Intel vendor ID.
> 
> IIRC/IIUC, AMD sold i486 CPUs with CPUID present in the ISA era, so I
> would have thought anything checking vendor ID should expect to see
> more than just Intel ?

Unfortunately I don't remember the specifics, but I have a vague memory 
that someone has mentioned this to me in the past.
>> What do you think is the best way forward? I'm still not convinced of the
>> utility of -cpu host/-cpu max for isapc, so what if instead of mapping them
>> to the pentium3 CPU we follow the standard deprecation path and emit a
>> warning on startup, and then remove them from valid_cpu_types in 2 releases
>> time? The advantage to this approach is that if people are actually using
>> -cpu host/-cpu max with the isapc machine then they would at least file an
>> issue in Gitlab and make us aware of it.
> 
> If we want to deprecate it the formal route, that's fine.

Works for me. Igor, any objections?


ATB,

Mark.

Re: [PATCH v2 1/2] hw/i386/isapc.c: remove support for -cpu host and -cpu max

[Igor Mammedov]

On Fri, 26 Sep 2025 16:22:31 +0100
Mark Cave-Ayland <mark.caveayland@nutanix.com> wrote:

> On 26/09/2025 16:12, Daniel P. Berrangé wrote:
> 
> > On Fri, Sep 26, 2025 at 04:01:23PM +0100, Mark Cave-Ayland wrote:  
> >> On 26/09/2025 14:55, Daniel P. Berrangé wrote:
> >>  
> >>> On Fri, Sep 26, 2025 at 02:49:00PM +0100, Mark Cave-Ayland wrote:  
> >>>> On 26/09/2025 13:39, Daniel P. Berrangé wrote:
> >>>>  
> >>>>> On Fri, Sep 26, 2025 at 01:36:25PM +0200, Markus Armbruster wrote:  
> >>>>>> Mark Cave-Ayland <mark.caveayland@nutanix.com> writes:
> >>>>>>  
> >>>>>>> Following recent discussions on the mailing list, it has been decided
> >>>>>>> that instead of mapping -cpu host and -cpu max to a suitable 32-bit x86 CPU,
> >>>>>>> it is preferable to disallow them and use the existing valid_cpu_types
> >>>>>>> validation logic so that an error is returned to the user instead.
> >>>>>>>
> >>>>>>> Signed-off-by: Mark Cave-Ayland <mark.caveayland@nutanix.com>
> >>>>>>> ---
> >>>>>>>     hw/i386/isapc.c | 27 ---------------------------
> >>>>>>>     1 file changed, 27 deletions(-)
> >>>>>>>
> >>>>>>> diff --git a/hw/i386/isapc.c b/hw/i386/isapc.c
> >>>>>>> index 44f4a44672..6c35a397df 100644
> >>>>>>> --- a/hw/i386/isapc.c
> >>>>>>> +++ b/hw/i386/isapc.c
> >>>>>>> @@ -41,31 +41,6 @@ static void pc_init_isa(MachineState *machine)
> >>>>>>>         DriveInfo *hd[MAX_IDE_BUS * MAX_IDE_DEVS];
> >>>>>>>         int i;
> >>>>>>> -    /*
> >>>>>>> -     * There is a small chance that someone unintentionally passes "-cpu max"
> >>>>>>> -     * for the isapc machine, which will provide a much more modern 32-bit
> >>>>>>> -     * CPU than would be expected for an ISA-era PC. If the "max" cpu type has
> >>>>>>> -     * been specified, choose the "best" 32-bit cpu possible which we consider
> >>>>>>> -     * be the pentium3 (deliberately choosing an Intel CPU given that the
> >>>>>>> -     * default 486 CPU for the isapc machine is also an Intel CPU).
> >>>>>>> -     */
> >>>>>>> -    if (!strcmp(machine->cpu_type, X86_CPU_TYPE_NAME("max"))) {
> >>>>>>> -        machine->cpu_type = X86_CPU_TYPE_NAME("pentium3");
> >>>>>>> -        warn_report("-cpu max is invalid for isapc machine, using pentium3");
> >>>>>>> -    }
> >>>>>>> -
> >>>>>>> -    /*
> >>>>>>> -     * Similarly if someone unintentionally passes "-cpu host" for the isapc
> >>>>>>> -     * machine then display a warning and also switch to the "best" 32-bit
> >>>>>>> -     * cpu possible which we consider to be the pentium3. This is because any
> >>>>>>> -     * host CPU will already be modern than this, but it also ensures any
> >>>>>>> -     * newer CPU flags/features are filtered out for older guests.
> >>>>>>> -     */
> >>>>>>> -    if (!strcmp(machine->cpu_type, X86_CPU_TYPE_NAME("host"))) {
> >>>>>>> -        machine->cpu_type = X86_CPU_TYPE_NAME("pentium3");
> >>>>>>> -        warn_report("-cpu host is invalid for isapc machine, using pentium3");
> >>>>>>> -    }
> >>>>>>> -
> >>>>>>>         if (machine->ram_size > 3.5 * GiB) {
> >>>>>>>             error_report("Too much memory for this machine: %" PRId64 " MiB, "
> >>>>>>>                          "maximum 3584 MiB", machine->ram_size / MiB);
> >>>>>>> @@ -162,8 +137,6 @@ static void isapc_machine_options(MachineClass *m)
> >>>>>>>             X86_CPU_TYPE_NAME("pentium2"),
> >>>>>>>             X86_CPU_TYPE_NAME("pentium3"),
> >>>>>>>             X86_CPU_TYPE_NAME("qemu32"),
> >>>>>>> -        X86_CPU_TYPE_NAME("max"),
> >>>>>>> -        X86_CPU_TYPE_NAME("host"),
> >>>>>>>             NULL
> >>>>>>>         };
> >>>>>>>         PCMachineClass *pcmc = PC_MACHINE_CLASS(m);  
> >>>>>>
> >>>>>> This reverts the "smart" part of recent
> >>>>>>
> >>>>>> commit e1e2909f8e74051a34a044940f90d4650b6e784a
> >>>>>> Author: Mark Cave-Ayland <mark.caveayland@nutanix.com>
> >>>>>> Date:   Thu Aug 28 12:09:44 2025 +0100
> >>>>>>
> >>>>>>        hw/i386/pc_piix.c: restrict isapc machine to 32-bit CPUs
> >>>>>>        The isapc machine represents a legacy ISA PC with a 486 CPU. Whilst it is
> >>>>>>        possible to specify any CPU via -cpu on the command line, it makes no
> >>>>>>        sense to allow modern 64-bit CPUs to be used.
> >>>>>>        Restrict the isapc machine to the available 32-bit CPUs, taking care to
> >>>>>>        handle the case where if a user inadvertently uses either -cpu max or
> >>>>>>        -cpu host then the "best" 32-bit CPU is used (in this case the pentium3).  
> >>>>>
> >>>>> What is written here made sense from the POV of use of isapc with
> >>>>> qemu-system-x86_64, but in qemu-system-i686, both 'max' and 'host'
> >>>>> where already 32-bit CPUs IIUC. Both this original patch and
> >>>>> the new patch block them from being used in qemu-system-i686
> >>>>> which feels wrong given the justification above.  
> >>>>
> >>>> I tried stepping through with -cpu host/-cpu max on qemu-system-i386 and
> >>>> it's a bit confusing: I think we end up with some kind of custom AMD vendor
> >>>> CPU but with LM disabled. I can't easily see a way to understand what
> >>>> features are currently enabled?
> >>>>
> >>>> I must admit I'm struggling to see the usefulness of -cpu host/-cpu max for
> >>>> isapc given that older OSs can be quite picky when it comes to hardware.  
> >>>
> >>> But x86 CPU vendors go to ridiculous levels of complexity to retain
> >>> historical back compat over many decades. If anything, I'd be surprised
> >>> about the opposite - an OS that didn't work with -cpu max.  
> >>
> >> It's not the CPU vendor I'd be worried about, but the OS vendor who may for
> >> example execute CPUID and become confused if it returns an AMD vendor ID
> >> instead of an Intel vendor ID.  

ha, that's how KVM works if I recall it right, one doesn't need host/max for it,
flip to host's vendor would happen with _any_ cpumodel.
That's leads to some degree of fun on guest OS side to deal with.

> > 
> > IIRC/IIUC, AMD sold i486 CPUs with CPUID present in the ISA era, so I
> > would have thought anything checking vendor ID should expect to see
> > more than just Intel ?  
> 
> Unfortunately I don't remember the specifics, but I have a vague memory 
> that someone has mentioned this to me in the past.
> >> What do you think is the best way forward? I'm still not convinced of the
> >> utility of -cpu host/-cpu max for isapc, so what if instead of mapping them
> >> to the pentium3 CPU we follow the standard deprecation path and emit a
> >> warning on startup, and then remove them from valid_cpu_types in 2 releases
> >> time? The advantage to this approach is that if people are actually using
> >> -cpu host/-cpu max with the isapc machine then they would at least file an
> >> issue in Gitlab and make us aware of it.  
> > 
> > If we want to deprecate it the formal route, that's fine.  
> 
> Works for me. Igor, any objections?

given host/max are accelerator specific models with all possible features for it,
it' would be fair to make sure that those models in qemu-system-i686 case expose
only 32-bit CPU's features
(do we wanna go to that extent for i386? I'm not sure)

However let's not confuse it with capabilities of specific machine type,
it shouldn't have any influence on cpu models. It looks like this patch does
the right thing /limiting permitted cpus to back then reality/.

If we strictly follow rules,
then deprecation is the way to go, so it wouldn't look as regression.

(aka QEMU used to start fine with host/max, and we warn in advance that it's
going out in favor of .../because of ...
shout out if you have a use case.)
 
> 
> 
> ATB,
> 
> Mark.
> 

[PATCH v2 2/2] docs/about/deprecated.rst: document new restrictions for isapc CPU models

[Mark Cave-Ayland]

Add a new paragraph in the "Backwards compatibility" section documenting that
the isapc machine is now restricted to 32-bit x86 CPUs, and -cpu host and
-cpu max are no longer supported.

Signed-off-by: Mark Cave-Ayland <mark.caveayland@nutanix.com>
---
 docs/about/deprecated.rst | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index aa300bbd50..4c7000650d 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -514,6 +514,19 @@ available firmwares that are using the current (wrong) name.  The
 property is kept as is in 9.1, together with "riscv,delegation", to
 give more time for firmware developers to change their code.
 
+x86 "isapc" board restricted to 32-bit x86 CPUs (since 10.2)
+''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
+
+The "isapc" board represents a historical x86 ISA PC and is intended for
+older 32-bit x86 CPU models, defaulting to a 486 CPU model.  Previously it
+was possible (but non-sensical) to specify a more modern x86 CPU, including
+``-cpu host`` or ``-cpu max`` even if the features were incompatible with many
+of the intended guest OSs.
+
+Now the "isapc" board contains an explicit list of supported 32-bit x86 CPU
+models. If the user requests an unsupported CPU model then an error message is
+returned indicating the available CPU models.
+
 Migration
 ---------
 
-- 
2.43.0

Re: [PATCH v2 2/2] docs/about/deprecated.rst: document new restrictions for isapc CPU models

[Markus Armbruster]

Mark Cave-Ayland <mark.caveayland@nutanix.com> writes:

> Add a new paragraph in the "Backwards compatibility" section documenting that
> the isapc machine is now restricted to 32-bit x86 CPUs, and -cpu host and
> -cpu max are no longer supported.
>
> Signed-off-by: Mark Cave-Ayland <mark.caveayland@nutanix.com>
> ---
>  docs/about/deprecated.rst | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
>
> diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
> index aa300bbd50..4c7000650d 100644
> --- a/docs/about/deprecated.rst
> +++ b/docs/about/deprecated.rst
> @@ -514,6 +514,19 @@ available firmwares that are using the current (wrong) name.  The
>  property is kept as is in 9.1, together with "riscv,delegation", to
>  give more time for firmware developers to change their code.
>  
> +x86 "isapc" board restricted to 32-bit x86 CPUs (since 10.2)
> +''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
> +
> +The "isapc" board represents a historical x86 ISA PC and is intended for
> +older 32-bit x86 CPU models, defaulting to a 486 CPU model.  Previously it
> +was possible (but non-sensical) to specify a more modern x86 CPU, including
> +``-cpu host`` or ``-cpu max`` even if the features were incompatible with many
> +of the intended guest OSs.
> +
> +Now the "isapc" board contains an explicit list of supported 32-bit x86 CPU
> +models. If the user requests an unsupported CPU model then an error message is
> +returned indicating the available CPU models.
> +
>  Migration
>  ---------

I couldn't see how this corresponds to PATCH 1 until I realized it
documents recent commit e1e2909f8e7 modified by PATCH 1.

A hint in the commit message could've saved me a few minutes :)

Reviewed-by: Markus Armbruster <armbru@redhat.com>

Re: [PATCH v2 2/2] docs/about/deprecated.rst: document new restrictions for isapc CPU models

[Peter Maydell]

On Thu, 25 Sept 2025 at 17:07, Mark Cave-Ayland
<mark.caveayland@nutanix.com> wrote:
>
> Add a new paragraph in the "Backwards compatibility" section documenting that
> the isapc machine is now restricted to 32-bit x86 CPUs, and -cpu host and
> -cpu max are no longer supported.
>
> Signed-off-by: Mark Cave-Ayland <mark.caveayland@nutanix.com>
> ---
>  docs/about/deprecated.rst | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
>
> diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
> index aa300bbd50..4c7000650d 100644
> --- a/docs/about/deprecated.rst
> +++ b/docs/about/deprecated.rst
> @@ -514,6 +514,19 @@ available firmwares that are using the current (wrong) name.  The
>  property is kept as is in 9.1, together with "riscv,delegation", to
>  give more time for firmware developers to change their code.
>
> +x86 "isapc" board restricted to 32-bit x86 CPUs (since 10.2)
> +''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
> +
> +The "isapc" board represents a historical x86 ISA PC and is intended for
> +older 32-bit x86 CPU models, defaulting to a 486 CPU model.  Previously it
> +was possible (but non-sensical) to specify a more modern x86 CPU, including
> +``-cpu host`` or ``-cpu max`` even if the features were incompatible with many
> +of the intended guest OSs.
> +
> +Now the "isapc" board contains an explicit list of supported 32-bit x86 CPU
> +models. If the user requests an unsupported CPU model then an error message is
> +returned indicating the available CPU models.

This should go in "removed.rst", I think. "deprecated.rst" is for
things that still work today (perhaps with a warning) but will stop
working in a future QEMU release, not for things that we have already
caused to stop working. (And we should only go directly to
'removed' for features that we are sure nobody's using, but
I assume we've already had that discussion for the code change.)

thanks
-- PMM

Re: [PATCH v2 2/2] docs/about/deprecated.rst: document new restrictions for isapc CPU models

[Mark Cave-Ayland]

On 26/09/2025 13:05, Peter Maydell wrote:

> On Thu, 25 Sept 2025 at 17:07, Mark Cave-Ayland
> <mark.caveayland@nutanix.com> wrote:
>>
>> Add a new paragraph in the "Backwards compatibility" section documenting that
>> the isapc machine is now restricted to 32-bit x86 CPUs, and -cpu host and
>> -cpu max are no longer supported.
>>
>> Signed-off-by: Mark Cave-Ayland <mark.caveayland@nutanix.com>
>> ---
>>   docs/about/deprecated.rst | 13 +++++++++++++
>>   1 file changed, 13 insertions(+)
>>
>> diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
>> index aa300bbd50..4c7000650d 100644
>> --- a/docs/about/deprecated.rst
>> +++ b/docs/about/deprecated.rst
>> @@ -514,6 +514,19 @@ available firmwares that are using the current (wrong) name.  The
>>   property is kept as is in 9.1, together with "riscv,delegation", to
>>   give more time for firmware developers to change their code.
>>
>> +x86 "isapc" board restricted to 32-bit x86 CPUs (since 10.2)
>> +''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
>> +
>> +The "isapc" board represents a historical x86 ISA PC and is intended for
>> +older 32-bit x86 CPU models, defaulting to a 486 CPU model.  Previously it
>> +was possible (but non-sensical) to specify a more modern x86 CPU, including
>> +``-cpu host`` or ``-cpu max`` even if the features were incompatible with many
>> +of the intended guest OSs.
>> +
>> +Now the "isapc" board contains an explicit list of supported 32-bit x86 CPU
>> +models. If the user requests an unsupported CPU model then an error message is
>> +returned indicating the available CPU models.
> 
> This should go in "removed.rst", I think. "deprecated.rst" is for
> things that still work today (perhaps with a warning) but will stop
> working in a future QEMU release, not for things that we have already
> caused to stop working. (And we should only go directly to
> 'removed' for features that we are sure nobody's using, but
> I assume we've already had that discussion for the code change.)

It's an interesting one because rather than removing something, we're 
adding a validation check to prevent the user from doing something that 
is nonsensical, i.e. using a modern CPU on a board/OSs that would never 
happen in real life. Given that just about everyone other than hobbyists 
is using the pc/q35 machines on x86, the target audience for isapc is 
comparatively small.

There was some concern that libvirt could generate -cpu host/-cpu max 
for isapc on the command line which is why I added the original 
workaround, but then Igor intervened as maintainer and requested this to 
be removed and enforced via valid_cpu_types instead.

Where do you think would be a suitable place in removed.rst? Maybe the 
"System emulator machines" section?


ATB,

Mark.

Re: [PATCH v2 2/2] docs/about/deprecated.rst: document new restrictions for isapc CPU models

[Peter Maydell]

On Fri, 26 Sept 2025 at 13:28, Mark Cave-Ayland
<mark.caveayland@nutanix.com> wrote:
>
> On 26/09/2025 13:05, Peter Maydell wrote:
>
> > On Thu, 25 Sept 2025 at 17:07, Mark Cave-Ayland
> > <mark.caveayland@nutanix.com> wrote:
> >>
> >> Add a new paragraph in the "Backwards compatibility" section documenting that
> >> the isapc machine is now restricted to 32-bit x86 CPUs, and -cpu host and
> >> -cpu max are no longer supported.
> >>
> >> Signed-off-by: Mark Cave-Ayland <mark.caveayland@nutanix.com>
> >> ---
> >>   docs/about/deprecated.rst | 13 +++++++++++++
> >>   1 file changed, 13 insertions(+)
> >>
> >> diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
> >> index aa300bbd50..4c7000650d 100644
> >> --- a/docs/about/deprecated.rst
> >> +++ b/docs/about/deprecated.rst
> >> @@ -514,6 +514,19 @@ available firmwares that are using the current (wrong) name.  The
> >>   property is kept as is in 9.1, together with "riscv,delegation", to
> >>   give more time for firmware developers to change their code.
> >>
> >> +x86 "isapc" board restricted to 32-bit x86 CPUs (since 10.2)
> >> +''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
> >> +
> >> +The "isapc" board represents a historical x86 ISA PC and is intended for
> >> +older 32-bit x86 CPU models, defaulting to a 486 CPU model.  Previously it
> >> +was possible (but non-sensical) to specify a more modern x86 CPU, including
> >> +``-cpu host`` or ``-cpu max`` even if the features were incompatible with many
> >> +of the intended guest OSs.
> >> +
> >> +Now the "isapc" board contains an explicit list of supported 32-bit x86 CPU
> >> +models. If the user requests an unsupported CPU model then an error message is
> >> +returned indicating the available CPU models.
> >
> > This should go in "removed.rst", I think. "deprecated.rst" is for
> > things that still work today (perhaps with a warning) but will stop
> > working in a future QEMU release, not for things that we have already
> > caused to stop working. (And we should only go directly to
> > 'removed' for features that we are sure nobody's using, but
> > I assume we've already had that discussion for the code change.)
>
> It's an interesting one because rather than removing something, we're
> adding a validation check to prevent the user from doing something that
> is nonsensical, i.e. using a modern CPU on a board/OSs that would never
> happen in real life. Given that just about everyone other than hobbyists
> is using the pc/q35 machines on x86, the target audience for isapc is
> comparatively small.
>
> There was some concern that libvirt could generate -cpu host/-cpu max
> for isapc on the command line which is why I added the original
> workaround, but then Igor intervened as maintainer and requested this to
> be removed and enforced via valid_cpu_types instead.
>
> Where do you think would be a suitable place in removed.rst? Maybe the
> "System emulator machines" section?

That would be fine. In general I think deprecated.rst and
removed.rst are supposed to have the same structure of sections,
so that when we take something from "deprecated, might warn"
to "stops working entirely" we move that paragraph from wherever
it was in deprecated.rst to the equivalent section in
removed.rst.

-- PMM

Re: [PATCH v2 0/2] isapc: remove support for -cpu host and -cpu max

[Igor Mammedov]

On Thu, 25 Sep 2025 17:03:18 +0100
Mark Cave-Ayland <mark.caveayland@nutanix.com> wrote:

> This series removes support for -cpu host and -cpu max from the isapc
> machine as suggested by Igor, and then updates the "Backwards compatibility"
> section of the documentation to reflect both this and the recently
> introduced 32-bit x86 CPU restriction.
> 
> Signed-off-by: Mark Cave-Ayland <mark.caveayland@nutanix.com>

so, taking in account discussion in this thread.

I'd 1st post only deprecation, and once it is run out
this patch.

With that:
Reviewed-by: Igor Mammedov <imammedo@redhat.com>

> 
> v2:
> - Add documentation change suggested by Markus
> 
> 
> Mark Cave-Ayland (2):
>   hw/i386/isapc.c: remove support for -cpu host and -cpu max
>   docs/about/deprecated.rst: document new restrictions for isapc CPU
>     models
> 
>  docs/about/deprecated.rst | 13 +++++++++++++
>  hw/i386/isapc.c           | 27 ---------------------------
>  2 files changed, 13 insertions(+), 27 deletions(-)
> 

Re: [PATCH v2 0/2] isapc: remove support for -cpu host and -cpu max

[Mark Cave-Ayland]

On 02/10/2025 14:13, Igor Mammedov wrote:

> On Thu, 25 Sep 2025 17:03:18 +0100
> Mark Cave-Ayland <mark.caveayland@nutanix.com> wrote:
> 
>> This series removes support for -cpu host and -cpu max from the isapc
>> machine as suggested by Igor, and then updates the "Backwards compatibility"
>> section of the documentation to reflect both this and the recently
>> introduced 32-bit x86 CPU restriction.
>>
>> Signed-off-by: Mark Cave-Ayland <mark.caveayland@nutanix.com>
> 
> so, taking in account discussion in this thread.
> 
> I'd 1st post only deprecation, and once it is run out
> this patch.

Regarding deprecation, do I understand correctly that you are happy with 
the current restriction to 32-bit x86 CPUs added for 10.2, and it's just 
the -cpu host/-cpu max you want to go through the deprecation process?

> With that:
> Reviewed-by: Igor Mammedov <imammedo@redhat.com>

Thanks!


ATB,

Mark.

Re: [PATCH v2 0/2] isapc: remove support for -cpu host and -cpu max

[Igor Mammedov]

On Fri, 3 Oct 2025 12:46:12 +0100
Mark Cave-Ayland <mark.caveayland@nutanix.com> wrote:

> On 02/10/2025 14:13, Igor Mammedov wrote:
> 
> > On Thu, 25 Sep 2025 17:03:18 +0100
> > Mark Cave-Ayland <mark.caveayland@nutanix.com> wrote:
> >   
> >> This series removes support for -cpu host and -cpu max from the isapc
> >> machine as suggested by Igor, and then updates the "Backwards compatibility"
> >> section of the documentation to reflect both this and the recently
> >> introduced 32-bit x86 CPU restriction.
> >>
> >> Signed-off-by: Mark Cave-Ayland <mark.caveayland@nutanix.com>  
> > 
> > so, taking in account discussion in this thread.
> > 
> > I'd 1st post only deprecation, and once it is run out
> > this patch.  
> 
> Regarding deprecation, do I understand correctly that you are happy with 
> the current restriction to 32-bit x86 CPUs added for 10.2, and it's just 
> the -cpu host/-cpu max you want to go through the deprecation process?

given we haven't released any restrictions yet and it was possible to start
VM with any of cpu model. We should just revert 
   e1e2909f8e74 hw/i386/pc_piix.c: restrict isapc machine to 32-bit CPUs
for now and add deprecation message for 10.2

and then apply reduced (on max/host) variant in 2 releases.


> > With that:
> > Reviewed-by: Igor Mammedov <imammedo@redhat.com>  
> 
> Thanks!
> 
> 
> ATB,
> 
> Mark.
>