1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
<think>
Alright, I'm trying to figure out whether this bug report should be classified as a 'user-mode' issue or a 'system-mode' issue in QEMU. Let me break down the information provided.
The user is experiencing an issue where their arm64 defconfig kernel (version 4.14.275) no longer boots after implementing FEAT_LPA in TCG. They've done some bisecting and found that the commit introducing FEAT_LPA is causing the problem. The problematic commit is 7a928f43d, which implements FEAT_LPA.
They mention that using `-cpu max` or `-cpu max,lpa2=off` results in a hang with no output after this change. However, before implementing FEAT_LVA (commit 0af312b6), the same setup worked fine.
The user also notes that a newer kernel (4.19.237) works correctly with `-cpu max` or `-cpu max,lpa2=off`. They're wondering if this behavior is expected due to the older kernel's age, suggesting they might need to use a different CPU type like `cortex-a72` for compatibility.
Now, considering QEMU's architecture: system-mode emulation involves simulating an entire system, including devices, peripherals, and handling lower-level operations. User-mode typically refers to processes running in user space without full hardware simulation.
Since the issue pertains to kernel booting and CPU features (FEAT_LPA), this is related to how the virtualized environment interacts with the guest OS's low-level initialization. This involves system-level configurations and device emulation, which are handled in QEMU's system-mode. The problem isn't about a specific userland application but rather the interaction between the kernel and the emulated hardware.
Therefore, the bug seems to be related to how QEMU is handling certain CPU features or configuration during boot, which affects the entire system operation. Hence, it falls under system-mode.
</think>
system
|