From: Eduardo Habkost <ehabkost@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: qemu-arm <qemu-arm@nongnu.org>,
QEMU Developers <qemu-devel@nongnu.org>,
"Richard W . M . Jones" <rjones@redhat.com>,
"patches@linaro.org" <patches@linaro.org>
Subject: Re: [Qemu-devel] [Qemu-arm] [PATCH 0/6] arm: support -cpu max (and gic-version=max)
Date: Fri, 26 Jan 2018 08:45:50 -0200 [thread overview]
Message-ID: <20180126104550.GG25150@localhost.localdomain> (raw)
In-Reply-To: <CAFEAcA96N1Nuh9rXVtWnmnmm_+xQRFiesdSLbTx4yJBGYEVJaQ@mail.gmail.com>
On Thu, Jan 25, 2018 at 03:10:31PM +0000, Peter Maydell wrote:
> On 25 January 2018 at 14:41, Peter Maydell <peter.maydell@linaro.org> wrote:
> > On 22 January 2018 at 18:33, Eduardo Habkost <ehabkost@redhat.com> wrote:
> >> About QOM type names:
> >>
> >> On x86, all CPU models are resolved to "<model>-<suffix>", and
> >> i386 and x86_64 have different suffixes. So the QOM type name is
> >> "max-x86_64-cpu" on qemu-system-x86_64, and "max-i386-cpu" on
> >> qemu-system-i386.
> >
> > OK. Looking at the target/arm code we do a similar suffix
> > trick, but we seem to have cut-n-pasted the handling in
> > aarch64_cpu_register(), so it uses the TYPE_ARM_CPU as the
> > suffix, rather the TYPE_AARCH64_CPU.
>
> ...and that's not as simple a fix as I thought, because the
> code in helper.c for implementing arch_query_cpu_definitions() and
> arm_cpu_list() assumes it can create the QOM type name by appending
> TYPE_ARM_CPU. The ARM_CPU_TYPE_NAME() macro which we use pretty
> extensively also assumes the suffix is the same regardless of
> what CPU type it's being applied to.
>
> Looking at x86 it seems that TYPE_X86_CPU expands to a different
> string for qemu-system-x86_64 and qemu-system-i386. I could do
> that, but it seems very confusing: I would expect a QOM type
> name like TYPE_FOO to always mean the same QOM type.
Yeah, I don't like the way TYPE_x86_CPU works, and I don't
recommend doing the same elsewhere.
>
> Given that the type names don't appear to the user, I think
> we can go ahead with implementing "-cpu max" for Arm without
> having to first disentangle this? "max" isn't in any worse
> a position than the existing "host" and "any" types.
Sounds reasonable to me.
--
Eduardo
next prev parent reply other threads:[~2018-01-26 13:12 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-07 18:14 [Qemu-devel] [PATCH 0/6] arm: support -cpu max (and gic-version=max) Peter Maydell
2017-12-07 18:14 ` [Qemu-devel] [PATCH 1/6] hw/arm/virt: Check that the CPU realize method succeeded Peter Maydell
2017-12-09 1:08 ` Eduardo Habkost
2018-01-26 14:32 ` [Qemu-devel] [Qemu-arm] " Philippe Mathieu-Daudé
2018-01-26 14:34 ` Peter Maydell
2017-12-07 18:14 ` [Qemu-devel] [PATCH 2/6] target/arm: Query host CPU features on-demand at instance init Peter Maydell
2018-01-26 13:53 ` [Qemu-devel] [Qemu-arm] " Philippe Mathieu-Daudé
2017-12-07 18:14 ` [Qemu-devel] [PATCH 3/6] target/arm: Move definition of 'host' cpu type into cpu.c Peter Maydell
2018-01-26 13:47 ` Philippe Mathieu-Daudé
2017-12-07 18:14 ` [Qemu-devel] [PATCH 4/6] target/arm: Add "-cpu max" support Peter Maydell
2018-01-26 14:29 ` Philippe Mathieu-Daudé
2018-01-26 14:33 ` Peter Maydell
2018-01-26 15:44 ` Philippe Mathieu-Daudé
2018-02-02 17:54 ` Peter Maydell
2018-02-05 10:39 ` Igor Mammedov
2017-12-07 18:14 ` [Qemu-devel] [PATCH 5/6] hw/arm/virt: Add "max" to the list of CPU types "virt" supports Peter Maydell
2017-12-07 18:14 ` [Qemu-devel] [PATCH 6/6] hw/arm/virt: Support -machine gic-version=max Peter Maydell
2017-12-07 19:37 ` [Qemu-devel] [Qemu-arm] [PATCH 0/6] arm: support -cpu max (and gic-version=max) Peter Maydell
2017-12-09 1:08 ` Eduardo Habkost
2018-01-22 18:06 ` Peter Maydell
2018-01-22 18:33 ` Eduardo Habkost
2018-01-25 14:41 ` Peter Maydell
2018-01-25 15:10 ` Peter Maydell
2018-01-26 10:45 ` Eduardo Habkost [this message]
2018-01-26 10:42 ` Eduardo Habkost
2018-01-26 11:02 ` Peter Maydell
2018-01-26 17:54 ` Eduardo Habkost
2018-01-26 18:04 ` Peter Maydell
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=20180126104550.GG25150@localhost.localdomain \
--to=ehabkost@redhat.com \
--cc=patches@linaro.org \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=rjones@redhat.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.