From d0c85e36e4de67af628d54e9ab577cc3fad7796a Mon Sep 17 00:00:00 2001 From: Christian Krinitsin Date: Thu, 3 Jul 2025 07:27:52 +0000 Subject: add deepseek and gemma results --- results/classifier/gemma3:12b/hypervisor/1211910 | 9 +++++++++ 1 file changed, 9 insertions(+) create mode 100644 results/classifier/gemma3:12b/hypervisor/1211910 (limited to 'results/classifier/gemma3:12b/hypervisor/1211910') diff --git a/results/classifier/gemma3:12b/hypervisor/1211910 b/results/classifier/gemma3:12b/hypervisor/1211910 new file mode 100644 index 000000000..e79750866 --- /dev/null +++ b/results/classifier/gemma3:12b/hypervisor/1211910 @@ -0,0 +1,9 @@ + +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). \ No newline at end of file -- cgit 1.4.1