1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
<think>
Okay, I need to figure out whether this bug is user-mode or system-mode related. Let me start by understanding the problem.
The issue arises when running a Zephyr TF-M IPC example on Qemu after a certain commit. Before commit 452c67a427 (Qemu v8.0.0-918-g6972ef1440), it worked, but now it's failing with an assertion error: `arm_feature(env, ARM_FEATURE_M)`.
The error message comes from Qemu's code in target/arm/cpu.h line 2396, specifically the function arm_is_secure_below_el3. The assertion is that ARM_FEATURE_M is not set. So, when this feature is present, it fails.
What does ARM_FEATURE_M mean? I recall that this refers to the ARMv7-M architecture, which is used in Cortex-M processors. These are typically used in microcontroller environments, which run in user mode for applications but have limited privilege levels compared to higher-end CPUs.
The example runs on mps2_an521_ns, which is a Cortex-M based board. So, it's using an ARM M-profile CPU.
In Qemu, if the code expects that the environment doesn't have ARM_FEATURE_M set when running in secure mode below EL3, but the feature is present, it causes this assertion. This suggests that after a certain change, Qemu started enforcing some security checks more strictly or perhaps changed how features are handled for M-profile CPUs.
The issue seems to be related to how Qemu handles the CPU features and secure states on ARM M-profile processors. Since the error occurs during the boot process of Zephyr's TF-M IPC example, which involves both secure and non-secure worlds (as is typical in TF-M setups), it might relate to how Qemu models the secure state for these CPUs.
Considering that this affects the ability to run the example at all, it points towards a system-level issue. The assertion failure is about CPU features related to security states, which are part of the hardware simulation by Qemu. This is not something an application running in user mode would cause; rather, it's a problem with how the virtual machine or CPU model is set up.
Therefore, this bug is likely related to system-mode operations because it involves low-level CPU features and secure state handling, which are part of the operating environment managed by Qemu's system emulation.
</think>
system
|