i386: 0.884
architecture: 0.839
permissions: 0.744
semantic: 0.698
x86: 0.692
ppc: 0.687
device: 0.682
register: 0.680
socket: 0.665
user-level: 0.657
graphic: 0.655
kernel: 0.653
peripherals: 0.652
hypervisor: 0.643
performance: 0.626
network: 0.599
files: 0.588
assembly: 0.551
vnc: 0.525
mistranslation: 0.512
PID: 0.502
risc-v: 0.490
TCG: 0.481
debug: 0.467
arm: 0.444
boot: 0.431
VMM: 0.425
KVM: 0.303
virtual: 0.286
--------------------
i386: 0.997
x86: 0.994
debug: 0.138
kernel: 0.046
semantic: 0.039
files: 0.038
register: 0.026
TCG: 0.025
architecture: 0.022
virtual: 0.017
assembly: 0.014
hypervisor: 0.014
PID: 0.007
user-level: 0.003
device: 0.003
performance: 0.002
risc-v: 0.002
network: 0.002
VMM: 0.002
vnc: 0.001
boot: 0.001
ppc: 0.001
graphic: 0.001
permissions: 0.001
socket: 0.001
KVM: 0.001
peripherals: 0.001
mistranslation: 0.000
arm: 0.000

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.