Re: [PATCH 0/3] hw/arm/virt: Use generic CPU invalidation

[Igor Mammedov <imammedo@redhat.com>]

On Thu, 13 Jul 2023 12:59:55 +0100
Peter Maydell <peter.maydell@linaro.org> wrote:

> On Thu, 13 Jul 2023 at 12:52, Marcin Juszkiewicz
> <marcin.juszkiewicz@linaro.org> wrote:
> >
> > W dniu 13.07.2023 o 13:44, Peter Maydell pisze:
> >  
> > > I see this isn't a change in this patch, but given that
> > > what the user specifies is not "cortex-a8-arm-cpu" but
> > > "cortex-a8", why do we include the "-arm-cpu" suffix in
> > > the error messages? It's not valid syntax to say
> > > "-cpu cortex-a8-arm-cpu", so it's a bit misleading...  
> >
> > Internally those cpu names are "max-{TYPE_ARM_CPU}" and similar for
> > other architectures.  
> 
> Yes; my question is "why are we not using the user-facing
> string rather than the internal type name?".

With other targets full CPU type name can also be valid
user-facing string. Namely we use it with -device/device_add
interface. Considering we would like to have CPU hotplug
on ARM as well, we shouldn't not outlaw full type name.
(QMP/monitor interface also mostly uses full type names)

Instead it might be better to consolidate on what has
been done on making CPU '-device' compatible and
allow to use full CPU type name with '-cpu' on arm machines.

Then later call suffix-less legacy => deprecate/drop it from
user-facing side including cleanup of all the infra we've
invented to keep mapping between cpu_model and typename.

With that gone, listing/restricting (supported) cpu types
can be done without extra processing and likely can be
done in one place for all targets/cpus instead of zoo
we have now.
(extra bonus: all error messages that include
CPU name will become consistent with the rest as well,
since only CPU typename is left around)
 
> -- PMM
>