From: Thomas Huth <thuth@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "Auger Eric" <eric.auger@redhat.com>,
"Richard Henderson" <richard.henderson@linaro.org>,
qemu-arm <qemu-arm@nongnu.org>,
"Philippe Mathieu-Daudé" <philmd@redhat.com>,
"QEMU Developers" <qemu-devel@nongnu.org>
Subject: Re: [PATCH 2/4] target/arm: Move cortex-m related functions to new file v7m.c
Date: Mon, 23 Sep 2019 20:51:23 +0200 [thread overview]
Message-ID: <4841d83d-4d91-eef6-28aa-c920cb10d9c9@redhat.com> (raw)
In-Reply-To: <CAFEAcA9k59CRG23qP-o5PF0mdXvXpszhuxx+GpbpWO+hFdHOOA@mail.gmail.com>
On 23/09/2019 20.45, Peter Maydell wrote:
> On Mon, 23 Sep 2019 at 19:09, Thomas Huth <thuth@redhat.com> wrote:
>> However, there's one thing I currently don't quite understand in this
>> code (since I'm not an ARM guy, sorry) : There are references to "v8" in
>> m_helper.c, too. Is that related to a separate CPU type, ie. should the
>> v8 code also be available when CONFIG_ARM_V7M is disabled? Or can the
>> code in m_helper.c be disabled completely if CONFIG_ARM_V7M is not set?
>
> QEMU's naming conventions here is a bit confusing, for
> historical reasons.
>
> Architecturally what we have is:
> * "M-profile" -- this is the flavour of Arm architecture for
> microcontrollers; it has some big differences from A and R
> profile (eg the exception mechanism is different and it has
> a built-in NVIC interrupt controller). All the Cortex-M<anything>
> CPUs are M-profile
> * "Arm-v7M" -- this is the v7 flavour of the M-profile
> architecture, eg Cortex-M3.
> * "Arm-v6M" -- this looks like it ought to mean "v6 flavour
> of M-profile", but if you look at what features it has it's
> more like "cut down version of v7M" (fewer instructions, cut
> down exception model, etc, but some things which on A-profile
> don't appear until v7A are present in v6M). Cortex-M0 and -M1.
> * "Arm-v8M" -- v8 flavour of M-profile. The big change here
> is support for TrustZone. Cortex-M33. v8M comes in two
> sub-profiles: "mainline", which has all the features like v7M,
> and "baseline", which is cut-down in the same way v6M is a
> cut-down v7M.
>
> In QEMU, we implemented Cortex-M3 first, and then added -M0 and
> -M33 later. So mostly our function naming convention uses
> "v7m" when it means "any M-profile"; a few v8M-specific
> functions use a "v8m" prefix. Everything in m_helper.c is
> M-profile specific; most of it is used by all M-profile cores,
> and a few bits are v8M-only or v7M-and-v8M-mainline only.
>
> From a CONFIG switch point of view I don't think it's
> worth being able to #ifdef out the various flavours of
> M-profile individually.
Ok, thanks a lot for the explanation! It's much clearer to me now.
So I think it likely would be best to disable the whole m_helper.c code
instead of introducing a new file like v7m.c (but that likely requires a
stub file instead or some #ifdeffing in translate.c).
It also sounds like CONFIG_ARM_V7M should rather be renamed to
CONFIG_ARM_MPROFILE or something similar?
Thomas
next prev parent reply other threads:[~2019-09-23 18:55 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-21 15:04 [PATCH 0/4] Make it possible to compile with CONFIG_ARM_V7M=n Thomas Huth
2019-09-21 15:04 ` [PATCH 1/4] target/arm: Make cpu_register() and set_feature() available for other files Thomas Huth
2019-09-23 14:28 ` Auger Eric
2019-09-21 15:04 ` [PATCH 2/4] target/arm: Move cortex-m related functions to new file v7m.c Thomas Huth
2019-09-23 14:31 ` Auger Eric
2019-09-23 18:09 ` Thomas Huth
2019-09-23 18:45 ` Peter Maydell
2019-09-23 18:51 ` Thomas Huth [this message]
2019-09-23 18:54 ` Peter Maydell
2019-09-24 11:02 ` Auger Eric
2019-09-24 11:06 ` Thomas Huth
2019-09-24 11:24 ` Auger Eric
2019-09-23 14:34 ` Peter Maydell
2019-09-24 9:52 ` Philippe Mathieu-Daudé
2019-09-21 15:04 ` [PATCH 3/4] hw/arm: Move armv7m_nvic.c to hw/arm/ and always enable it for arm builds Thomas Huth
2019-09-23 14:52 ` Peter Maydell
2019-09-23 17:54 ` Thomas Huth
2019-09-23 18:27 ` Peter Maydell
2019-09-23 18:36 ` Thomas Huth
2019-09-23 18:50 ` Peter Maydell
2019-09-24 4:44 ` Thomas Huth
2019-09-24 9:42 ` Peter Maydell
2019-09-24 9:48 ` Thomas Huth
2019-09-24 10:01 ` Philippe Mathieu-Daudé
2019-09-21 15:04 ` [PATCH 4/4] default-configs: Do not enforce CONFIG_ARM_V7M anymore Thomas Huth
2019-09-23 8:37 ` [PATCH 0/4] Make it possible to compile with CONFIG_ARM_V7M=n Philippe Mathieu-Daudé
2019-09-23 8:50 ` Thomas Huth
2019-09-23 8:58 ` Philippe Mathieu-Daudé
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=4841d83d-4d91-eef6-28aa-c920cb10d9c9@redhat.com \
--to=thuth@redhat.com \
--cc=eric.auger@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=philmd@redhat.com \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
/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).