blob: 289d25430ea4b4035dd0c448e487450737aa5f6b (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
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.]
|