blob: 551f7b6f58cf43a5571c6901dce900978423ecb5 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
<think>
Okay, so I'm trying to figure out whether this QEMU issue is a user-mode problem or a system-mode problem. Let's start by understanding the scenario.
The user is running an application using QEMU in user mode for an ARM binary on Ubuntu 22.04. They mention that version 6.2 works fine, but when they compiled version 8.0 themselves, mmap operations fail once the memory usage exceeds around 1GB. The issue seems to be with how memory is being mapped beyond a certain point.
They provided a test application and steps to reproduce: creating five 256MB files and trying to mmap all of them. The first three succeed, but the fourth fails. This points towards a problem with address space allocation beyond a certain limit.
The user also notes that this limit is around where QEMU loaded the ELF binary (0x40000000), suggesting an addressing issue in how the process's memory is being managed. They tried adjusting the base address using the -B option but ran into other issues, which might be related to how the user-mode emulator handles memory allocations.
QEMU has two main modes: system and user. System mode simulates a full OS with hardware devices, while user mode runs individual applications without a full OS context, translating syscalls as needed. Since this issue is about an application's mmap calls failing within QEMU's user mode, it's likely related to how the user-mode emulator manages memory for processes.
The fact that older versions of QEMU (like 6.2) don't have this problem suggests a regression introduced in later versions. The change might be in how the user-mode code handles virtual address spaces or mmap operations beyond certain thresholds.
I'm thinking that the bug is related to the user-mode emulator's memory management, possibly an oversight in how it allocates or reserves virtual addresses for applications. Maybe something changed in how QEMU maps files into the process's address space when the total exceeds 1GB.
So, considering all this, I classify this issue as a 'user' mode problem because it involves how applications interact with memory within QEMU's user-mode environment.
</think>
user
|