summaryrefslogtreecommitdiffstats
path: root/results/classifier/108/debug/2040
diff options
context:
space:
mode:
authorChristian Krinitsin <mail@krinitsin.com>2025-07-03 19:39:53 +0200
committerChristian Krinitsin <mail@krinitsin.com>2025-07-03 19:39:53 +0200
commitdee4dcba78baf712cab403d47d9db319ab7f95d6 (patch)
tree418478faf06786701a56268672f73d6b0b4eb239 /results/classifier/108/debug/2040
parent4d9e26c0333abd39bdbd039dcdb30ed429c475ba (diff)
downloademulator-bug-study-dee4dcba78baf712cab403d47d9db319ab7f95d6.tar.gz
emulator-bug-study-dee4dcba78baf712cab403d47d9db319ab7f95d6.zip
restructure results
Diffstat (limited to 'results/classifier/108/debug/2040')
-rw-r--r--results/classifier/108/debug/204039
1 files changed, 0 insertions, 39 deletions
diff --git a/results/classifier/108/debug/2040 b/results/classifier/108/debug/2040
deleted file mode 100644
index 37264043..00000000
--- a/results/classifier/108/debug/2040
+++ /dev/null
@@ -1,39 +0,0 @@
-debug: 0.930
-device: 0.766
-graphic: 0.732
-performance: 0.720
-other: 0.692
-boot: 0.632
-socket: 0.573
-semantic: 0.558
-network: 0.478
-permissions: 0.471
-PID: 0.450
-vnc: 0.425
-files: 0.191
-KVM: 0.156
-
-x86 TCG incorrectly truncates physical addresses to 32 bits when PAE is enabled
-Description of problem:
-Originally observed as 32-bit Windows failing to boot on systems with RAM above 4G when using TCG (but working fine under KVM). Windows kernel debugger showed the kernel allocating a block of memory but somehow failing to create a page table mapping for it.
-
-Bisection in QEMU produced the first bad commit as 4a1e9d4 ("target/i386: Use atomic operations for pte updates"), which changed the PTE accessing code from using e.g. `x86_ldq_phys()` to using `probe_access_full()` and `ldq_p()`.
-
-Further deconstruction of the changes in this commit found that at some point during the boot, the value obtained from `ldq_p()` was completely different to the value obtained from `x86_ldq_phys()`. Debugging revealed that the underlying host addresses used by each method were exactly 4G apart, with the new method (`ldq_p()`) accessing a host location 4G below the correct address.
-
-Inspection of the code revealed one place where addresses are truncated to 32 bits, which would cause this 4G offset: in `get_physical_address()` we have the code:
-
-```
- if (!(env->hflags & HF_LMA_MASK)) {
- /* Without long mode we can only address 32bits in real mode */
- out->paddr = (uint32_t)out->paddr;
- }
-```
-
-This looks wrong, since PAE allows for physical addresses above 4G to be accessed without long mode. (This is the whole point of PAE.)
-
-A quick experiment shows that commenting out the above block of code fixes the symptom and allows Windows 10 to boot with RAM above 4G.
-
-I suspect that the test should be checking for PAE being enabled rather than long mode being enabled. (Enabling PAE is part of setting up the CPU for long mode, so it is impossible to be in long mode without PAE already enabled.)
-Steps to reproduce:
-Run the command given above.