All of lore.kernel.org
 help / color / mirror / Atom feed
From: Igor Mammedov <imammedo@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org>,
	Gavin Shan <gshan@redhat.com>,
	qemu-arm@nongnu.org, qemu-devel@nongnu.org, pbonzini@redhat.com,
	eduardo@habkost.net, marcel.apfelbaum@gmail.com,
	philmd@linaro.org, wangyanan55@huawei.com, shan.gavin@gmail.com
Subject: Re: [PATCH 0/3] hw/arm/virt: Use generic CPU invalidation
Date: Mon, 17 Jul 2023 14:44:55 +0200	[thread overview]
Message-ID: <20230717144455.6f02fde9@imammedo.users.ipa.redhat.com> (raw)
In-Reply-To: <CAFEAcA92QFxN0at+5rk7yrfk1sj3tX-GcfZYYY5_=210np_j4g@mail.gmail.com>

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	other threads:[~2023-07-17 12:45 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-13  5:44 [PATCH 0/3] hw/arm/virt: Use generic CPU invalidation Gavin Shan
2023-07-13  5:45 ` [PATCH 1/3] machine: Factor CPU type invalidation out into helper Gavin Shan
2023-07-14 12:07   ` Igor Mammedov
2023-07-18  6:11     ` Gavin Shan
2023-07-24 14:39       ` Igor Mammedov
2023-07-13  5:45 ` [PATCH 2/3] hw/arm/virt: Use generic CPU type invalidation Gavin Shan
2023-07-14 11:59   ` Igor Mammedov
2023-07-18  6:17     ` Gavin Shan
2023-07-13  5:45 ` [PATCH 3/3] hw/arm/virt: Support host CPU type only when KVM or HVF is configured Gavin Shan
2023-07-13 12:46   ` Cornelia Huck
2023-07-13 13:16     ` Gavin Shan
2023-07-13 11:44 ` [PATCH 0/3] hw/arm/virt: Use generic CPU invalidation Peter Maydell
2023-07-13 11:52   ` Marcin Juszkiewicz
2023-07-13 11:59     ` Peter Maydell
2023-07-14 11:50       ` Igor Mammedov
2023-07-14 12:56         ` Peter Maydell
2023-07-17 12:44           ` Igor Mammedov [this message]
2023-07-18 10:31             ` Gavin Shan
2023-07-24 15:06               ` Igor Mammedov
2023-07-24 15:14                 ` Peter Maydell
2023-07-25  6:46                   ` Igor Mammedov
2023-07-13 12:34     ` Gavin Shan
2023-07-13 12:44       ` Marcin Juszkiewicz
2023-07-13 13:00         ` Gavin Shan
2023-07-13 16:29       ` Philippe Mathieu-Daudé
2023-07-14  0:51         ` Gavin Shan
2023-07-14  9:14           ` Gavin Shan
2023-07-13 19:27       ` Richard Henderson
2023-07-14  0:54         ` Gavin Shan
2023-07-13 12:42   ` Gavin Shan

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=20230717144455.6f02fde9@imammedo.users.ipa.redhat.com \
    --to=imammedo@redhat.com \
    --cc=eduardo@habkost.net \
    --cc=gshan@redhat.com \
    --cc=marcel.apfelbaum@gmail.com \
    --cc=marcin.juszkiewicz@linaro.org \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=philmd@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=shan.gavin@gmail.com \
    --cc=wangyanan55@huawei.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.