summary refs log tree commit diff stats
path: root/results/classifier/108/other/1211
diff options
context:
space:
mode:
Diffstat (limited to '')
-rw-r--r--results/classifier/108/other/121122
-rw-r--r--results/classifier/108/other/121191028
-rw-r--r--results/classifier/108/other/121194323
3 files changed, 73 insertions, 0 deletions
diff --git a/results/classifier/108/other/1211 b/results/classifier/108/other/1211
new file mode 100644
index 000000000..260f5e2a3
--- /dev/null
+++ b/results/classifier/108/other/1211
@@ -0,0 +1,22 @@
+device: 0.854
+graphic: 0.562
+debug: 0.375
+boot: 0.229
+semantic: 0.184
+PID: 0.109
+files: 0.089
+other: 0.077
+vnc: 0.038
+network: 0.029
+performance: 0.022
+socket: 0.018
+permissions: 0.012
+KVM: 0.010
+
+Bad fonts in "cirrus" VGA card.
+Description of problem:
+Similar to #988. Fixed by set "no_bitblt" and "sw_cursor" in XF86Config file.
+Steps to reproduce:
+Similar to #988.
+Additional information:
+
diff --git a/results/classifier/108/other/1211910 b/results/classifier/108/other/1211910
new file mode 100644
index 000000000..93f1e470b
--- /dev/null
+++ b/results/classifier/108/other/1211910
@@ -0,0 +1,28 @@
+graphic: 0.888
+performance: 0.828
+device: 0.775
+semantic: 0.642
+other: 0.624
+permissions: 0.542
+network: 0.533
+vnc: 0.528
+socket: 0.489
+debug: 0.405
+PID: 0.379
+boot: 0.349
+files: 0.340
+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.]
+
diff --git a/results/classifier/108/other/1211943 b/results/classifier/108/other/1211943
new file mode 100644
index 000000000..9ccf4cd5b
--- /dev/null
+++ b/results/classifier/108/other/1211943
@@ -0,0 +1,23 @@
+device: 0.751
+performance: 0.569
+network: 0.548
+graphic: 0.544
+socket: 0.489
+PID: 0.347
+boot: 0.311
+debug: 0.308
+semantic: 0.300
+vnc: 0.292
+KVM: 0.278
+other: 0.199
+files: 0.186
+permissions: 0.137
+
+#GP and aligned move instruction
+
+When the operand of movaps, movapd or movdqa instruction isn't aligned, general-protection exception should be generated.
+
+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.]
+