qemu-arm
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Igor Mammedov
Subject: Re: [PATCH 0/3] hw/arm/virt: Use generic CPU invalidation
Date: Mon, 17 Jul 2023 14:44:55 +0200

On Fri, 14 Jul 2023 13:56:00 +0100
Peter Maydell <peter.maydell@linaro.org> wrote:

> On Fri, 14 Jul 2023 at 12:50, Igor Mammedov <imammedo@redhat.com> wrote:
> >
> > 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)  
> 
> You don't seem to be able to use the full type name on
> x86-64 either:
> 
> $ ./build/all/qemu-system-x86_64 -cpu pentium-x86_64-cpu
> qemu-system-x86_64: unable to find CPU model 'pentium-x86_64-cpu'

that's because it also tied into old cpu_model resolving
routines, and I haven't added typename lookup the last
time I've touched it (it was out of topic change anyway).

but some targets do recognize typename, while some
do a lot more juggling with cpu_model (alpha/ppc),
and yet another class (garbage in => cpu type out).

With the last one we could just error,
while with alpha/ppc we could dumb it down to typenames
only.

> and '-cpu help' does not list them with the suffix.

both above points are fixable,

I can prepare PoC patches for that if there is
no opposition to the idea.

> > 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.  
> 
> This seems to me like a worsening of the user interface,
> and in practice there is not much likelihood of being
> able to deprecate-and-drop the nicer user-facing names,
> because they are baked into so many command lines and
> scripts.
Nice names are subjective point, I suspect in a long run
once users switched to using longer names, they won't care much
about that either.

Also it's arguable if it is worsening UI or not.
I see using consolidated typenames across the board (incl. UI)
as a positive development.

As for scripts/CLI users out there, yes it would be disruptive
for a while but one can adapt to new naming (or use a wrapper
around QEMU that does suffix adding/model mapping as a crutch).

It weren't possible to drop anything before we introduced
deprecation process, but with it we can do it.



> thanks
> -- PMM
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]