On Mon, 23 Sep 2019 at 19:09, Thomas Huth <th...@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. thanks -- PMM
