1 files changed, 43 insertions, 0 deletions
diff --git a/results/classifier/zero-shot/118/hypervisor/1211910 b/results/classifier/zero-shot/118/hypervisor/1211910
new file mode 100644
index 000000000..d9dbaedcb
--- /dev/null
+++ b/results/classifier/zero-shot/118/hypervisor/1211910
@@ -0,0 +1,43 @@
+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.]
+