blob: fae999031d3014ef8df3c98a5419d2e7c77f7112 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
|
<think>
Okay, so I'm trying to figure out whether this QEMU bug is user-mode or system-mode related. The issue involves the fldl instruction in i386 emulation, which affects how floating-point operations are handled. From what I remember, fldl loads a double-precision float into the FPU stack.
The problem seems to be with the precision control bits of the FPU control word, specifically in QEMU's softfloat implementation after a certain commit. The output is incorrect when converting from float64 to floatx80. Before the commit, it worked correctly, but now there's a discrepancy.
Since this issue deals directly with how floating-point operations are emulated at the CPU level, and FPU control words are part of the CPU's state, I think this falls under user-mode emulation. User-mode instructions like fldl are handled by QEMU when running user-space applications or processes.
Peripherals or system-level devices aren't mentioned here; it's purely about CPU instruction handling. So, this bug is likely related to how QEMU emulates the CPU for user programs rather than managing higher-privilege operations or system devices.
</think>
The issue pertains to the emulation of an i386 CPU instruction within QEMU, specifically affecting floating-point operations. This is part of the user-mode emulation as it deals with application-level instructions.
user
|