semantic: 0.197
other: 0.176
device: 0.083
permissions: 0.080
graphic: 0.061
files: 0.055
socket: 0.055
PID: 0.054
performance: 0.049
vnc: 0.047
network: 0.046
debug: 0.040
KVM: 0.028
boot: 0.028
debug: 0.304
files: 0.150
semantic: 0.148
other: 0.096
PID: 0.062
device: 0.038
performance: 0.036
network: 0.033
vnc: 0.025
boot: 0.024
graphic: 0.023
permissions: 0.022
socket: 0.019
KVM: 0.019

32-to-64-bit call gate unsupported in IA32e mode

In particular, the lcall implementation doesn't support the 64-bit TSS.

helper_lcall_protected (target-i386/seg_helper.c:1884) calls get_ss_esp_from_tss() on a call gate to a lower privilege level, which tries to extract a 32-bit ESP and 16-bit SS from the TSS.  In IA32e mode (64-bit or compatibility mode), this instead grabs the lower 32-bits of the target RSP, and 16 of the upper bits as the SS.  Additionally, several of the subsequent checks are incorrect (even if the correct stack pointer were extracted).

This isn't a problem for interrupts since the interrupts are given their own implementation entirely, that uses get_rsp_from_tss() rather than get_ss_esp_from_tss().

I believe the missing logic is from the branch starting "ELSE (* current TSS is 64-bit *)" in the CALL pseudocode in the Intel manual (page 3-124 of the PDF I have).

Reproduced at master (c0b520dfb8890294a9f8879f4759172900585995), and also as of a qemu built a year ago.

I also suspect that qemu will incorrectly allow calls through 32-bit call gates in compatibility mode (rather than raising a GP fault --- see Intel manuals volume 3A 5-21).  And I doubt 64-to-64-bit call gates work either.  I haven't actually tested either of those scenarios, though, this is just from reading the code.

Looking through old bug tickets... is this still an issue with the latest version of QEMU? Or could we close this ticket nowadays?

Looking at the commit log it looks like Andrew fixed this in commit 0aca060526d3ff9632aaed in 2018 ?


That looks like the corresponding fix, indeed. Let's close this ticket.