hypervisor: 0.986
x86: 0.932
architecture: 0.907
graphic: 0.888
performance: 0.828
device: 0.775
mistranslation: 0.658
semantic: 0.642
register: 0.559
permissions: 0.542
network: 0.533
vnc: 0.528
virtual: 0.498
socket: 0.489
VMM: 0.482
i386: 0.480
debug: 0.405
arm: 0.401
peripherals: 0.392
user-level: 0.390
risc-v: 0.385
PID: 0.379
boot: 0.349
kernel: 0.340
files: 0.340
ppc: 0.339
assembly: 0.275
TCG: 0.227
KVM: 0.035

Logical to linear address translation is wrong for 32-bit guests on a 64-bit hypervisor

I run a 64-bit hypervisor in qemu-system-x86_64 (without KVM) and on top of that I have a 32-bit guest. The guest configures the code-segment to have a base of 0x4000_0000 and a limit of 0xFFFF_FFFF with paging disabled. Thus, if a logical address of e.g. 0xC000_0000 is used, it should be translated to 0x0000_0000 (linear and physical), because of the overflow that happens.
But this does not happen with the described setup. Instead, qemu seems to calculate the logical to linear translation with 64-bit addresses so that no overflow happens. Consequently, the resulting address is 0x1_0000_0000 and this gets written to exitinfo2 in the VMCB structure. This causes trouble for hypervisors that expect the upper 32 bits of exitinfo2 to be 0 for 32-bit guests.

Note also that the exact same setup runs fine on real AMD machines with SVM. That is, the upper 32 bits in exitinfo2 are always 0 because of the overflow.

I've tested that with the latest development version of QEMU (commit 328465fd9f3a628ab320b5959d68d3d49df58fa6).

Triaging old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays?

[Expired for QEMU because there has been no activity for 60 days.]