qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Mark Cave-Ayland <mark.caveayland@nutanix.com>
Cc: Xiaoyao Li <xiaoyao.li@intel.com>,
	pbonzini@redhat.com, mst@redhat.com, marcel.apfelbaum@gmail.com,
	eduardo@habkost.net, imammedo@redhat.com, qemu-devel@nongnu.org,
	Jiri Denemark <jdenemar@redhat.com>
Subject: Re: [PATCH v6 01/19] hw/i386/pc_piix.c: restrict isapc machine to 32-bit CPUs
Date: Wed, 27 Aug 2025 12:46:22 +0100	[thread overview]
Message-ID: <aK7wDn03e8RtKmk3@redhat.com> (raw)
In-Reply-To: <58c515a4-292e-4aec-b57e-73be89b9c322@nutanix.com>

On Wed, Aug 27, 2025 at 12:10:00PM +0100, Mark Cave-Ayland wrote:
> On 26/08/2025 08:25, Xiaoyao Li wrote:
> 
> > On 8/22/2025 8:11 PM, Mark Cave-Ayland wrote:
> > > 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 -cpu max 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>
> > > ---
> > >   hw/i386/pc_piix.c | 26 ++++++++++++++++++++++++++
> > >   1 file changed, 26 insertions(+)
> > > 
> > > diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
> > > index c03324281b..5720b6b556 100644
> > > --- a/hw/i386/pc_piix.c
> > > +++ b/hw/i386/pc_piix.c
> > > @@ -436,6 +436,19 @@ static void pc_set_south_bridge(Object *obj,
> > > int value, Error **errp)
> > >   #ifdef CONFIG_ISAPC
> > >   static void pc_init_isa(MachineState *machine)
> > >   {
> > > +    /*
> > > +     * 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");
> > > +    }
> > 
> > Do we need to handle the case of "-cpu host"?
> 
> I don't believe so. I wasn't originally planning to support "-cpu max" for
> isapc, however Daniel mentioned that it could possibly be generated from
> libvirt so it makes sense to add the above check to warn in this case and
> then continue.

Libvirt will support sending any valid -cpu flag, including both
'max' (any config) and 'host' (if KVM).

If 'isapc' still expects to support KVM, then it would be odd to
reject 'host', but KVM presumably has no built-in way to limit to
32-bit without QEMU manually masking many features ?

I'm a little worried about implications of libvirt sending '-cpu max'
and QEMU secretly turning that into '-cpu pentium3', as opposed to
having '-cpu max' expand to equiv to 'pentium3', which might cauase
confusion when libvirt queries the expanded CPU ? Copying Jiri for
an opinion from libvirt side, as I might be worrying about nothing.


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



  reply	other threads:[~2025-08-27 11:49 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-22 12:11 [PATCH v6 00/19] hw/i386: separate isapc out from pc_piix Mark Cave-Ayland
2025-08-22 12:11 ` [PATCH v6 01/19] hw/i386/pc_piix.c: restrict isapc machine to 32-bit CPUs Mark Cave-Ayland
2025-08-26  7:25   ` Xiaoyao Li
2025-08-27 11:10     ` Mark Cave-Ayland
2025-08-27 11:46       ` Daniel P. Berrangé [this message]
2025-08-27 11:50       ` Xiaoyao Li
2025-08-28 10:42         ` Mark Cave-Ayland
2025-08-22 12:11 ` [PATCH v6 02/19] hw/i386/pc_piix.c: remove include for loader.h Mark Cave-Ayland
2025-08-26  7:30   ` Xiaoyao Li
2025-08-22 12:11 ` [PATCH v6 03/19] hw/i386/pc_piix.c: inline pc_xen_hvm_init_pci() into pc_xen_hvm_init() Mark Cave-Ayland
2025-08-26  7:34   ` Xiaoyao Li
2025-08-22 12:11 ` [PATCH v6 04/19] hw/i386/pc_piix.c: duplicate pc_init1() into pc_isa_init() Mark Cave-Ayland
2025-08-26  9:21   ` Xiaoyao Li
2025-08-27 10:47     ` Mark Cave-Ayland
2025-08-22 12:11 ` [PATCH v6 05/19] hw/i386/pc_piix.c: remove pcmc->pci_enabled dependent initialisation from pc_init_isa() Mark Cave-Ayland
2025-08-26  9:48   ` Xiaoyao Li
2025-08-22 12:11 ` [PATCH v6 06/19] hw/i386/pc_piix.c: remove SMI and piix4_pm " Mark Cave-Ayland
2025-08-26  9:52   ` Xiaoyao Li
2025-08-22 12:11 ` [PATCH v6 07/19] hw/i386/pc_piix.c: remove SGX " Mark Cave-Ayland
2025-08-26 11:55   ` Xiaoyao Li
2025-08-22 12:11 ` [PATCH v6 08/19] hw/i386/pc_piix.c: remove nvdimm " Mark Cave-Ayland
2025-08-26 11:56   ` Xiaoyao Li
2025-08-22 12:11 ` [PATCH v6 09/19] hw/i386/pc_piix.c: simplify RAM size logic in pc_init_isa() Mark Cave-Ayland
2025-08-22 14:58   ` Philippe Mathieu-Daudé
2025-08-26 10:01   ` Xiaoyao Li
2025-08-27 11:00     ` Mark Cave-Ayland
2025-08-28  8:41       ` Mark Cave-Ayland
2025-08-22 12:11 ` [PATCH v6 10/19] hw/i386/pc_piix.c: hardcode hole64_size to 0 " Mark Cave-Ayland
2025-08-26 11:57   ` Xiaoyao Li
2025-08-22 12:11 ` [PATCH v6 11/19] hw/i386/pc_piix.c: remove pc_system_flash_cleanup_unused() from pc_init_isa() Mark Cave-Ayland
2025-08-22 12:11 ` [PATCH v6 12/19] hw/i386/pc_piix.c: always initialise ISA IDE drives in pc_init_isa() Mark Cave-Ayland
2025-08-26 12:01   ` Xiaoyao Li
2025-08-22 12:11 ` [PATCH v6 13/19] hw/i386/pc_piix.c: assume pcmc->pci_enabled is always false " Mark Cave-Ayland
2025-08-26  9:50   ` Xiaoyao Li
2025-08-27 11:32     ` Mark Cave-Ayland
2025-08-22 12:12 ` [PATCH v6 14/19] hw/i386/pc_piix.c: hardcode pcms->pci_bus to NULL " Mark Cave-Ayland
2025-08-26 12:03   ` Xiaoyao Li
2025-08-22 12:12 ` [PATCH v6 15/19] hw/i386/pc_piix.c: assume pcmc->pci_enabled is always true in pc_init1() Mark Cave-Ayland
2025-08-26 12:09   ` Xiaoyao Li
2025-08-27 11:54     ` Mark Cave-Ayland
2025-08-22 12:12 ` [PATCH v6 16/19] hw/i386: move isapc machine to separate isapc.c file Mark Cave-Ayland
2025-08-26 12:10   ` Xiaoyao Li
2025-08-22 12:12 ` [PATCH v6 17/19] hw/i386/pc_piix.c: remove unused headers after isapc machine split Mark Cave-Ayland
2025-08-26 12:10   ` Xiaoyao Li
2025-08-22 12:12 ` [PATCH v6 18/19] hw/i386/pc_piix.c: replace rom_memory with pci_memory Mark Cave-Ayland
2025-08-26 12:11   ` Xiaoyao Li
2025-08-22 12:12 ` [PATCH v6 19/19] hw/i386/isapc.c: replace rom_memory with system_memory Mark Cave-Ayland
2025-08-26 12:12   ` Xiaoyao Li

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aK7wDn03e8RtKmk3@redhat.com \
    --to=berrange@redhat.com \
    --cc=eduardo@habkost.net \
    --cc=imammedo@redhat.com \
    --cc=jdenemar@redhat.com \
    --cc=marcel.apfelbaum@gmail.com \
    --cc=mark.caveayland@nutanix.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=xiaoyao.li@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).