blob: a375693a91015e1eef83f69939dc68cdf6a2a424 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
<think>
Okay, I need to classify this bug report as either user-mode or system-mode. Let me read through the problem description carefully.
The issue is about incorrect results when using the ssra instruction in QEMU-aarch64 for vector lengths of 1024 bits or higher. The user provided a C program that uses SVE (Scalable Vector Extensions) instructions. They built it with GCC and ran it under QEMU with different vector lengths.
In the test case, when using a vector length of 64, both signed and unsigned results are correct (64). But when increasing to 128, the unsigned result is still correct but the signed result becomes 0. This suggests that the emulation in QEMU for SVE2's ssra instruction isn't handling larger vectors properly.
SVE instructions operate on vectors of variable lengths. The problem here seems specific to how QEMU emulates these vector operations at different vector sizes. Since the issue arises when using larger vectors, it's likely related to how the emulator handles vectorized computations in user-space applications.
QEMU is an emulator that can run user-mode programs without requiring a full OS. When running the test program, it's executing user-mode code. The problem occurs during the execution of SVE instructions, which are part of the CPU's instruction set and affect how the program computes results.
This bug doesn't involve any system-level components like device drivers or OS-specific behavior. It's purely about how the emulator correctly handles specific vector operations in user-space applications. Therefore, it should be classified as a user-mode issue.
</think>
user
|