blob: 8c992bce8c4217a72345ba9359fcafdbcd603a5b (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
<think>
Alright, I need to classify this bug report into one of three categories: instruction, syscall, or runtime. Let's break down the problem described here.
The user reports a significant performance slowdown between QEMU versions 8.0.0 and 8.1.0 when running on an AArch64 machine. Specifically, they mention that after applying commit 59b6b42cd3, which enables FEAT_LSE2 for the max CPU, their execution time increased dramatically from 0.8s to 6.8s. They've also noted that reverting this commit or specifying a different CPU (-cpu cortex-a35) mitigates the issue.
Looking at the possible categories:
1. **Instruction**: This would relate to an issue with how specific instructions are handled, perhaps incorrect handling leading to errors. However, here the problem is performance, not instruction correctness.
2. **Syscall**: This category involves issues with system calls. The report doesn't mention any syscalls failing or behaving incorrectly; it's about execution time.
3. **Runtime**: This encompasses runtime errors or performance issues that occur during normal operation. Since the slowdown happens at runtime and affects performance, this seems to fit.
The issue arises from enabling a new CPU feature (FEAT_LSE2), which affects how QEMU emulates instructions. The problem isn't a crash or incorrect behavior but rather a significant increase in execution time, indicating a runtime performance issue related to how these features are handled during emulation.
</think>
runtime
|