1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
<think>
Okay, so I have this bug report from QEMU that I need to classify into one of the given categories. Let me read through it carefully.
The bug is titled "32-to-64-bit call gate unsupported in IA32e mode." Hmm, IA32e mode refers to 64-bit long mode on x86 processors. So this seems related to how QEMU handles calls between 32-bit and 64-bit environments, especially when dealing with call gates.
The report mentions that the lcall implementation doesn't support the 64-bit TSS (Task State Segment). The specific issue is in the helper_lcall_protected function in target-i386/seg_helper.c at line 1884. It calls get_ss_esp_from_tss(), which tries to extract a 32-bit ESP and 16-bit SS from the TSS. But in IA32e mode, this approach is incorrect because it only grabs the lower 32 bits of RSP and part of the upper bits as SS.
The user points out that this isn't an issue for interrupts because they have a separate implementation using get_rsp_from_tss(). The problem lies in the logic when handling call gates to a lower privilege level, which should be addressed by adding code from the "ELSE (* current TSS is 64-bit *)" branch in Intel's pseudocode (page 3-124).
Looking at the possible categories: mistranslation, assembly lowering, other, device, graphic, socket, network, KVM, boot, vnc, debug, files, permissions, performance, kernel, peripherals, hypervisor.
This issue is about handling x86 call gates and TSS in IA32e mode. It's related to how the virtual CPU handles specific instructions and state transitions, which falls under the hypervisor category because QEMU acts as a hypervisor when running virtual machines. The problem is in translating or emulating certain processor behaviors correctly in 64-bit mode.
So the classification should be 'hypervisor' since it pertains to how QEMU emulates x86 instructions and state management, particularly in handling different modes and privilege levels.
</think>
hypervisor
|