1 files changed, 46 insertions, 0 deletions
diff --git a/results/classifier/zero-shot/118/KVM/530077 b/results/classifier/zero-shot/118/KVM/530077
new file mode 100644
index 000000000..289d25430
--- /dev/null
+++ b/results/classifier/zero-shot/118/KVM/530077
@@ -0,0 +1,46 @@
+KVM: 0.898
+graphic: 0.810
+device: 0.589
+semantic: 0.536
+boot: 0.533
+performance: 0.484
+architecture: 0.483
+hypervisor: 0.467
+kernel: 0.405
+socket: 0.359
+network: 0.350
+user-level: 0.330
+register: 0.317
+permissions: 0.296
+vnc: 0.281
+mistranslation: 0.255
+debug: 0.250
+i386: 0.250
+PID: 0.230
+virtual: 0.227
+risc-v: 0.223
+ppc: 0.218
+files: 0.202
+x86: 0.195
+peripherals: 0.137
+arm: 0.131
+TCG: 0.111
+VMM: 0.109
+assembly: 0.055
+
+kvm: 16-bit code execution failure should be more friendly
+
+Today, when kvm fails at 16-bit code execution, we report:
+
+     spirit:~/qemu> qemu-kvm ./hda-fedora.img 
+     kvm: unhandled exit 80000021
+     kvm_run returned -22
+
+There are three reasons exit reason 21 happens.  The first is that a user is executing an image containing a workload that uses GFXBOOT or some other bootloader that exercises big real mode.  On pre-Westmere Intel processors, VT could not handle big real mode.  The second reason is that the guest's image is corrupted and we're executing random code.  We accidentally fall into one of the unsupported modes for VT.  Again, this is addressed on WSM.  The third case is where there's an actual bug in KVM.  This should be exceedingly rare at this stage.
+
+We should present a friendly error message explaining the possible causes and recommending corrective action.
+
+Triaging old bug tickets... has this ever been fixed, thus could we close this ticket nowadays? Or is there something left to do here?
+
+[Expired for QEMU because there has been no activity for 60 days.]
+