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
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
|
permissions: 0.993
debug: 0.993
register: 0.990
files: 0.989
arm: 0.989
assembly: 0.988
PID: 0.988
device: 0.988
performance: 0.987
socket: 0.987
boot: 0.987
architecture: 0.986
risc-v: 0.981
other: 0.979
semantic: 0.974
vnc: 0.972
x86: 0.969
graphic: 0.955
kernel virtual machine: 0.948
mistranslation: 0.930
TCG: 0.917
network: 0.879
[Qemu-devel] [Bug Report] vm paused after succeeding to migrate
Hi, all
I encounterd a bug when I try to migrate a windows vm.
Enviroment information:
host A: cpu E5620(model WestmereEP without flag xsave)
host B: cpu E5-2643(model SandyBridgeEP with xsave)
The reproduce steps is :
1. Start a windows 2008 vm with -cpu host(which means host-passthrough).
2. Migrate the vm to host B when cr4.OSXSAVE=0 (successfully).
3. Vm runs on host B for a while so that cr4.OSXSAVE changes to 1.
4. Then migrate the vm to host A (successfully), but vm was paused, and qemu
printed log as followed:
KVM: entry failed, hardware error 0x80000021
If you're running a guest on an Intel machine without unrestricted mode
support, the failure can be most likely due to the guest entering an invalid
state for Intel VT. For example, the guest maybe running in big real mode
which is not supported on less recent Intel processors.
EAX=019b3bb0 EBX=01a3ae80 ECX=01a61ce8 EDX=00000000
ESI=01a62000 EDI=00000000 EBP=00000000 ESP=01718b20
EIP=0185d982 EFL=00000286 [--S--P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0000 00000000 0000ffff 00009300
CS =f000 ffff0000 0000ffff 00009b00
SS =0000 00000000 0000ffff 00009300
DS =0000 00000000 0000ffff 00009300
FS =0000 00000000 0000ffff 00009300
GS =0000 00000000 0000ffff 00009300
LDT=0000 00000000 0000ffff 00008200
TR =0000 00000000 0000ffff 00008b00
GDT= 00000000 0000ffff
IDT= 00000000 0000ffff
CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000
DR3=0000000000000000
DR6=00000000ffff0ff0 DR7=0000000000000400
EFER=0000000000000000
Code=00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <00> 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
I have found that problem happened when kvm_put_sregs returns err -22(called by
kvm_arch_put_registers(qemu)).
Because kvm_arch_vcpu_ioctl_set_sregs(kvm-mod) checked that guest_cpuid_has no
X86_FEATURE_XSAVE but cr4.OSXSAVE=1.
So should we cancel migration when kvm_arch_put_registers returns error?
* linzhecheng (address@hidden) wrote:
>
Hi, all
>
I encounterd a bug when I try to migrate a windows vm.
>
>
Enviroment information:
>
host A: cpu E5620(model WestmereEP without flag xsave)
>
host B: cpu E5-2643(model SandyBridgeEP with xsave)
>
>
The reproduce steps is :
>
1. Start a windows 2008 vm with -cpu host(which means host-passthrough).
>
2. Migrate the vm to host B when cr4.OSXSAVE=0 (successfully).
>
3. Vm runs on host B for a while so that cr4.OSXSAVE changes to 1.
>
4. Then migrate the vm to host A (successfully), but vm was paused, and qemu
>
printed log as followed:
Remember that migrating using -cpu host across different CPU models is NOT
expected to work.
>
KVM: entry failed, hardware error 0x80000021
>
>
If you're running a guest on an Intel machine without unrestricted mode
>
support, the failure can be most likely due to the guest entering an invalid
>
state for Intel VT. For example, the guest maybe running in big real mode
>
which is not supported on less recent Intel processors.
>
>
EAX=019b3bb0 EBX=01a3ae80 ECX=01a61ce8 EDX=00000000
>
ESI=01a62000 EDI=00000000 EBP=00000000 ESP=01718b20
>
EIP=0185d982 EFL=00000286 [--S--P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
>
ES =0000 00000000 0000ffff 00009300
>
CS =f000 ffff0000 0000ffff 00009b00
>
SS =0000 00000000 0000ffff 00009300
>
DS =0000 00000000 0000ffff 00009300
>
FS =0000 00000000 0000ffff 00009300
>
GS =0000 00000000 0000ffff 00009300
>
LDT=0000 00000000 0000ffff 00008200
>
TR =0000 00000000 0000ffff 00008b00
>
GDT= 00000000 0000ffff
>
IDT= 00000000 0000ffff
>
CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000
>
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000
>
DR3=0000000000000000
>
DR6=00000000ffff0ff0 DR7=0000000000000400
>
EFER=0000000000000000
>
Code=00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <00> 00 00
>
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>
00
>
>
I have found that problem happened when kvm_put_sregs returns err -22(called
>
by kvm_arch_put_registers(qemu)).
>
Because kvm_arch_vcpu_ioctl_set_sregs(kvm-mod) checked that guest_cpuid_has
>
no X86_FEATURE_XSAVE but cr4.OSXSAVE=1.
>
So should we cancel migration when kvm_arch_put_registers returns error?
It would seem good if we can make the migration fail there rather than
hitting that KVM error.
It looks like we need to do a bit of plumbing to convert the places that
call it to return a bool rather than void.
Dave
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK
|