Re: regression bisected; KVM: entry failed, hardware error 0x80000021
On 25/12/2014 08:46, Chen, Tiejun wrote:
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index f528343..910bc48 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -672,6 +672,7 @@ static void update_memslots(struct kvm_memslots *slots,
WARN_ON(mslots[i].id != id);
if (!new-npages) {
new-base_gfn = 0;
+ new-flags = 0;
if (mslots[i].npages)
slots-used_slots--;
} else {
Why is this assignment needed?
Paolo
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: regression bisected; KVM: entry failed, hardware error 0x80000021
Chen, Tiejun wrote:
On 2014/12/24 19:02, Jamie Heilman wrote:
Chen, Tiejun wrote:
On 2014/12/23 15:26, Jamie Heilman wrote:
Chen, Tiejun wrote:
On 2014/12/23 9:50, Chen, Tiejun wrote:
On 2014/12/22 17:23, Jamie Heilman wrote:
KVM internal error. Suberror: 1
emulation failure
EAX=000de494 EBX= ECX= EDX=0cfd
ESI=0059 EDI= EBP= ESP=6fb4
EIP=000f15c1 EFL=00010016 [AP-] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0010 00c09300 DPL=0 DS [-WA]
CS =0008 00c09b00 DPL=0 CS32 [-RA]
SS =0010 00c09300 DPL=0 DS [-WA]
DS =0010 00c09300 DPL=0 DS [-WA]
FS =0010 00c09300 DPL=0 DS [-WA]
GS =0010 00c09300 DPL=0 DS [-WA]
LDT= 8200 DPL=0 LDT
TR = 8b00 DPL=0 TSS32-busy
GDT= 000f6be8 0037
IDT= 000f6c26
CR0=6011 CR2= CR3= CR4=
DR0= DR1= DR2=
DR3=
DR6=0ff0 DR7=0400
EFER=
Code=e8 ae fc ff ff 89 f2 a8 10 89 d8 75 0a b9 41 15 ff ff ff d1 5b
5e c3 5b 5e e9 76 ff ff ff b0 11 e6 20 e6 a0 b0 08 e6 21 b0 70 e6 a1
b0 04 e6 21 b0 02
FWIW, I get the same thing with 34a1cd60d17 reverted. Maybe there are
two bugs, maybe there's more to this first one. I can repro this
So if my understanding is correct, this is probably another bug. And
especially, I already saw the same log in another thread, Cleaning up
the KVM clock. Maybe you can continue to `git bisect` to locate that
bad commit.
Looks just now Andy found that commit,
0e60b0799fedc495a5c57dbd669de3c10d72edd2 kvm: change memslot sorting rule
from size to GFN, maybe you can try to revert this to try yours again.
That doesn't revert cleanly for me, and I don't have much time to
fiddle with it until the 24th---so checked out the commit before it
(d4ae84a0), applied your patch, built, and yes, everything works fine
at that point. I'll probably have time for another full bisection
later, assuming things aren't ironed out already by then.
3.18.0-rc3-00120-gd4ae84a0 + vmx reorder msr writes patch = OK
3.18.0-rc3-00121-g0e60b07 + vmx reorder msr writes patch = emulation failure
So that certainly points to 0e60b0799fedc495a5c57dbd669de3c10d72edd2
as well.
Could you try this to fix your last error?
Running qemu-system-x86_64 -machine pc,accel=kvm -nodefaults works,
my real (headless) kvm guests work, but this new patch makes running
qemu-system-x86_64 -machine pc,accel=kvm fail again, this time with
Are you sure? From my test based on 3.19-rc1 that it owns top commit,
aa39477b5692611b91ac9455ae588738852b3f60
just plus my previous patch, kvm: x86: vmx: reorder some msr writing
I already can execute such a command successfully,
qemu-system-x86_64 -machine pc,accel=kvm -m 2048 -smp 2 -hda ubuntu.img
And your log below seems not to relate mem_slot issue we're discussing, I
guess you need to update qemu as well.
Yes, I'm sure.
But I also found my new patch just work out Andy's next case, its really
bringing a new issue in !next case. So I tried to refine that patch again as
follows,
This latest patch (again, after fixing all the whitespace so it actually
applies), does the trick. Both
qemu-system-x86_64 -machine pc,accel=kvm and
qemu-system-x86_64 -machine pc,accel=kvm -nodefaults work for me
now without any of the aforementioned warnings from the host.
Signed-off-by: Tiejun Chen tiejun.c...@intel.com
---
virt/kvm/kvm_main.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index f528343..910bc48 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -672,6 +672,7 @@ static void update_memslots(struct kvm_memslots *slots,
WARN_ON(mslots[i].id != id);
if (!new-npages) {
new-base_gfn = 0;
+ new-flags = 0;
if (mslots[i].npages)
slots-used_slots--;
} else {
@@ -688,7 +689,9 @@ static void update_memslots(struct kvm_memslots *slots,
i++;
}
while (i 0
- new-base_gfn mslots[i - 1].base_gfn) {
+ ((new-base_gfn mslots[i - 1].base_gfn) ||
+(!new-base_gfn
+ !mslots[i - 1].base_gfn !mslots[i - 1].npages))) {
mslots[i] = mslots[i - 1];
slots-id_to_index[mslots[i].id] = i;
i--;
Tiejun
errors in the host to the tune of:
[ cut here ]
WARNING: CPU: 1 PID: 3901 at arch/x86/kvm/x86.c:6575
kvm_arch_vcpu_ioctl_run+0xd63/0xe5b [kvm]()
Modules linked in: nfsv4 cpufreq_userspace cpufreq_stats cpufreq_powersave
cpufreq_ondemand cpufreq_conservative autofs4 fan nfsd auth_rpcgss nfs lockd
grace fscache sunrpc
Re: regression bisected; KVM: entry failed, hardware error 0x80000021
On 2014/12/25 18:52, Jamie Heilman wrote:
Chen, Tiejun wrote:
On 2014/12/24 19:02, Jamie Heilman wrote:
Chen, Tiejun wrote:
On 2014/12/23 15:26, Jamie Heilman wrote:
Chen, Tiejun wrote:
On 2014/12/23 9:50, Chen, Tiejun wrote:
On 2014/12/22 17:23, Jamie Heilman wrote:
KVM internal error. Suberror: 1
emulation failure
EAX=000de494 EBX= ECX= EDX=0cfd
ESI=0059 EDI= EBP= ESP=6fb4
EIP=000f15c1 EFL=00010016 [AP-] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0010 00c09300 DPL=0 DS [-WA]
CS =0008 00c09b00 DPL=0 CS32 [-RA]
SS =0010 00c09300 DPL=0 DS [-WA]
DS =0010 00c09300 DPL=0 DS [-WA]
FS =0010 00c09300 DPL=0 DS [-WA]
GS =0010 00c09300 DPL=0 DS [-WA]
LDT= 8200 DPL=0 LDT
TR = 8b00 DPL=0 TSS32-busy
GDT= 000f6be8 0037
IDT= 000f6c26
CR0=6011 CR2= CR3= CR4=
DR0= DR1= DR2=
DR3=
DR6=0ff0 DR7=0400
EFER=
Code=e8 ae fc ff ff 89 f2 a8 10 89 d8 75 0a b9 41 15 ff ff ff d1 5b
5e c3 5b 5e e9 76 ff ff ff b0 11 e6 20 e6 a0 b0 08 e6 21 b0 70 e6 a1
b0 04 e6 21 b0 02
FWIW, I get the same thing with 34a1cd60d17 reverted. Maybe there are
two bugs, maybe there's more to this first one. I can repro this
So if my understanding is correct, this is probably another bug. And
especially, I already saw the same log in another thread, Cleaning up
the KVM clock. Maybe you can continue to `git bisect` to locate that
bad commit.
Looks just now Andy found that commit,
0e60b0799fedc495a5c57dbd669de3c10d72edd2 kvm: change memslot sorting rule
from size to GFN, maybe you can try to revert this to try yours again.
That doesn't revert cleanly for me, and I don't have much time to
fiddle with it until the 24th---so checked out the commit before it
(d4ae84a0), applied your patch, built, and yes, everything works fine
at that point. I'll probably have time for another full bisection
later, assuming things aren't ironed out already by then.
3.18.0-rc3-00120-gd4ae84a0 + vmx reorder msr writes patch = OK
3.18.0-rc3-00121-g0e60b07 + vmx reorder msr writes patch = emulation failure
So that certainly points to 0e60b0799fedc495a5c57dbd669de3c10d72edd2
as well.
Could you try this to fix your last error?
Running qemu-system-x86_64 -machine pc,accel=kvm -nodefaults works,
my real (headless) kvm guests work, but this new patch makes running
qemu-system-x86_64 -machine pc,accel=kvm fail again, this time with
Are you sure? From my test based on 3.19-rc1 that it owns top commit,
aa39477b5692611b91ac9455ae588738852b3f60
just plus my previous patch, kvm: x86: vmx: reorder some msr writing
I already can execute such a command successfully,
qemu-system-x86_64 -machine pc,accel=kvm -m 2048 -smp 2 -hda ubuntu.img
And your log below seems not to relate mem_slot issue we're discussing, I
guess you need to update qemu as well.
Yes, I'm sure.
But I also found my new patch just work out Andy's next case, its really
bringing a new issue in !next case. So I tried to refine that patch again as
follows,
This latest patch (again, after fixing all the whitespace so it actually
Next time I guess I need to post that as a attached file :)
applies), does the trick. Both
qemu-system-x86_64 -machine pc,accel=kvm and
qemu-system-x86_64 -machine pc,accel=kvm -nodefaults work for me
now without any of the aforementioned warnings from the host.
Sounds great and thanks for your test again.
Tiejun
Signed-off-by: Tiejun Chen tiejun.c...@intel.com
---
virt/kvm/kvm_main.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index f528343..910bc48 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -672,6 +672,7 @@ static void update_memslots(struct kvm_memslots *slots,
WARN_ON(mslots[i].id != id);
if (!new-npages) {
new-base_gfn = 0;
+ new-flags = 0;
if (mslots[i].npages)
slots-used_slots--;
} else {
@@ -688,7 +689,9 @@ static void update_memslots(struct kvm_memslots *slots,
i++;
}
while (i 0
- new-base_gfn mslots[i - 1].base_gfn) {
+ ((new-base_gfn mslots[i - 1].base_gfn) ||
+(!new-base_gfn
+ !mslots[i - 1].base_gfn !mslots[i - 1].npages))) {
mslots[i] = mslots[i - 1];
slots-id_to_index[mslots[i].id] = i;
i--;
Tiejun
errors in the host to the tune of:
[ cut here ]
WARNING: CPU: 1 PID: 3901 at arch/x86/kvm/x86.c:6575
kvm_arch_vcpu_ioctl_run+0xd63/0xe5b [kvm]()
Modules linked in: nfsv4 cpufreq_userspace cpufreq_stats cpufreq_powersave
cpufreq_ondemand
Re: regression bisected; KVM: entry failed, hardware error 0x80000021
On 2014/12/23 15:26, Jamie Heilman wrote: Chen, Tiejun wrote: On 2014/12/23 9:50, Chen, Tiejun wrote: On 2014/12/22 17:23, Jamie Heilman wrote: Chen, Tiejun wrote: On 2014/12/21 20:46, Jamie Heilman wrote: With v3.19-rc1 when I run qemu-system-x86_64 -machine pc,accel=kvm I get: KVM: entry failed, hardware error 0x8021 Looks some MSR writing issues such a failed entry. 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= EBX= ECX= EDX=0663 ESI= EDI= EBP= ESP= EIP=e05b EFL=00010002 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES = 9300 CS =f000 000f 9b00 SS = 9300 DS = 9300 FS = 9300 GS = 9300 LDT= 8200 TR = 8b00 GDT= IDT= CR0=6010 CR2= CR3= CR4= DR0= DR1= DR2= DR3= DR6=0ff0 DR7=0400 EFER= And I don't see any obvious wrong as well. Any valuable info from dmesg? With the simple qemu command above, on 3.18.1 I see: kern.info: kvm: zapping shadow pages for mmio generation wraparound when I fire up a full guest that's actually useful I get: kern.info: kvm: zapping shadow pages for mmio generation wraparound kern.err: kvm [4073]: vcpu0 disabled perfctr wrmsr: 0xc1 data 0x On 3.18.0-rc3-00042-g34a1cd6 nothing appears in the dmesg, just the message I mention above to stderr. Same thing with a stock 3.19.0-rc1. Once I apply your patch the simple test command produces the same zapping shadow pages messages as 3.18.1, and a test guest of a Debian Jessie image (w/stock distro kernel) produces the same thing with disabled perfctr wrmsr message. However, it doesn't look like Sorry I'm not sure if I understood current status. Looks 3.19-rc1 my patch just fix that error above, KVM: entry failed, hardware error 0x8021 ... Right? I'm entirely out of the woods, because one of my other guest VMs with a custom kernel that works great under 3.18.1 now fails to run. Nothing in dmesg, but here's the stderr: But even you revert 34a1cd60d17 or just apply my patch, something else introduced between 3.18.1 and 3.19-rc1 led this error below, right? KVM internal error. Suberror: 1 emulation failure EAX=000de494 EBX= ECX= EDX=0cfd ESI=0059 EDI= EBP= ESP=6fb4 EIP=000f15c1 EFL=00010016 [AP-] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0010 00c09300 DPL=0 DS [-WA] CS =0008 00c09b00 DPL=0 CS32 [-RA] SS =0010 00c09300 DPL=0 DS [-WA] DS =0010 00c09300 DPL=0 DS [-WA] FS =0010 00c09300 DPL=0 DS [-WA] GS =0010 00c09300 DPL=0 DS [-WA] LDT= 8200 DPL=0 LDT TR = 8b00 DPL=0 TSS32-busy GDT= 000f6be8 0037 IDT= 000f6c26 CR0=6011 CR2= CR3= CR4= DR0= DR1= DR2= DR3= DR6=0ff0 DR7=0400 EFER= Code=e8 ae fc ff ff 89 f2 a8 10 89 d8 75 0a b9 41 15 ff ff ff d1 5b 5e c3 5b 5e e9 76 ff ff ff b0 11 e6 20 e6 a0 b0 08 e6 21 b0 70 e6 a1 b0 04 e6 21 b0 02 FWIW, I get the same thing with 34a1cd60d17 reverted. Maybe there are two bugs, maybe there's more to this first one. I can repro this So if my understanding is correct, this is probably another bug. And especially, I already saw the same log in another thread, Cleaning up the KVM clock. Maybe you can continue to `git bisect` to locate that bad commit. Looks just now Andy found that commit, 0e60b0799fedc495a5c57dbd669de3c10d72edd2 kvm: change memslot sorting rule from size to GFN, maybe you can try to revert this to try yours again. That doesn't revert cleanly for me, and I don't have much time to fiddle with it until the 24th---so checked out the commit before it (d4ae84a0), applied your patch, built, and yes, everything works fine at that point. I'll probably have time for another full bisection later, assuming things aren't ironed out already by then. Could you try this to fix your last error? Signed-off-by: Tiejun Chen tiejun.c...@intel.com --- virt/kvm/kvm_main.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index f528343..a2d928c 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -672,6 +672,7 @@ static void update_memslots(struct kvm_memslots *slots, WARN_ON
Re: regression bisected; KVM: entry failed, hardware error 0x80000021
Chen, Tiejun wrote: On 2014/12/23 15:26, Jamie Heilman wrote: Chen, Tiejun wrote: On 2014/12/23 9:50, Chen, Tiejun wrote: On 2014/12/22 17:23, Jamie Heilman wrote: KVM internal error. Suberror: 1 emulation failure EAX=000de494 EBX= ECX= EDX=0cfd ESI=0059 EDI= EBP= ESP=6fb4 EIP=000f15c1 EFL=00010016 [AP-] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0010 00c09300 DPL=0 DS [-WA] CS =0008 00c09b00 DPL=0 CS32 [-RA] SS =0010 00c09300 DPL=0 DS [-WA] DS =0010 00c09300 DPL=0 DS [-WA] FS =0010 00c09300 DPL=0 DS [-WA] GS =0010 00c09300 DPL=0 DS [-WA] LDT= 8200 DPL=0 LDT TR = 8b00 DPL=0 TSS32-busy GDT= 000f6be8 0037 IDT= 000f6c26 CR0=6011 CR2= CR3= CR4= DR0= DR1= DR2= DR3= DR6=0ff0 DR7=0400 EFER= Code=e8 ae fc ff ff 89 f2 a8 10 89 d8 75 0a b9 41 15 ff ff ff d1 5b 5e c3 5b 5e e9 76 ff ff ff b0 11 e6 20 e6 a0 b0 08 e6 21 b0 70 e6 a1 b0 04 e6 21 b0 02 FWIW, I get the same thing with 34a1cd60d17 reverted. Maybe there are two bugs, maybe there's more to this first one. I can repro this So if my understanding is correct, this is probably another bug. And especially, I already saw the same log in another thread, Cleaning up the KVM clock. Maybe you can continue to `git bisect` to locate that bad commit. Looks just now Andy found that commit, 0e60b0799fedc495a5c57dbd669de3c10d72edd2 kvm: change memslot sorting rule from size to GFN, maybe you can try to revert this to try yours again. That doesn't revert cleanly for me, and I don't have much time to fiddle with it until the 24th---so checked out the commit before it (d4ae84a0), applied your patch, built, and yes, everything works fine at that point. I'll probably have time for another full bisection later, assuming things aren't ironed out already by then. 3.18.0-rc3-00120-gd4ae84a0 + vmx reorder msr writes patch = OK 3.18.0-rc3-00121-g0e60b07 + vmx reorder msr writes patch = emulation failure So that certainly points to 0e60b0799fedc495a5c57dbd669de3c10d72edd2 as well. Could you try this to fix your last error? Running qemu-system-x86_64 -machine pc,accel=kvm -nodefaults works, my real (headless) kvm guests work, but this new patch makes running qemu-system-x86_64 -machine pc,accel=kvm fail again, this time with errors in the host to the tune of: [ cut here ] WARNING: CPU: 1 PID: 3901 at arch/x86/kvm/x86.c:6575 kvm_arch_vcpu_ioctl_run+0xd63/0xe5b [kvm]() Modules linked in: nfsv4 cpufreq_userspace cpufreq_stats cpufreq_powersave cpufreq_ondemand cpufreq_conservative autofs4 fan nfsd auth_rpcgss nfs lockd grace fscache sunrpc bridge stp llc vhost_net tun vhost macvtap macvlan fuse cbc dm_crypt usb_storage snd_hda_codec_analog snd_hda_codec_generic kvm_intel kvm tg3 ptp pps_core sr_mod snd_hda_intel snd_hda_controller snd_hda_codec snd_hwdep snd_pcm snd_timer snd sg dcdbas cdrom psmouse soundcore floppy evdev xfs dm_mod raid1 md_mod CPU: 1 PID: 3901 Comm: qemu-system-x86 Not tainted 3.19.0-rc1-00011-g53262d1-dirty #1 Hardware name: Dell Inc. Precision WorkStation T3400 /0TP412, BIOS A14 04/30/2012 7e052328 8800c25ffcf8 813defbe 8800c25ffd38 8103b517 8800c25ffd28 a019bdec 8800caf1d000 8800c2774800 Call Trace: [813defbe] dump_stack+0x4c/0x6e [8103b517] warn_slowpath_common+0x97/0xb1 [a019bdec] ? kvm_arch_vcpu_ioctl_run+0xd63/0xe5b [kvm] [8103b60b] warn_slowpath_null+0x15/0x17 [a019bdec] kvm_arch_vcpu_ioctl_run+0xd63/0xe5b [kvm] [a02308b9] ? vmcs_load+0x20/0x62 [kvm_intel] [a0231e03] ? vmx_vcpu_load+0x140/0x16a [kvm_intel] [a0196ba3] ? kvm_arch_vcpu_load+0x15c/0x161 [kvm] [a018d8b1] kvm_vcpu_ioctl+0x189/0x4bd [kvm] [8104647a] ? do_sigtimedwait+0x12f/0x189 [810ea316] do_vfs_ioctl+0x370/0x436 [810f24f2] ? __fget+0x67/0x72 [810ea41b] SyS_ioctl+0x3f/0x5e [813e34d2] system_call_fastpath+0x12/0x17 ---[ end trace 46abac932fb3b4a1 ]--- [ cut here ] WARNING: CPU: 1 PID: 3901 at arch/x86/kvm/x86.c:6575 kvm_arch_vcpu_ioctl_run+0xd63/0xe5b [kvm]() Modules linked in: nfsv4 cpufreq_userspace cpufreq_stats cpufreq_powersave cpufreq_ondemand cpufreq_conservative autofs4 fan nfsd auth_rpcgss nfs lockd grace fscache sunrpc bridge stp llc vhost_net tun vhost macvtap macvlan fuse cbc dm_crypt usb_storage snd_hda_codec_analog snd_hda_codec_generic kvm_intel kvm tg3 ptp pps_core sr_mod snd_hda_intel snd_hda_controller snd_hda_codec snd_hwdep snd_pcm snd_timer snd sg dcdbas cdrom psmouse soundcore
Re: regression bisected; KVM: entry failed, hardware error 0x80000021
On 24/12/2014 12:02, Jamie Heilman wrote:
Running qemu-system-x86_64 -machine pc,accel=kvm -nodefaults works,
my real (headless) kvm guests work, but this new patch makes running
qemu-system-x86_64 -machine pc,accel=kvm fail again, this time with
errors in the host to the tune of:
[ cut here ]
WARNING: CPU: 1 PID: 3901 at arch/x86/kvm/x86.c:6575
kvm_arch_vcpu_ioctl_run+0xd63/0xe5b [kvm]()
Modules linked in: nfsv4 cpufreq_userspace cpufreq_stats cpufreq_powersave
cpufreq_ondemand cpufreq_conservative autofs4 fan nfsd auth_rpcgss nfs lockd
grace fscache sunrpc bridge stp llc vhost_net tun vhost macvtap macvlan fuse
cbc dm_crypt usb_storage snd_hda_codec_analog snd_hda_codec_generic kvm_intel
kvm tg3 ptp pps_core sr_mod snd_hda_intel snd_hda_controller snd_hda_codec
snd_hwdep snd_pcm snd_timer snd sg dcdbas cdrom psmouse soundcore floppy
evdev xfs dm_mod raid1 md_mod
CPU: 1 PID: 3901 Comm: qemu-system-x86 Not tainted
3.19.0-rc1-00011-g53262d1-dirty #1
Hardware name: Dell Inc. Precision WorkStation T3400 /0TP412, BIOS A14
04/30/2012
7e052328 8800c25ffcf8 813defbe
8800c25ffd38 8103b517
8800c25ffd28 a019bdec 8800caf1d000 8800c2774800
Call Trace:
[813defbe] dump_stack+0x4c/0x6e
[8103b517] warn_slowpath_common+0x97/0xb1
[a019bdec] ? kvm_arch_vcpu_ioctl_run+0xd63/0xe5b [kvm]
[8103b60b] warn_slowpath_null+0x15/0x17
[a019bdec] kvm_arch_vcpu_ioctl_run+0xd63/0xe5b [kvm]
[a02308b9] ? vmcs_load+0x20/0x62 [kvm_intel]
[a0231e03] ? vmx_vcpu_load+0x140/0x16a [kvm_intel]
[a0196ba3] ? kvm_arch_vcpu_load+0x15c/0x161 [kvm]
[a018d8b1] kvm_vcpu_ioctl+0x189/0x4bd [kvm]
[8104647a] ? do_sigtimedwait+0x12f/0x189
[810ea316] do_vfs_ioctl+0x370/0x436
[810f24f2] ? __fget+0x67/0x72
[810ea41b] SyS_ioctl+0x3f/0x5e
[813e34d2] system_call_fastpath+0x12/0x17
---[ end trace 46abac932fb3b4a1 ]---
[ cut here ]
WARNING: CPU: 1 PID: 3901 at arch/x86/kvm/x86.c:6575
kvm_arch_vcpu_ioctl_run+0xd63/0xe5b [kvm]()
Modules linked in: nfsv4 cpufreq_userspace cpufreq_stats cpufreq_powersave
cpufreq_ondemand cpufreq_conservative autofs4 fan nfsd auth_rpcgss nfs lockd
grace fscache sunrpc bridge stp llc vhost_net tun vhost macvtap macvlan fuse
cbc dm_crypt usb_storage snd_hda_codec_analog snd_hda_codec_generic kvm_intel
kvm tg3 ptp pps_core sr_mod snd_hda_intel snd_hda_controller snd_hda_codec
snd_hwdep snd_pcm snd_timer snd sg dcdbas cdrom psmouse soundcore floppy
evdev xfs dm_mod raid1 md_mod
CPU: 1 PID: 3901 Comm: qemu-system-x86 Tainted: GW
3.19.0-rc1-00011-g53262d1-dirty #1
Hardware name: Dell Inc. Precision WorkStation T3400 /0TP412, BIOS A14
04/30/2012
7e052328 8800c25ffcf8 813defbe
8800c25ffd38 8103b517
8800c25ffd28 a019bdec 8800caf1d000 8800c2774800
Call Trace:
[813defbe] dump_stack+0x4c/0x6e
[8103b517] warn_slowpath_common+0x97/0xb1
[a019bdec] ? kvm_arch_vcpu_ioctl_run+0xd63/0xe5b [kvm]
[8103b60b] warn_slowpath_null+0x15/0x17
[a019bdec] kvm_arch_vcpu_ioctl_run+0xd63/0xe5b [kvm]
[a02308b9] ? vmcs_load+0x20/0x62 [kvm_intel]
[a0231e03] ? vmx_vcpu_load+0x140/0x16a [kvm_intel]
[a0196ba3] ? kvm_arch_vcpu_load+0x15c/0x161 [kvm]
[a018d8b1] kvm_vcpu_ioctl+0x189/0x4bd [kvm]
[8104647a] ? do_sigtimedwait+0x12f/0x189
[810ea316] do_vfs_ioctl+0x370/0x436
[810f24f2] ? __fget+0x67/0x72
[810ea41b] SyS_ioctl+0x3f/0x5e
[813e34d2] system_call_fastpath+0x12/0x17
---[ end trace 46abac932fb3b4a2 ]---
over and over and over ad nauseum, or until I kill the qemu command,
it also eats a core's worth of cpu.
Yeah, I'm fairly sure that the second hunk of Tiejun's patch is not
correct, but he's on the right track. I hope to post a fix today, else
on the 27th or 29th.
Paolo
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: regression bisected; KVM: entry failed, hardware error 0x80000021
On 2014/12/24 19:02, Jamie Heilman wrote:
Chen, Tiejun wrote:
On 2014/12/23 15:26, Jamie Heilman wrote:
Chen, Tiejun wrote:
On 2014/12/23 9:50, Chen, Tiejun wrote:
On 2014/12/22 17:23, Jamie Heilman wrote:
KVM internal error. Suberror: 1
emulation failure
EAX=000de494 EBX= ECX= EDX=0cfd
ESI=0059 EDI= EBP= ESP=6fb4
EIP=000f15c1 EFL=00010016 [AP-] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0010 00c09300 DPL=0 DS [-WA]
CS =0008 00c09b00 DPL=0 CS32 [-RA]
SS =0010 00c09300 DPL=0 DS [-WA]
DS =0010 00c09300 DPL=0 DS [-WA]
FS =0010 00c09300 DPL=0 DS [-WA]
GS =0010 00c09300 DPL=0 DS [-WA]
LDT= 8200 DPL=0 LDT
TR = 8b00 DPL=0 TSS32-busy
GDT= 000f6be8 0037
IDT= 000f6c26
CR0=6011 CR2= CR3= CR4=
DR0= DR1= DR2=
DR3=
DR6=0ff0 DR7=0400
EFER=
Code=e8 ae fc ff ff 89 f2 a8 10 89 d8 75 0a b9 41 15 ff ff ff d1 5b
5e c3 5b 5e e9 76 ff ff ff b0 11 e6 20 e6 a0 b0 08 e6 21 b0 70 e6 a1
b0 04 e6 21 b0 02
FWIW, I get the same thing with 34a1cd60d17 reverted. Maybe there are
two bugs, maybe there's more to this first one. I can repro this
So if my understanding is correct, this is probably another bug. And
especially, I already saw the same log in another thread, Cleaning up
the KVM clock. Maybe you can continue to `git bisect` to locate that
bad commit.
Looks just now Andy found that commit,
0e60b0799fedc495a5c57dbd669de3c10d72edd2 kvm: change memslot sorting rule
from size to GFN, maybe you can try to revert this to try yours again.
That doesn't revert cleanly for me, and I don't have much time to
fiddle with it until the 24th---so checked out the commit before it
(d4ae84a0), applied your patch, built, and yes, everything works fine
at that point. I'll probably have time for another full bisection
later, assuming things aren't ironed out already by then.
3.18.0-rc3-00120-gd4ae84a0 + vmx reorder msr writes patch = OK
3.18.0-rc3-00121-g0e60b07 + vmx reorder msr writes patch = emulation failure
So that certainly points to 0e60b0799fedc495a5c57dbd669de3c10d72edd2
as well.
Could you try this to fix your last error?
Running qemu-system-x86_64 -machine pc,accel=kvm -nodefaults works,
my real (headless) kvm guests work, but this new patch makes running
qemu-system-x86_64 -machine pc,accel=kvm fail again, this time with
Are you sure? From my test based on 3.19-rc1 that it owns top commit,
aa39477b5692611b91ac9455ae588738852b3f60
just plus my previous patch, kvm: x86: vmx: reorder some msr writing
I already can execute such a command successfully,
qemu-system-x86_64 -machine pc,accel=kvm -m 2048 -smp 2 -hda ubuntu.img
And your log below seems not to relate mem_slot issue we're discussing,
I guess you need to update qemu as well.
But I also found my new patch just work out Andy's next case, its really
bringing a new issue in !next case. So I tried to refine that patch
again as follows,
Signed-off-by: Tiejun Chen tiejun.c...@intel.com
---
virt/kvm/kvm_main.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index f528343..910bc48 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -672,6 +672,7 @@ static void update_memslots(struct kvm_memslots *slots,
WARN_ON(mslots[i].id != id);
if (!new-npages) {
new-base_gfn = 0;
+ new-flags = 0;
if (mslots[i].npages)
slots-used_slots--;
} else {
@@ -688,7 +689,9 @@ static void update_memslots(struct kvm_memslots *slots,
i++;
}
while (i 0
- new-base_gfn mslots[i - 1].base_gfn) {
+ ((new-base_gfn mslots[i - 1].base_gfn) ||
+(!new-base_gfn
+ !mslots[i - 1].base_gfn !mslots[i - 1].npages))) {
mslots[i] = mslots[i - 1];
slots-id_to_index[mslots[i].id] = i;
i--;
Tiejun
errors in the host to the tune of:
[ cut here ]
WARNING: CPU: 1 PID: 3901 at arch/x86/kvm/x86.c:6575
kvm_arch_vcpu_ioctl_run+0xd63/0xe5b [kvm]()
Modules linked in: nfsv4 cpufreq_userspace cpufreq_stats cpufreq_powersave
cpufreq_ondemand cpufreq_conservative autofs4 fan nfsd auth_rpcgss nfs lockd
grace fscache sunrpc bridge stp llc vhost_net tun vhost macvtap macvlan fuse
cbc dm_crypt usb_storage snd_hda_codec_analog snd_hda_codec_generic kvm_intel
kvm tg3 ptp pps_core sr_mod snd_hda_intel snd_hda_controller snd_hda_codec
snd_hwdep snd_pcm snd_timer snd sg dcdbas cdrom psmouse soundcore floppy evdev
xfs dm_mod raid1 md_mod
CPU: 1 PID: 3901 Comm: qemu-system-x86 Not tainted
3.19.0-rc1-00011-g53262d1-dirty #1
Hardware
Re: regression bisected; KVM: entry failed, hardware error 0x80000021
On 2014/12/24 19:11, Paolo Bonzini wrote:
On 24/12/2014 12:02, Jamie Heilman wrote:
Running qemu-system-x86_64 -machine pc,accel=kvm -nodefaults works,
my real (headless) kvm guests work, but this new patch makes running
qemu-system-x86_64 -machine pc,accel=kvm fail again, this time with
errors in the host to the tune of:
[ cut here ]
WARNING: CPU: 1 PID: 3901 at arch/x86/kvm/x86.c:6575
kvm_arch_vcpu_ioctl_run+0xd63/0xe5b [kvm]()
Modules linked in: nfsv4 cpufreq_userspace cpufreq_stats cpufreq_powersave
cpufreq_ondemand cpufreq_conservative autofs4 fan nfsd auth_rpcgss nfs lockd
grace fscache sunrpc bridge stp llc vhost_net tun vhost macvtap macvlan fuse
cbc dm_crypt usb_storage snd_hda_codec_analog snd_hda_codec_generic kvm_intel
kvm tg3 ptp pps_core sr_mod snd_hda_intel snd_hda_controller snd_hda_codec
snd_hwdep snd_pcm snd_timer snd sg dcdbas cdrom psmouse soundcore floppy evdev
xfs dm_mod raid1 md_mod
CPU: 1 PID: 3901 Comm: qemu-system-x86 Not tainted
3.19.0-rc1-00011-g53262d1-dirty #1
Hardware name: Dell Inc. Precision WorkStation T3400 /0TP412, BIOS A14
04/30/2012
7e052328 8800c25ffcf8 813defbe
8800c25ffd38 8103b517
8800c25ffd28 a019bdec 8800caf1d000 8800c2774800
Call Trace:
[813defbe] dump_stack+0x4c/0x6e
[8103b517] warn_slowpath_common+0x97/0xb1
[a019bdec] ? kvm_arch_vcpu_ioctl_run+0xd63/0xe5b [kvm]
[8103b60b] warn_slowpath_null+0x15/0x17
[a019bdec] kvm_arch_vcpu_ioctl_run+0xd63/0xe5b [kvm]
[a02308b9] ? vmcs_load+0x20/0x62 [kvm_intel]
[a0231e03] ? vmx_vcpu_load+0x140/0x16a [kvm_intel]
[a0196ba3] ? kvm_arch_vcpu_load+0x15c/0x161 [kvm]
[a018d8b1] kvm_vcpu_ioctl+0x189/0x4bd [kvm]
[8104647a] ? do_sigtimedwait+0x12f/0x189
[810ea316] do_vfs_ioctl+0x370/0x436
[810f24f2] ? __fget+0x67/0x72
[810ea41b] SyS_ioctl+0x3f/0x5e
[813e34d2] system_call_fastpath+0x12/0x17
---[ end trace 46abac932fb3b4a1 ]---
[ cut here ]
WARNING: CPU: 1 PID: 3901 at arch/x86/kvm/x86.c:6575
kvm_arch_vcpu_ioctl_run+0xd63/0xe5b [kvm]()
Modules linked in: nfsv4 cpufreq_userspace cpufreq_stats cpufreq_powersave
cpufreq_ondemand cpufreq_conservative autofs4 fan nfsd auth_rpcgss nfs lockd
grace fscache sunrpc bridge stp llc vhost_net tun vhost macvtap macvlan fuse
cbc dm_crypt usb_storage snd_hda_codec_analog snd_hda_codec_generic kvm_intel
kvm tg3 ptp pps_core sr_mod snd_hda_intel snd_hda_controller snd_hda_codec
snd_hwdep snd_pcm snd_timer snd sg dcdbas cdrom psmouse soundcore floppy evdev
xfs dm_mod raid1 md_mod
CPU: 1 PID: 3901 Comm: qemu-system-x86 Tainted: GW
3.19.0-rc1-00011-g53262d1-dirty #1
Hardware name: Dell Inc. Precision WorkStation T3400 /0TP412, BIOS A14
04/30/2012
7e052328 8800c25ffcf8 813defbe
8800c25ffd38 8103b517
8800c25ffd28 a019bdec 8800caf1d000 8800c2774800
Call Trace:
[813defbe] dump_stack+0x4c/0x6e
[8103b517] warn_slowpath_common+0x97/0xb1
[a019bdec] ? kvm_arch_vcpu_ioctl_run+0xd63/0xe5b [kvm]
[8103b60b] warn_slowpath_null+0x15/0x17
[a019bdec] kvm_arch_vcpu_ioctl_run+0xd63/0xe5b [kvm]
[a02308b9] ? vmcs_load+0x20/0x62 [kvm_intel]
[a0231e03] ? vmx_vcpu_load+0x140/0x16a [kvm_intel]
[a0196ba3] ? kvm_arch_vcpu_load+0x15c/0x161 [kvm]
[a018d8b1] kvm_vcpu_ioctl+0x189/0x4bd [kvm]
[8104647a] ? do_sigtimedwait+0x12f/0x189
[810ea316] do_vfs_ioctl+0x370/0x436
[810f24f2] ? __fget+0x67/0x72
[810ea41b] SyS_ioctl+0x3f/0x5e
[813e34d2] system_call_fastpath+0x12/0x17
---[ end trace 46abac932fb3b4a2 ]---
over and over and over ad nauseum, or until I kill the qemu command,
it also eats a core's worth of cpu.
Such a message above seems to be out of our mem_slot issue, I'm not 100%
sure but actually I can run this case,
qemu-system-x86_64 -machine pc,accel=kvm -m 2048 -smp 2 -hda ubuntu.img
Just one patch, kvm: x86: vmx: reorder some msr writing, is needed
here. So I guess you guy can try to pull your 3.19-rc1 + that patch, and
also pull qemu.
Yeah, I'm fairly sure that the second hunk of Tiejun's patch is not
correct, but he's on the right track. I hope to post a fix today, else
Yeah, looks that will broken !next case then I regenerate that again
post into another email. Now at lease I myself can run Andy's next case
and a normal case, qemu-system-x86_64 -machine pc,accel=kvm, at the
same time. But if I'm missing something please correct me directly :)
Tiejun
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: regression bisected; KVM: entry failed, hardware error 0x80000021
Chen, Tiejun wrote: On 2014/12/21 20:46, Jamie Heilman wrote: With v3.19-rc1 when I run qemu-system-x86_64 -machine pc,accel=kvm I get: KVM: entry failed, hardware error 0x8021 Looks some MSR writing issues such a failed entry. 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= EBX= ECX= EDX=0663 ESI= EDI= EBP= ESP= EIP=e05b EFL=00010002 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES = 9300 CS =f000 000f 9b00 SS = 9300 DS = 9300 FS = 9300 GS = 9300 LDT= 8200 TR = 8b00 GDT= IDT= CR0=6010 CR2= CR3= CR4= DR0= DR1= DR2= DR3= DR6=0ff0 DR7=0400 EFER= And I don't see any obvious wrong as well. Any valuable info from dmesg? With the simple qemu command above, on 3.18.1 I see: kern.info: kvm: zapping shadow pages for mmio generation wraparound when I fire up a full guest that's actually useful I get: kern.info: kvm: zapping shadow pages for mmio generation wraparound kern.err: kvm [4073]: vcpu0 disabled perfctr wrmsr: 0xc1 data 0x On 3.18.0-rc3-00042-g34a1cd6 nothing appears in the dmesg, just the message I mention above to stderr. Same thing with a stock 3.19.0-rc1. Once I apply your patch the simple test command produces the same zapping shadow pages messages as 3.18.1, and a test guest of a Debian Jessie image (w/stock distro kernel) produces the same thing with disabled perfctr wrmsr message. However, it doesn't look like I'm entirely out of the woods, because one of my other guest VMs with a custom kernel that works great under 3.18.1 now fails to run. Nothing in dmesg, but here's the stderr: KVM internal error. Suberror: 1 emulation failure EAX=000de494 EBX= ECX= EDX=0cfd ESI=0059 EDI= EBP= ESP=6fb4 EIP=000f15c1 EFL=00010016 [AP-] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0010 00c09300 DPL=0 DS [-WA] CS =0008 00c09b00 DPL=0 CS32 [-RA] SS =0010 00c09300 DPL=0 DS [-WA] DS =0010 00c09300 DPL=0 DS [-WA] FS =0010 00c09300 DPL=0 DS [-WA] GS =0010 00c09300 DPL=0 DS [-WA] LDT= 8200 DPL=0 LDT TR = 8b00 DPL=0 TSS32-busy GDT= 000f6be8 0037 IDT= 000f6c26 CR0=6011 CR2= CR3= CR4= DR0= DR1= DR2= DR3= DR6=0ff0 DR7=0400 EFER= Code=e8 ae fc ff ff 89 f2 a8 10 89 d8 75 0a b9 41 15 ff ff ff d1 5b 5e c3 5b 5e e9 76 ff ff ff b0 11 e6 20 e6 a0 b0 08 e6 21 b0 70 e6 a1 b0 04 e6 21 b0 02 FWIW, I get the same thing with 34a1cd60d17 reverted. Maybe there are two bugs, maybe there's more to this first one. I can repro this error with the command: qemu-system-x86_64 -machine pc,accel=kvm -nodefaults This is with QEMU emulator version 2.1.2 (Debian 1:2.1+dfsg-11), Copyright (c) 2003-2008 Fabrice Bellard The host system is: cpu family : 6 model : 23 model name : Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz stepping: 10 microcode : 0xa0b ... flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm dtherm tpr_shadow vnmi flexpriority I bisected this back to: commit 34a1cd60d17f62c1f077c1478a6c2ca8c3d17af4 Author: Tiejun Chen tiejun.c...@intel.com Date: Tue Oct 28 10:14:48 2014 +0800 kvm: x86: vmx: move some vmx setting from vmx_init() to hardware_setup() Instead of vmx_init(), actually it would make reasonable sense to do anything specific to vmx hardware setting in vmx_x86_ops-hardware_setup(). This commit just reorders something but some MSR writing depend on previous status. Could you try this? I unmangled the expanded tabs, and applied this: diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c index feb852b..96c84a8 100644 --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/vmx.c @@ -5840,49 +5840,6 @@ static __init int hardware_setup(void) memset(vmx_msr_bitmap_legacy, 0xff, PAGE_SIZE); memset(vmx_msr_bitmap_longmode
Re: regression bisected; KVM: entry failed, hardware error 0x80000021
On 2014/12/22 17:23, Jamie Heilman wrote: Chen, Tiejun wrote: On 2014/12/21 20:46, Jamie Heilman wrote: With v3.19-rc1 when I run qemu-system-x86_64 -machine pc,accel=kvm I get: KVM: entry failed, hardware error 0x8021 Looks some MSR writing issues such a failed entry. 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= EBX= ECX= EDX=0663 ESI= EDI= EBP= ESP= EIP=e05b EFL=00010002 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES = 9300 CS =f000 000f 9b00 SS = 9300 DS = 9300 FS = 9300 GS = 9300 LDT= 8200 TR = 8b00 GDT= IDT= CR0=6010 CR2= CR3= CR4= DR0= DR1= DR2= DR3= DR6=0ff0 DR7=0400 EFER= And I don't see any obvious wrong as well. Any valuable info from dmesg? With the simple qemu command above, on 3.18.1 I see: kern.info: kvm: zapping shadow pages for mmio generation wraparound when I fire up a full guest that's actually useful I get: kern.info: kvm: zapping shadow pages for mmio generation wraparound kern.err: kvm [4073]: vcpu0 disabled perfctr wrmsr: 0xc1 data 0x On 3.18.0-rc3-00042-g34a1cd6 nothing appears in the dmesg, just the message I mention above to stderr. Same thing with a stock 3.19.0-rc1. Once I apply your patch the simple test command produces the same zapping shadow pages messages as 3.18.1, and a test guest of a Debian Jessie image (w/stock distro kernel) produces the same thing with disabled perfctr wrmsr message. However, it doesn't look like Sorry I'm not sure if I understood current status. Looks 3.19-rc1 my patch just fix that error above, KVM: entry failed, hardware error 0x8021 ... Right? I'm entirely out of the woods, because one of my other guest VMs with a custom kernel that works great under 3.18.1 now fails to run. Nothing in dmesg, but here's the stderr: But even you revert 34a1cd60d17 or just apply my patch, something else introduced between 3.18.1 and 3.19-rc1 led this error below, right? KVM internal error. Suberror: 1 emulation failure EAX=000de494 EBX= ECX= EDX=0cfd ESI=0059 EDI= EBP= ESP=6fb4 EIP=000f15c1 EFL=00010016 [AP-] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0010 00c09300 DPL=0 DS [-WA] CS =0008 00c09b00 DPL=0 CS32 [-RA] SS =0010 00c09300 DPL=0 DS [-WA] DS =0010 00c09300 DPL=0 DS [-WA] FS =0010 00c09300 DPL=0 DS [-WA] GS =0010 00c09300 DPL=0 DS [-WA] LDT= 8200 DPL=0 LDT TR = 8b00 DPL=0 TSS32-busy GDT= 000f6be8 0037 IDT= 000f6c26 CR0=6011 CR2= CR3= CR4= DR0= DR1= DR2= DR3= DR6=0ff0 DR7=0400 EFER= Code=e8 ae fc ff ff 89 f2 a8 10 89 d8 75 0a b9 41 15 ff ff ff d1 5b 5e c3 5b 5e e9 76 ff ff ff b0 11 e6 20 e6 a0 b0 08 e6 21 b0 70 e6 a1 b0 04 e6 21 b0 02 FWIW, I get the same thing with 34a1cd60d17 reverted. Maybe there are two bugs, maybe there's more to this first one. I can repro this So if my understanding is correct, this is probably another bug. And especially, I already saw the same log in another thread, Cleaning up the KVM clock. Maybe you can continue to `git bisect` to locate that bad commit. Thanks Tiejun error with the command: qemu-system-x86_64 -machine pc,accel=kvm -nodefaults This is with QEMU emulator version 2.1.2 (Debian 1:2.1+dfsg-11), Copyright (c) 2003-2008 Fabrice Bellard The host system is: cpu family : 6 model : 23 model name : Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz stepping: 10 microcode : 0xa0b ... flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm dtherm tpr_shadow vnmi flexpriority I bisected this back to: commit 34a1cd60d17f62c1f077c1478a6c2ca8c3d17af4 Author: Tiejun Chen tiejun.c...@intel.com Date: Tue Oct 28 10:14:48 2014 +0800 kvm: x86: vmx: move some vmx setting from vmx_init() to hardware_setup() Instead of vmx_init(), actually it would make reasonable sense
Re: regression bisected; KVM: entry failed, hardware error 0x80000021
On 2014/12/23 9:50, Chen, Tiejun wrote: On 2014/12/22 17:23, Jamie Heilman wrote: Chen, Tiejun wrote: On 2014/12/21 20:46, Jamie Heilman wrote: With v3.19-rc1 when I run qemu-system-x86_64 -machine pc,accel=kvm I get: KVM: entry failed, hardware error 0x8021 Looks some MSR writing issues such a failed entry. 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= EBX= ECX= EDX=0663 ESI= EDI= EBP= ESP= EIP=e05b EFL=00010002 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES = 9300 CS =f000 000f 9b00 SS = 9300 DS = 9300 FS = 9300 GS = 9300 LDT= 8200 TR = 8b00 GDT= IDT= CR0=6010 CR2= CR3= CR4= DR0= DR1= DR2= DR3= DR6=0ff0 DR7=0400 EFER= And I don't see any obvious wrong as well. Any valuable info from dmesg? With the simple qemu command above, on 3.18.1 I see: kern.info: kvm: zapping shadow pages for mmio generation wraparound when I fire up a full guest that's actually useful I get: kern.info: kvm: zapping shadow pages for mmio generation wraparound kern.err: kvm [4073]: vcpu0 disabled perfctr wrmsr: 0xc1 data 0x On 3.18.0-rc3-00042-g34a1cd6 nothing appears in the dmesg, just the message I mention above to stderr. Same thing with a stock 3.19.0-rc1. Once I apply your patch the simple test command produces the same zapping shadow pages messages as 3.18.1, and a test guest of a Debian Jessie image (w/stock distro kernel) produces the same thing with disabled perfctr wrmsr message. However, it doesn't look like Sorry I'm not sure if I understood current status. Looks 3.19-rc1 my patch just fix that error above, KVM: entry failed, hardware error 0x8021 ... Right? I'm entirely out of the woods, because one of my other guest VMs with a custom kernel that works great under 3.18.1 now fails to run. Nothing in dmesg, but here's the stderr: But even you revert 34a1cd60d17 or just apply my patch, something else introduced between 3.18.1 and 3.19-rc1 led this error below, right? KVM internal error. Suberror: 1 emulation failure EAX=000de494 EBX= ECX= EDX=0cfd ESI=0059 EDI= EBP= ESP=6fb4 EIP=000f15c1 EFL=00010016 [AP-] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0010 00c09300 DPL=0 DS [-WA] CS =0008 00c09b00 DPL=0 CS32 [-RA] SS =0010 00c09300 DPL=0 DS [-WA] DS =0010 00c09300 DPL=0 DS [-WA] FS =0010 00c09300 DPL=0 DS [-WA] GS =0010 00c09300 DPL=0 DS [-WA] LDT= 8200 DPL=0 LDT TR = 8b00 DPL=0 TSS32-busy GDT= 000f6be8 0037 IDT= 000f6c26 CR0=6011 CR2= CR3= CR4= DR0= DR1= DR2= DR3= DR6=0ff0 DR7=0400 EFER= Code=e8 ae fc ff ff 89 f2 a8 10 89 d8 75 0a b9 41 15 ff ff ff d1 5b 5e c3 5b 5e e9 76 ff ff ff b0 11 e6 20 e6 a0 b0 08 e6 21 b0 70 e6 a1 b0 04 e6 21 b0 02 FWIW, I get the same thing with 34a1cd60d17 reverted. Maybe there are two bugs, maybe there's more to this first one. I can repro this So if my understanding is correct, this is probably another bug. And especially, I already saw the same log in another thread, Cleaning up the KVM clock. Maybe you can continue to `git bisect` to locate that bad commit. Looks just now Andy found that commit, 0e60b0799fedc495a5c57dbd669de3c10d72edd2 kvm: change memslot sorting rule from size to GFN, maybe you can try to revert this to try yours again. Thanks Tiejun -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: regression bisected; KVM: entry failed, hardware error 0x80000021
Chen, Tiejun wrote: On 2014/12/23 9:50, Chen, Tiejun wrote: On 2014/12/22 17:23, Jamie Heilman wrote: Chen, Tiejun wrote: On 2014/12/21 20:46, Jamie Heilman wrote: With v3.19-rc1 when I run qemu-system-x86_64 -machine pc,accel=kvm I get: KVM: entry failed, hardware error 0x8021 Looks some MSR writing issues such a failed entry. 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= EBX= ECX= EDX=0663 ESI= EDI= EBP= ESP= EIP=e05b EFL=00010002 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES = 9300 CS =f000 000f 9b00 SS = 9300 DS = 9300 FS = 9300 GS = 9300 LDT= 8200 TR = 8b00 GDT= IDT= CR0=6010 CR2= CR3= CR4= DR0= DR1= DR2= DR3= DR6=0ff0 DR7=0400 EFER= And I don't see any obvious wrong as well. Any valuable info from dmesg? With the simple qemu command above, on 3.18.1 I see: kern.info: kvm: zapping shadow pages for mmio generation wraparound when I fire up a full guest that's actually useful I get: kern.info: kvm: zapping shadow pages for mmio generation wraparound kern.err: kvm [4073]: vcpu0 disabled perfctr wrmsr: 0xc1 data 0x On 3.18.0-rc3-00042-g34a1cd6 nothing appears in the dmesg, just the message I mention above to stderr. Same thing with a stock 3.19.0-rc1. Once I apply your patch the simple test command produces the same zapping shadow pages messages as 3.18.1, and a test guest of a Debian Jessie image (w/stock distro kernel) produces the same thing with disabled perfctr wrmsr message. However, it doesn't look like Sorry I'm not sure if I understood current status. Looks 3.19-rc1 my patch just fix that error above, KVM: entry failed, hardware error 0x8021 ... Right? I'm entirely out of the woods, because one of my other guest VMs with a custom kernel that works great under 3.18.1 now fails to run. Nothing in dmesg, but here's the stderr: But even you revert 34a1cd60d17 or just apply my patch, something else introduced between 3.18.1 and 3.19-rc1 led this error below, right? KVM internal error. Suberror: 1 emulation failure EAX=000de494 EBX= ECX= EDX=0cfd ESI=0059 EDI= EBP= ESP=6fb4 EIP=000f15c1 EFL=00010016 [AP-] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0010 00c09300 DPL=0 DS [-WA] CS =0008 00c09b00 DPL=0 CS32 [-RA] SS =0010 00c09300 DPL=0 DS [-WA] DS =0010 00c09300 DPL=0 DS [-WA] FS =0010 00c09300 DPL=0 DS [-WA] GS =0010 00c09300 DPL=0 DS [-WA] LDT= 8200 DPL=0 LDT TR = 8b00 DPL=0 TSS32-busy GDT= 000f6be8 0037 IDT= 000f6c26 CR0=6011 CR2= CR3= CR4= DR0= DR1= DR2= DR3= DR6=0ff0 DR7=0400 EFER= Code=e8 ae fc ff ff 89 f2 a8 10 89 d8 75 0a b9 41 15 ff ff ff d1 5b 5e c3 5b 5e e9 76 ff ff ff b0 11 e6 20 e6 a0 b0 08 e6 21 b0 70 e6 a1 b0 04 e6 21 b0 02 FWIW, I get the same thing with 34a1cd60d17 reverted. Maybe there are two bugs, maybe there's more to this first one. I can repro this So if my understanding is correct, this is probably another bug. And especially, I already saw the same log in another thread, Cleaning up the KVM clock. Maybe you can continue to `git bisect` to locate that bad commit. Looks just now Andy found that commit, 0e60b0799fedc495a5c57dbd669de3c10d72edd2 kvm: change memslot sorting rule from size to GFN, maybe you can try to revert this to try yours again. That doesn't revert cleanly for me, and I don't have much time to fiddle with it until the 24th---so checked out the commit before it (d4ae84a0), applied your patch, built, and yes, everything works fine at that point. I'll probably have time for another full bisection later, assuming things aren't ironed out already by then. -- Jamie Heilman http://audible.transient.net/~jamie/ -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: regression bisected; KVM: entry failed, hardware error 0x80000021
On 2014/12/23 15:26, Jamie Heilman wrote: Chen, Tiejun wrote: On 2014/12/23 9:50, Chen, Tiejun wrote: On 2014/12/22 17:23, Jamie Heilman wrote: Chen, Tiejun wrote: On 2014/12/21 20:46, Jamie Heilman wrote: With v3.19-rc1 when I run qemu-system-x86_64 -machine pc,accel=kvm I get: KVM: entry failed, hardware error 0x8021 Looks some MSR writing issues such a failed entry. 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= EBX= ECX= EDX=0663 ESI= EDI= EBP= ESP= EIP=e05b EFL=00010002 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES = 9300 CS =f000 000f 9b00 SS = 9300 DS = 9300 FS = 9300 GS = 9300 LDT= 8200 TR = 8b00 GDT= IDT= CR0=6010 CR2= CR3= CR4= DR0= DR1= DR2= DR3= DR6=0ff0 DR7=0400 EFER= And I don't see any obvious wrong as well. Any valuable info from dmesg? With the simple qemu command above, on 3.18.1 I see: kern.info: kvm: zapping shadow pages for mmio generation wraparound when I fire up a full guest that's actually useful I get: kern.info: kvm: zapping shadow pages for mmio generation wraparound kern.err: kvm [4073]: vcpu0 disabled perfctr wrmsr: 0xc1 data 0x On 3.18.0-rc3-00042-g34a1cd6 nothing appears in the dmesg, just the message I mention above to stderr. Same thing with a stock 3.19.0-rc1. Once I apply your patch the simple test command produces the same zapping shadow pages messages as 3.18.1, and a test guest of a Debian Jessie image (w/stock distro kernel) produces the same thing with disabled perfctr wrmsr message. However, it doesn't look like Sorry I'm not sure if I understood current status. Looks 3.19-rc1 my patch just fix that error above, KVM: entry failed, hardware error 0x8021 ... Right? I'm entirely out of the woods, because one of my other guest VMs with a custom kernel that works great under 3.18.1 now fails to run. Nothing in dmesg, but here's the stderr: But even you revert 34a1cd60d17 or just apply my patch, something else introduced between 3.18.1 and 3.19-rc1 led this error below, right? KVM internal error. Suberror: 1 emulation failure EAX=000de494 EBX= ECX= EDX=0cfd ESI=0059 EDI= EBP= ESP=6fb4 EIP=000f15c1 EFL=00010016 [AP-] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0010 00c09300 DPL=0 DS [-WA] CS =0008 00c09b00 DPL=0 CS32 [-RA] SS =0010 00c09300 DPL=0 DS [-WA] DS =0010 00c09300 DPL=0 DS [-WA] FS =0010 00c09300 DPL=0 DS [-WA] GS =0010 00c09300 DPL=0 DS [-WA] LDT= 8200 DPL=0 LDT TR = 8b00 DPL=0 TSS32-busy GDT= 000f6be8 0037 IDT= 000f6c26 CR0=6011 CR2= CR3= CR4= DR0= DR1= DR2= DR3= DR6=0ff0 DR7=0400 EFER= Code=e8 ae fc ff ff 89 f2 a8 10 89 d8 75 0a b9 41 15 ff ff ff d1 5b 5e c3 5b 5e e9 76 ff ff ff b0 11 e6 20 e6 a0 b0 08 e6 21 b0 70 e6 a1 b0 04 e6 21 b0 02 FWIW, I get the same thing with 34a1cd60d17 reverted. Maybe there are two bugs, maybe there's more to this first one. I can repro this So if my understanding is correct, this is probably another bug. And especially, I already saw the same log in another thread, Cleaning up the KVM clock. Maybe you can continue to `git bisect` to locate that bad commit. Looks just now Andy found that commit, 0e60b0799fedc495a5c57dbd669de3c10d72edd2 kvm: change memslot sorting rule from size to GFN, maybe you can try to revert this to try yours again. That doesn't revert cleanly for me, and I don't have much time to Yeah, I guess all associated commits should be reverted gradually. fiddle with it until the 24th---so checked out the commit before it (d4ae84a0), applied your patch, built, and yes, everything works fine Thanks for your test. I think I can submit this patch to fix one of yours problems and I'd like to add you as Reported-by Tested-by. Then we can step into another issue. And I'm trying to fetch 3.19-rc1 (because I'm always working on kvm/next.) to take a look at that but maybe Paolo is already going on that. Tiejun at that point. I'll probably have time for another full bisection later, assuming things aren't ironed out already
regression bisected; KVM: entry failed, hardware error 0x80000021
With v3.19-rc1 when I run qemu-system-x86_64 -machine pc,accel=kvm I get: KVM: entry failed, hardware error 0x8021 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= EBX= ECX= EDX=0663 ESI= EDI= EBP= ESP= EIP=e05b EFL=00010002 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES = 9300 CS =f000 000f 9b00 SS = 9300 DS = 9300 FS = 9300 GS = 9300 LDT= 8200 TR = 8b00 GDT= IDT= CR0=6010 CR2= CR3= CR4= DR0= DR1= DR2= DR3= DR6=0ff0 DR7=0400 EFER= Code=85 00 87 00 89 00 8b 00 00 00 86 00 88 00 8a 00 8c 00 00 90 2e 66 83 3e 30 6c 00 0f 85 e7 f2 31 c0 8e d0 66 bc 00 70 00 00 66 ba 31 2e 0f 00 e9 45 f1 This is with QEMU emulator version 2.1.2 (Debian 1:2.1+dfsg-11), Copyright (c) 2003-2008 Fabrice Bellard The host system is: cpu family : 6 model : 23 model name : Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz stepping: 10 microcode : 0xa0b ... flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm dtherm tpr_shadow vnmi flexpriority I bisected this back to: commit 34a1cd60d17f62c1f077c1478a6c2ca8c3d17af4 Author: Tiejun Chen tiejun.c...@intel.com Date: Tue Oct 28 10:14:48 2014 +0800 kvm: x86: vmx: move some vmx setting from vmx_init() to hardware_setup() Instead of vmx_init(), actually it would make reasonable sense to do anything specific to vmx hardware setting in vmx_x86_ops-hardware_setup(). Signed-off-by: Tiejun Chen tiejun.c...@intel.com Signed-off-by: Paolo Bonzini pbonz...@redhat.com reverting this commit appears to fix the issue, in so far that I can run kvm again without the aforementioned error, but I haven't tested it thoroughly beyond that. Let me know if you need more information or testing. -- Jamie Heilman http://audible.transient.net/~jamie/ -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: regression bisected; KVM: entry failed, hardware error 0x80000021
On 2014/12/21 20:46, Jamie Heilman wrote:
With v3.19-rc1 when I run qemu-system-x86_64 -machine pc,accel=kvm I
get:
KVM: entry failed, hardware error 0x8021
Looks some MSR writing issues such a failed entry.
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= EBX= ECX= EDX=0663
ESI= EDI= EBP= ESP=
EIP=e05b EFL=00010002 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES = 9300
CS =f000 000f 9b00
SS = 9300
DS = 9300
FS = 9300
GS = 9300
LDT= 8200
TR = 8b00
GDT=
IDT=
CR0=6010 CR2= CR3= CR4=
DR0= DR1= DR2=
DR3=
DR6=0ff0 DR7=0400
EFER=
And I don't see any obvious wrong as well. Any valuable info from dmesg?
Code=85 00 87 00 89 00 8b 00 00 00 86 00 88 00 8a 00 8c 00 00 90 2e 66 83 3e
30 6c 00 0f 85 e7 f2 31 c0 8e d0 66 bc 00 70 00 00 66 ba 31 2e 0f 00 e9 45 f1
This is with QEMU emulator version 2.1.2 (Debian 1:2.1+dfsg-11),
Copyright (c) 2003-2008 Fabrice Bellard
The host system is:
cpu family : 6
model : 23
model name : Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz
stepping: 10
microcode : 0xa0b
...
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm
constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf pni dtes64 monitor
ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm dtherm
tpr_shadow vnmi flexpriority
I bisected this back to:
commit 34a1cd60d17f62c1f077c1478a6c2ca8c3d17af4
Author: Tiejun Chen tiejun.c...@intel.com
Date: Tue Oct 28 10:14:48 2014 +0800
kvm: x86: vmx: move some vmx setting from vmx_init() to hardware_setup()
Instead of vmx_init(), actually it would make reasonable sense to do
anything specific to vmx hardware setting in vmx_x86_ops-hardware_setup().
This commit just reorders something but some MSR writing depend on
previous status.
Could you try this?
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index feb852b..96c84a8 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -5840,49 +5840,6 @@ static __init int hardware_setup(void)
memset(vmx_msr_bitmap_legacy, 0xff, PAGE_SIZE);
memset(vmx_msr_bitmap_longmode, 0xff, PAGE_SIZE);
- vmx_disable_intercept_for_msr(MSR_FS_BASE, false);
- vmx_disable_intercept_for_msr(MSR_GS_BASE, false);
- vmx_disable_intercept_for_msr(MSR_KERNEL_GS_BASE, true);
- vmx_disable_intercept_for_msr(MSR_IA32_SYSENTER_CS, false);
- vmx_disable_intercept_for_msr(MSR_IA32_SYSENTER_ESP, false);
- vmx_disable_intercept_for_msr(MSR_IA32_SYSENTER_EIP, false);
- vmx_disable_intercept_for_msr(MSR_IA32_BNDCFGS, true);
-
- memcpy(vmx_msr_bitmap_legacy_x2apic,
- vmx_msr_bitmap_legacy, PAGE_SIZE);
- memcpy(vmx_msr_bitmap_longmode_x2apic,
- vmx_msr_bitmap_longmode, PAGE_SIZE);
-
- if (enable_apicv) {
- for (msr = 0x800; msr = 0x8ff; msr++)
- vmx_disable_intercept_msr_read_x2apic(msr);
-
- /* According SDM, in x2apic mode, the whole id reg is used.
-* But in KVM, it only use the highest eight bits. Need to
-* intercept it */
- vmx_enable_intercept_msr_read_x2apic(0x802);
- /* TMCCT */
- vmx_enable_intercept_msr_read_x2apic(0x839);
- /* TPR */
- vmx_disable_intercept_msr_write_x2apic(0x808);
- /* EOI */
- vmx_disable_intercept_msr_write_x2apic(0x80b);
- /* SELF-IPI */
- vmx_disable_intercept_msr_write_x2apic(0x83f);
- }
-
- if (enable_ept) {
- kvm_mmu_set_mask_ptes(0ull,
- (enable_ept_ad_bits) ? VMX_EPT_ACCESS_BIT : 0ull,
- (enable_ept_ad_bits) ? VMX_EPT_DIRTY_BIT : 0ull,
- 0ull, VMX_EPT_EXECUTABLE_MASK);
- ept_set_mmio_spte_mask();
- kvm_enable_tdp();
- } else
- kvm_disable_tdp();
-
- update_ple_window_actual_max();
-
if (setup_vmcs_config(vmcs_config) 0) {
r = -EIO;
goto out7;
@@ -5945,6 +5902,49 @@ static __init int hardware_setup(void)
if (nested)
nested_vmx_setup_ctls_msrs
With '-cpu host' in L1 nested guest fails: KVM: entry failed, hardware error 0x7
Hi, This error occurs when using using '-cpu host'. And, is consistently reproducible with Fedora 21's Kernels. One way to reproduce the issue -- a) Enable nested virt on host, I use this procedure[1] b) Boot a a guest (ensure /dev/kvm character device shows up) c) Invoke `libguestfs-test-tool` utility in L1 (which will run a QEMU appliance with -cpu host). You should see the failure in this log: ~/.cache/libvirt/qemu/log/guestfs-vegb4aor6a8d1r3e.log QEMU CLI: [. . .] 2014-11-26 12:16:02.449+: starting up LC_ALL=C PATH=/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/home/kashyapc/.local/bin:/home/kashyapc/bin:/usr/local/sbin:/usr/sbin:/sbin HOME=/home/kashyapc USER=kashyapc LOGNAME=kashyapc QEMU_AUDIO_DRV=none TMPDIR=/var/tmp /bin/qemu-kvm -name guestfs-vegb4aor6a8d1r3e -S -machine pc-i440fx-2.1,accel=kvm,usb=off -cpu host -m 500 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 27869b93-0b83-4b57-a909-9265c677d307 -nographic -no-user-config -nodefaults -device sga -chardev socket,id=charmonitor,path=/home/kashyapc/.config/libvirt/qemu/lib/guestfs-vegb4aor6a8d1r3e.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-reboot -no-acpi -boot strict=on -kernel /var/tmp/.guestfs-1000/appliance.d/kernel -initrd /var/tmp/.guestfs-1000/appliance.d/initrd -append panic=1 console=ttyS0 udevtimeout=6000 udev.event-timeout=6000 no_timer_check acpi=off printk.time=1 cgroup_disable=memory root=/dev/sdb selinux=0 TERM=screen -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x3 -drive file=/tmp/libguestfsenp1an/devnull1,if=none,id=drive-scsi0-0-0-0,format=raw,cache=writeback -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 -drive file=/tmp/libguestfsenp1an/overlay2,if=none,id=drive-scsi0-0-1-0,format=qcow2,cache=unsafe -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=1,lun=0,drive=drive-scsi0-0-1-0,id=scsi0-0-1-0 -chardev socket,id=charserial0,path=/tmp/libguestfsenp1an/console.sock -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charchannel0,path=/tmp/libguestfsenp1an/guestfsd.sock -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.libguestfs.channel.0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 -msg timestamp=on Domain id=2 is tainted: custom-argv Domain id=2 is tainted: host-cpu KVM: entry failed, hardware error 0x7 RAX=000f RBX= RCX=038f RDX= RSI=000f RDI=038f RBP=88001ee4faa0 RSP=88001ee4faa0 R8 = R9 =88001f00cf60 R10=88001ee4fa48 R11=0005 R12=038f R13=81809390 R14= R15=88001f00ca40 RIP=8105b8ca RFL=0046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES = 00c0 CS =0010 00a09b00 DPL=0 CS64 [-RA] SS = 00c0 DS = 00c0 FS = 00c0 GS = 88001f00 00c0 LDT= 00c0 TR =0040 88001f012080 2087 8b00 DPL=0 TSS64-busy GDT= 88001f00a000 007f IDT= ff56b000 0fff CR0=8005003b CR2= CR3=01c11000 CR4=07f0 DR0= DR1= DR2= DR3= DR6=0ff0 DR7=0400 EFER=0d01 Code=20 48 89 f8 48 09 f0 5d c3 90 55 89 f0 89 f9 48 89 e5 0f 30 31 c0 5d c3 66 90 55 89 f9 48 89 e5 0f 33 48 89 d7 89 c1 48 c1 e7 20 48 89 f8 48 09 c8 5d [. . .] I'll admit, with Fedora Rawhide Kernel, libvirt and QEMU versions I could not reproduce the issue: $ uname -r; rpm -q qemu-system-x86 libvirt-daemon-kvm 3.18.0-0.rc6.git0.1.fc22.x86_64 qemu-system-x86-2.2.0-0.1.rc1.fc22.x86_64 libvirt-daemon-kvm-1.2.10-3.fc22.x86_64 There's an existing bug for Fedora, here[2] [1] https://kashyapc.fedorapeople.org/virt/procedure-to-enable-nested-virt-on-intel-machines.txt [2] https://bugzilla.redhat.com/show_bug.cgi?id=1016748#c9 -- KVM: entry failed, hardware error 0x7 for nested kvm guest -- /kashyap -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM entry failed, hardware error
On 06/12/2012 01:23 PM, Johannes Bauer wrote: On 10.06.2012 17:19, Avi Kivity wrote: Looks like we weren't dealing with interrupts correctly. I pushed some patches, please pull again and retry. Updated to cf3d9372065470403e0780599ca612553211a10b and it works perfectly for me! Good to hear. We'll try to get emulate_invalid_guest_state=1 to be the default for 3.6. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM entry failed, hardware error
On 06/07/2012 10:14 PM, Johannes Bauer wrote: On 07.06.2012 19:25, Avi Kivity wrote: Note that c does NOT cause the VM to resume, only info registers does. dmesg shows nothing out of the ordinary. I'm guessing this is 5152902652. Try bumping 'unsigned count = 130' (by adding zeros at the end, don't bother with anything less). If you increase it too much qemu may hang; but kill -9 should unfreeze it. Doesn't seem to be right -- still got the same problem. I first bumped it up to 1300 and inserted debugging output to see how many cycles are actually spent in the loop. It enters the emulation mode so frequently (and leaves it again) that the dmesg buffer ran over (128kB). So I changed the debugging to give me the lowest cycle count that it ever has after the loop: handle_invalid_guest_state: emulation left, new low count 1295 handle_invalid_guest_state: emulation left, new low count 1292 handle_invalid_guest_state: emulation left, new low count 1291 handle_invalid_guest_state: emulation left, new low count 1245 Which means that it spends a maximum of 55 cycles in the loop (well below the original 130 even). So my change had no effect. Any other ideas maybe? Looks like we weren't dealing with interrupts correctly. I pushed some patches, please pull again and retry. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM entry failed, hardware error
On 06/06/2012 09:07 PM, Johannes Bauer wrote: On 06.06.2012 17:53, Avi Kivity wrote: # rmmod kvm_intel # modprobe kvm_intel emulate_invalid_guest_state=1 Warning: experimental code. Tried it out -- I don't get the error anymore, but qemu just hangs on boot with 100% CPU. :-( Please retry with git://git.kernel.org/pub/scm/virt/kvm/kvm.git big-real-mode Same thing: $ uname -a Linux joequad 3.5.0-rc1-46053-gf2ebd42 #1 SMP PREEMPT Wed Jun 6 19:49:21 CEST 2012 x86_64 Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz GenuineIntel GNU/Linux $ cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-3.5.0-rc1-46053-gf2ebd42 root=/dev/sda1 ro kvm-intel.emulate_invalid_guest_state=1 QEmu hangs with 100% CPU. Is there anything I can try to be able to tell you *where* it hangs? add -monitor stdio to the command line and then: (qemu) info registers (qemu) x/20i 0xcsbase + $eip (for csbase substitute the second value for CS in 'info registers') Run info registers a few times and note whether eip changes or not. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM entry failed, hardware error
On 07.06.2012 09:12, Avi Kivity wrote: add -monitor stdio to the command line and then: (qemu) info registers (qemu) x/20i 0xcsbase + $eip Run info registers a few times and note whether eip changes or not. It does not. Here's where it hangs: (qemu) info registers EAX=23de EBX=0b70 ECX=0b90 EDX=0002 ESI=002523de EDI=0b84 EBP=146e ESP=146e EIP=08d7 EFL=0202 [---] CPL=3 II=0 A20=1 SMM=0 HLT=0 ES =23de 00023de0 f300 CS =2000 0002 f300 SS =23de 00023de0 f300 DS =23de 00023de0 f300 FS =0060 00023de0 9300 GS =0060 00023de0 9300 LDT= 00c0 TR =0040 feffd000 2088 8b00 GDT= 0001f000 007f IDT= CR0=0010 CR2= CR3= CR4= DR0= DR1= DR2= DR3= DR6=0ff0 DR7=0400 EFER= FCW=037f FSW= [ST=0] FTW=00 MXCSR=1f80 FPR0= FPR1= FPR2= FPR3= FPR4= FPR5= FPR6= FPR7= XMM00= XMM01= XMM02= XMM03= XMM04= XMM05= XMM06= XMM07= (qemu) x/20i 0x2 + $eip 0x000208d7: leave 0x000208d8: ret 0x000208d9: enter $0x0,$0x0 0x000208dd: push %ebp 0x000208df: push %ebx 0x000208e1: push %esi 0x000208e3: push %edi 0x000208e5: mov%esp,%ebx 0x000208e8: mov%ebx,%edi 0x000208eb: add$0x14,%edi 0x000208ef: addr32 mov (%edi),%eax 0x000208f3: mov$0x1480,%sp 0x000208f6: xor%bp,%bp 0x000208f8: movzwl %bp,%ebp 0x000208fc: movzwl %sp,%esp 0x00020900: push %ebx 0x00020902: push %eax 0x00020904: call 0x20919 0x00020907: add$0x4,%sp 0x0002090a: pop%ebx And this is where it came from and tries to return to: (qemu) x /8hx 0x23de0 + $esp 0002524e: 0x1474 0x092a 0x0001 0x 0x0907 0x4970 0x0002 0x0b70 (qemu) x/20i 0x2 + 0x92a - 0x15 0x00020915: pop%ebp 0x00020917: leave 0x00020918: ret 0x00020919: enter $0x0,$0x0 0x0002091d: mov0x1510,%ax 0x00020920: push %ax 0x00020921: and%ax,%ax 0x00020923: je 0x2092a 0x00020927: call 0x20871 0x0002092a: push %bx 0x0002092b: push %di 0x0002092c: push %si 0x0002092d: push %ds 0x0002092e: push %es 0x0002092f: push %bp 0x00020930: mov0x4(%bp),%eax 0x00020934: mov%ax,%bp 0x00020936: and$0xf,%bp 0x00020939: shr$0x4,%eax 0x0002093d: mov%ax,%ds Here's the whole function that causes the hangup: (qemu) x/39i 0x2 + 0x871 0x00020871: enter $0x0,$0x0 0x00020875: push %ebx 0x00020877: mov0x1510,%ax 0x0002087a: and%ax,%ax 0x0002087c: je 0x208d5 0x00020880: sgdtw 0x1500 0x00020885: sidtw 0x1508 0x0002088a: movw $0x0,0x1510 0x00020890: mov%cr0,%eax 0x00020893: mov%eax,0x1514 0x00020897: and$0x7ffe,%eax 0x0002089d: mov%eax,%cr0 0x000208a0: jmp0x208a5 0x000208a2: nop 0x000208a3: nop 0x000208a4: nop 0x000208a5: mov%cr3,%eax 0x000208a8: nop 0x000208a9: nop 0x000208aa: nop 0x000208ab: nop 0x000208ac: mov%eax,%cr3 0x000208af: pushw 0x1536 0x000208b3: pop%es 0x000208b4: mov$0x8c6,%bx 0x000208b7: mov0x1536,%ax 0x000208ba: mov%ax,%es:-0x2(%bx) 0x000208be: ljmp *%es:-0x4(%bx) 0x000208c2: (bad) 0x000208c3: or %al,(%bx,%si) 0x000208c5: and%ah,0x1534(%bx,%di) 0x000208c9: mov%ax,%ds 0x000208cb: mov%ax,%ss 0x000208cd: mov%ax,%es 0x000208cf: lidtw 0x14f8 0x000208d4: sti 0x000208d5: pop%ebx 0x000208d7: leave 0x000208d8: ret Best regards, Joe -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM entry failed, hardware error
On 06/07/2012 01:03 PM, Johannes Bauer wrote: On 07.06.2012 09:12, Avi Kivity wrote: add -monitor stdio to the command line and then: (qemu) info registers (qemu) x/20i 0xcsbase + $eip Run info registers a few times and note whether eip changes or not. It does not. Here's where it hangs: (qemu) x/20i 0x2 + $eip 0x000208d7: leave Pretty straightforward, we need to emulate the leave instruction. I'll update the branch and notify you. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM entry failed, hardware error
On 06/07/2012 01:54 PM, Avi Kivity wrote: On 06/07/2012 01:03 PM, Johannes Bauer wrote: On 07.06.2012 09:12, Avi Kivity wrote: add -monitor stdio to the command line and then: (qemu) info registers (qemu) x/20i 0xcsbase + $eip Run info registers a few times and note whether eip changes or not. It does not. Here's where it hangs: (qemu) x/20i 0x2 + $eip 0x000208d7: leave Pretty straightforward, we need to emulate the leave instruction. I'll update the branch and notify you. Please try the big-real-mode branch again. It contains emulation for the missing instruction, plus a bunch of tweaks which allowed it to boot Fedora 17 smp with emulate_invalid_guest_state=1. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM entry failed, hardware error
On 07.06.2012 16:52, Avi Kivity wrote: Please try the big-real-mode branch again. It contains emulation for the missing instruction, plus a bunch of tweaks which allowed it to boot Fedora 17 smp with emulate_invalid_guest_state=1. Progress! So now I'm on Linux joequad 3.5.0-rc1-46078-g54d5c7c #2 SMP PREEMPT Thu Jun 7 17:11:38 CEST 2012 x86_64 Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz GenuineIntel GNU/Linux And see the following (kind of weird) behavior: I can boot up now. But it's bound to some condition: When not using -monitor stdio, I have the same behavior as before. When using -monitor stdio, it locks up occasionaly, but appears to resume operation whenever I type info registers. That way I was able to boot up (by entering about 50 times info registers, then it had left real mode and booted up normally). I was first a bit confused, but this is definitely what I'm seeing: Because of shutting down the VM I had put the guest in a Windows Recovery mode where a text-mode progress bar appears with the text Windows is loading files The bar locks up -- when I type info registers, it progresses about 2-4 characters and locks up again (until it's fully loaded, then it just works). Note that c does NOT cause the VM to resume, only info registers does. dmesg shows nothing out of the ordinary. But I think we're getting somewhere! Thank you very much for your support already! Best regards, Joe -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM entry failed, hardware error
On 06/07/2012 06:39 PM, Johannes Bauer wrote: On 07.06.2012 16:52, Avi Kivity wrote: Please try the big-real-mode branch again. It contains emulation for the missing instruction, plus a bunch of tweaks which allowed it to boot Fedora 17 smp with emulate_invalid_guest_state=1. Progress! Great! So now I'm on Linux joequad 3.5.0-rc1-46078-g54d5c7c #2 SMP PREEMPT Thu Jun 7 17:11:38 CEST 2012 x86_64 Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz GenuineIntel GNU/Linux And see the following (kind of weird) behavior: I can boot up now. But it's bound to some condition: When not using -monitor stdio, I have the same behavior as before. When using -monitor stdio, it locks up occasionaly, but appears to resume operation whenever I type info registers. That way I was able to boot up (by entering about 50 times info registers, then it had left real mode and booted up normally). I was first a bit confused, but this is definitely what I'm seeing: Because of shutting down the VM I had put the guest in a Windows Recovery mode where a text-mode progress bar appears with the text Windows is loading files The bar locks up -- when I type info registers, it progresses about 2-4 characters and locks up again (until it's fully loaded, then it just works). Note that c does NOT cause the VM to resume, only info registers does. dmesg shows nothing out of the ordinary. I'm guessing this is 5152902652. Try bumping 'unsigned count = 130' (by adding zeros at the end, don't bother with anything less). If you increase it too much qemu may hang; but kill -9 should unfreeze it. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM entry failed, hardware error
On 07.06.2012 19:25, Avi Kivity wrote: Note that c does NOT cause the VM to resume, only info registers does. dmesg shows nothing out of the ordinary. I'm guessing this is 5152902652. Try bumping 'unsigned count = 130' (by adding zeros at the end, don't bother with anything less). If you increase it too much qemu may hang; but kill -9 should unfreeze it. Doesn't seem to be right -- still got the same problem. I first bumped it up to 1300 and inserted debugging output to see how many cycles are actually spent in the loop. It enters the emulation mode so frequently (and leaves it again) that the dmesg buffer ran over (128kB). So I changed the debugging to give me the lowest cycle count that it ever has after the loop: handle_invalid_guest_state: emulation left, new low count 1295 handle_invalid_guest_state: emulation left, new low count 1292 handle_invalid_guest_state: emulation left, new low count 1291 handle_invalid_guest_state: emulation left, new low count 1245 Which means that it spends a maximum of 55 cycles in the loop (well below the original 130 even). So my change had no effect. Any other ideas maybe? Best regards, Joe -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM entry failed, hardware error
On 07.06.2012 19:25, Avi Kivity wrote: Note that c does NOT cause the VM to resume, only info registers does. dmesg shows nothing out of the ordinary. I'm guessing this is 5152902652. Try bumping 'unsigned count = 130' (by adding zeros at the end, don't bother with anything less). If you increase it too much qemu may hang; but kill -9 should unfreeze it. Okay, here's more clues. They're not exactly meaningful for me, but probably of interest to you. Besides the low count value after loop exit value, I've introduced two counters which both are incremented inside the loop. Also I've modified the loop to be one return only (i.e. ret = foobar; goto out instead of return). Then when I have a script which continuously echos info registers and pipe that output together with qemu, I get this startup: 2012-06-07 21:39:34 handle_invalid_guest_state: emulation left, new loop low count 1295, total of 5 emulated insns 2012-06-07 21:39:34 handle_invalid_guest_state: emulation left, new loop low count 1292, total of 13 emulated insns 2012-06-07 21:39:34 handle_invalid_guest_state: emulation left, 1293 iterations left, 15 emulated insn, loop low count 1292 2012-06-07 21:39:34 handle_invalid_guest_state: emulation left, new loop low count 1291, total of 131214 emulated insns 2012-06-07 21:39:34 handle_invalid_guest_state: emulation left, new loop low count 1245, total of 131269 emulated insns 2012-06-07 21:39:35 handle_invalid_guest_state: emulation left, 1299 iterations left, 25 emulated insn, loop low count 1245 2012-06-07 21:39:35 handle_invalid_guest_state: emulation left, 1245 iterations left, 300012 emulated insn, loop low count 1245 2012-06-07 21:39:35 handle_invalid_guest_state: emulation left, 1291 iterations left, 400013 emulated insn, loop low count 1245 2012-06-07 21:39:35 handle_invalid_guest_state: emulation left, 1245 iterations left, 500050 emulated insn, loop low count 1245 2012-06-07 21:39:35 handle_invalid_guest_state: emulation left, 1245 iterations left, 600059 emulated insn, loop low count 1245 2012-06-07 21:39:35 handle_invalid_guest_state: emulation left, 1299 iterations left, 700059 emulated insn, loop low count 1245 2012-06-07 21:39:35 handle_invalid_guest_state: emulation left, 1299 iterations left, 800059 emulated insn, loop low count 1245 2012-06-07 21:39:36 handle_invalid_guest_state: emulation left, 1299 iterations left, 900059 emulated insn, loop low count 1245 2012-06-07 21:39:36 handle_invalid_guest_state: emulation left, 1299 iterations left, 159 emulated insn, loop low count 1245 2012-06-07 21:39:36 handle_invalid_guest_state: emulation left, new loop low count 1228, total of 1030349 emulated insns 2012-06-07 21:39:36 handle_invalid_guest_state: emulation left, 1291 iterations left, 1100063 emulated insn, loop low count 1228 2012-06-07 21:39:36 handle_invalid_guest_state: emulation left, 1299 iterations left, 1200063 emulated insn, loop low count 1228 2012-06-07 21:39:36 handle_invalid_guest_state: emulation left, 1299 iterations left, 1300063 emulated insn, loop low count 1228 2012-06-07 21:39:36 handle_invalid_guest_state: emulation left, 1245 iterations left, 1400113 emulated insn, loop low count 1228 2012-06-07 21:39:37 handle_invalid_guest_state: emulation left, 1245 iterations left, 1500145 emulated insn, loop low count 1228 After which it has booted up and does not emulate anymore. Note the maximum time spent in the loop is 72 iterations. But when I just start up and do not issue ANY info registers, I get the following output: 2012-06-07 21:41:44 handle_invalid_guest_state: emulation left, new loop low count 1295, total of 5 emulated insns 2012-06-07 21:41:44 handle_invalid_guest_state: emulation left, new loop low count 1292, total of 13 emulated insns 2012-06-07 21:41:44 handle_invalid_guest_state: emulation left, 1293 iterations left, 14 emulated insn, loop low count 1292 2012-06-07 21:41:44 handle_invalid_guest_state: emulation left, new loop low count 1291, total of 131955 emulated insns 2012-06-07 21:41:44 handle_invalid_guest_state: emulation left, new loop low count 1245, total of 132010 emulated insns 2012-06-07 21:41:44 handle_invalid_guest_state: emulation left, 1299 iterations left, 24 emulated insn, loop low count 1245 2012-06-07 21:41:45 handle_invalid_guest_state: emulation left, 1299 iterations left, 34 emulated insn, loop low count 1245 2012-06-07 21:41:45 handle_invalid_guest_state: emulation left, 1299 iterations left, 44 emulated insn, loop low count 1245 2012-06-07 21:41:45 handle_invalid_guest_state: emulation left, 1299 iterations left, 54 emulated insn, loop low count 1245 2012-06-07 21:41:45 handle_invalid_guest_state: emulation left, 1299 iterations left, 64 emulated insn, loop low count 1245 2012-06-07 21:41:45 handle_invalid_guest_state: emulation left, 1299 iterations left, 74 emulated insn, loop low count 1245 2012-06-07 21:41:45 handle_invalid_guest_state: emulation left, 1299 iterations left,
Re: KVM entry failed, hardware error
On 07.06.2012 21:46, Johannes Bauer wrote: In an infinite loop. Which looks to be as if it is continuously exiting after just one iteration (count at leave is 1299). Maybe I'll fiddle some more and am able to provide some insight (probably you already know what's going on, but it won't hurt I guess). Followup on that: I've shorted the debug output (so it doesn't get wrapped in mail and can be more easily read) and I've enumerated all five possible exists from the loop: 1. intr_window_requested (kvm_get_rflags(vmx-vcpu) X86_EFLAGS_IF) 2. err == EMULATE_DO_MMIO 3. err != EMULATE_DONE 4. signal_pending(current) 5. while loop exit And added that to the loop. When it hangs, it always exists by #1: higs: new low cnt 1295, 5 emu insns higs: new low cnt 1292, 13 emu insns higs: left count=1293, 12 emu insns, llc=1292, rsn=5 higs: new low cnt 1291, 135348 emu insns higs: new low cnt 1245, 135403 emu insns higs: new low cnt 1228, 183120 emu insns higs: left count=1291, 27 emu insns, llc=1228, rsn=5 higs: left count=1299, 37 emu insns, llc=1228, rsn=1 higs: left count=1299, 47 emu insns, llc=1228, rsn=1 higs: left count=1299, 57 emu insns, llc=1228, rsn=1 higs: left count=1299, 67 emu insns, llc=1228, rsn=1 higs: left count=1299, 77 emu insns, llc=1228, rsn=1 higs: left count=1299, 87 emu insns, llc=1228, rsn=1 higs: left count=1299, 97 emu insns, llc=1228, rsn=1 higs: left count=1299, 107 emu insns, llc=1228, rsn=1 higs: left count=1299, 117 emu insns, llc=1228, rsn=1 higs: left count=1299, 127 emu insns, llc=1228, rsn=1 higs: left count=1299, 137 emu insns, llc=1228, rsn=1 higs: left count=1299, 147 emu insns, llc=1228, rsn=1 higs: left count=1299, 157 emu insns, llc=1228, rsn=1 higs: left count=1299, 167 emu insns, llc=1228, rsn=1 higs: left count=1299, 177 emu insns, llc=1228, rsn=1 higs: left count=1299, 187 emu insns, llc=1228, rsn=1 higs: left count=1299, 197 emu insns, llc=1228, rsn=1 higs: left count=1299, 207 emu insns, llc=1228, rsn=1 higs: left count=1299, 217 emu insns, llc=1228, rsn=1 [...] If there's any more output I can provide to help you track down the problem at hand, please let me know. Best regards, Joe -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM entry failed, hardware error
On 06/03/2012 04:01 PM, Johannes Bauer wrote: # rmmod kvm_intel # modprobe kvm_intel emulate_invalid_guest_state=1 Warning: experimental code. Tried it out -- I don't get the error anymore, but qemu just hangs on boot with 100% CPU. :-( Please retry with git://git.kernel.org/pub/scm/virt/kvm/kvm.git big-real-mode -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM entry failed, hardware error
On 06.06.2012 17:53, Avi Kivity wrote: # rmmod kvm_intel # modprobe kvm_intel emulate_invalid_guest_state=1 Warning: experimental code. Tried it out -- I don't get the error anymore, but qemu just hangs on boot with 100% CPU. :-( Please retry with git://git.kernel.org/pub/scm/virt/kvm/kvm.git big-real-mode Same thing: $ uname -a Linux joequad 3.5.0-rc1-46053-gf2ebd42 #1 SMP PREEMPT Wed Jun 6 19:49:21 CEST 2012 x86_64 Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz GenuineIntel GNU/Linux $ cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-3.5.0-rc1-46053-gf2ebd42 root=/dev/sda1 ro kvm-intel.emulate_invalid_guest_state=1 QEmu hangs with 100% CPU. Is there anything I can try to be able to tell you *where* it hangs? Best regards, Johannes -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM entry failed, hardware error
On 05.06.2012 15:59, David Ahern wrote: You need to install the plugins for trace-cmd: make install_plugins you could also try setting: export TRACE_CMD_PLUGIN_DIR=/path/to/plugins Aha, with that I get more messages: trace-cmd: No such file or directory cound not load plugin '/home/joe/qEmu/trace/trace-cmd/plugin_kvm.so' /home/joe/qemu/trace/trace-cmd/plugin_kvm.so: undefined symbol: ud_translate_att However, during the build process, udis86 is linked in like it should be: [...] gcc -g -Wall -I. '-DPLUGIN_DIR=/usr/local/share/trace-cmd/plugins' -DHAVE_UDIS86 -ludis86 -DHAVE_BLK_TC_FLUSH -shared -nostartfiles -o plugin_blk.so plugin_blk.o But when looking, I just noticed that it does not appear in the imports $ ldd plugin_kvm.so linux-vdso.so.1 = (0x7fff3cfff000) libc.so.6 = /lib64/libc.so.6 (0x7f6429e1c000) /lib64/ld-linux-x86-64.so.2 (0x7f642a3e4000) Nor do I actually *have* the .so of udis86 in my /usr/lib directory. Gentoo by default just built the static library. Weird! I'll recompile myself and then it'll work for sure. Best regards, Joe -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM entry failed, hardware error
On 6/4/12 12:28 PM, Johannes Bauer wrote:
On 04.06.2012 10:53, Gleb Natapov wrote:
On Sun, Jun 03, 2012 at 06:25:33PM +0200, Johannes Bauer wrote:
Therefore, I've uploaded the compressed trace.dat file, so you can maybe
have a look why the report tool barfs and interpret it correctly. I
can't figure it out. The trace is here:
http://spornkuller.de/trace.dat.bz2
I can read this trace.
Hm, weird. But good that it works on your side. I get a lot of:
trace-cmd: No such file or directory
bad op token {
failed to read event print fmt for kvm_emulate_insn
version = 6
CPU 0 is empty
You need to install the plugins for trace-cmd:
make install_plugins
you could also try setting:
export TRACE_CMD_PLUGIN_DIR=/path/to/plugins
David
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM entry failed, hardware error
On Sun, Jun 03, 2012 at 06:25:33PM +0200, Johannes Bauer wrote: Therefore, I've uploaded the compressed trace.dat file, so you can maybe have a look why the report tool barfs and interpret it correctly. I can't figure it out. The trace is here: http://spornkuller.de/trace.dat.bz2 I can read this trace. Can you do info pci in qemu's monitor after failure? What is your command line? -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM entry failed, hardware error
On 06/04/2012 11:53 AM, Gleb Natapov wrote: On Sun, Jun 03, 2012 at 06:25:33PM +0200, Johannes Bauer wrote: Therefore, I've uploaded the compressed trace.dat file, so you can maybe have a look why the report tool barfs and interpret it correctly. I can't figure it out. The trace is here: http://spornkuller.de/trace.dat.bz2 I can read this trace. Can you do info pci in qemu's monitor after failure? What is your command line? Also after the failure: x/256b 0x2b -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM entry failed, hardware error
On 04.06.2012 10:53, Gleb Natapov wrote:
On Sun, Jun 03, 2012 at 06:25:33PM +0200, Johannes Bauer wrote:
Therefore, I've uploaded the compressed trace.dat file, so you can maybe
have a look why the report tool barfs and interpret it correctly. I
can't figure it out. The trace is here:
http://spornkuller.de/trace.dat.bz2
I can read this trace.
Hm, weird. But good that it works on your side. I get a lot of:
trace-cmd: No such file or directory
bad op token {
failed to read event print fmt for kvm_emulate_insn
version = 6
CPU 0 is empty
cpus=4
qemu-system-x86-10775 [001] 2512.220779: kvm_fpu: load
qemu-system-x86-10775 [001] 2512.220782: kvm_entry:vcpu 0
qemu-system-x86-10775 [001] 2512.220785: kvm_exit: reason
EXCEPTION_NMI rip 0xfff0 info 0 8b0e
qemu-system-x86-10775 [001] 2512.220787: kvm_page_fault: address
0 error_code 14
qemu-system-x86-10775 [001] 2512.220796: kvm_entry:vcpu 0
qemu-system-x86-10775 [001] 2512.220798: kvm_exit: reason
EXCEPTION_NMI rip 0xc81e info 0 8b0d
qemu-system-x86-10775 [001] 2512.220803: kvm_emulate_insn: [FAILED
TO PARSE] rip=51230 csbase=983040 len=3 insn= �f%���f flags=0 failed=0
qemu-system-x86-10775 [001] 2512.220806: kvm_entry:vcpu 0
qemu-system-x86-10775 [001] 2512.220807: kvm_exit: reason
EXCEPTION_NMI rip 0xc827 info 0 8b0d
qemu-system-x86-10775 [001] 2512.220808: kvm_emulate_insn: [FAILED
TO PARSE] rip=51239 csbase=983040 len=3 insn=���f�flags=0 failed=0
[...]
Can you do info pci in qemu's monitor
after failure?
(qemu) info pci
Bus 0, device 0, function 0:
Host bridge: PCI device 8086:1237
id
Bus 0, device 1, function 0:
ISA bridge: PCI device 8086:7000
id
Bus 0, device 1, function 1:
IDE controller: PCI device 8086:7010
BAR4: I/O at 0xc000 [0xc00f].
id
Bus 0, device 1, function 3:
Bridge: PCI device 8086:7113
IRQ 9.
id
Bus 0, device 2, function 0:
VGA controller: PCI device 1013:00b8
BAR0: 32 bit prefetchable memory at 0xf000 [0xf1ff].
BAR1: 32 bit memory at 0xf200 [0xf2000fff].
BAR6: 32 bit memory at 0x [0xfffe].
id
Bus 0, device 3, function 0:
Ethernet controller: PCI device 8086:100e
IRQ 11.
BAR0: 32 bit memory at 0xf202 [0xf203].
BAR1: I/O at 0xc040 [0xc07f].
BAR6: 32 bit memory at 0x [0x0001fffe].
id
Bus 0, device 4, function 0:
SCSI controller: PCI device 1af4:1001
IRQ 11.
BAR0: I/O at 0xc080 [0xc0bf].
BAR1: 32 bit memory at 0xf206 [0xf2060fff].
id
What is your command line?
bin/qemu-system-x86_64 -cpu host -enable-kvm -net nic -net
user,smb=Share,restrict=on -drive
media=disk,file=Windows7_x32.qcow2,if=virtio -m 2048 -smp 1 -nographic
(added -nographic to be able to enter the console)
Also, as per Avi's request:
(qemu) x/256b 0x2b
002b: 0xeb 0x26 0x27 0x00 0x00 0x00 0x2b 0x00
002b0008: 0xff 0xff 0x00 0x00 0x00 0x9a 0xcf 0x00
002b0010: 0xff 0xff 0x00 0x00 0x00 0x92 0xcf 0x00
002b0018: 0xff 0xff 0x00 0x00 0x2b 0x9f 0x00 0x00
002b0020: 0xff 0xff 0x00 0x02 0x00 0x93 0x00 0x00
002b0028: 0x8a 0x15 0x68 0xbc 0x00 0x00 0xa1 0xbf
002b0030: 0x00 0x2b 0x00 0x85 0xc0 0x74 0x06 0x8b
002b0038: 0x1d 0xbb 0x00 0x2b 0x00 0xa1 0xc7 0x00
002b0040: 0x2b 0x00 0x85 0xc0 0x74 0x06 0x8b 0x15
002b0048: 0xc3 0x00 0x2b 0x00 0xbe 0x00 0x00 0x20
002b0050: 0x00 0x31 0xc0 0x31 0xff 0x66 0x8b 0x3d
002b0058: 0xb5 0x00 0x2b 0x00 0xc1 0xe7 0x04 0x66
002b0060: 0xa1 0xb3 0x00 0x2b 0x00 0x01 0xc7 0x8b
002b0068: 0x0d 0xb7 0x00 0x2b 0x00 0xfc 0xf3 0xa4
002b0070: 0x0f 0x01 0x15 0x02 0x00 0x2b 0x00 0x66
002b0078: 0xb8 0x20 0x00 0x8e 0xd8 0x8e 0xc0 0x8e
002b0080: 0xe0 0x8e 0xe8 0x8e 0xd0 0xbc 0x00 0x02
002b0088: 0x00 0x00 0xea 0x91 0x00 0x00 0x00 0x18
002b0090: 0x00 0x0f 0x20 0xc0 0x66 0x83 0xe0 0xfe
002b0098: 0x0f 0x22 0xc0 0x66 0x31 0xc0 0x8e 0xd8
002b00a0: 0x8e 0xc0 0x8e 0xd0 0x66 0xbc 0x00 0x04
002b00a8: 0x00 0x00 0x8e 0xe0 0x8e 0xe8 0xea 0x00
002b00b0: 0x00 0x00 0x20 0x00 0x00 0x00 0x20 0x4a
002b00b8: 0xda 0x05 0x00 0x80 0x00 0x00 0x00 0x01
002b00c0: 0x00 0x00 0x00 0x80 0x00 0x00 0x00 0x01
002b00c8: 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x90
002b00d0: 0x90 0x90 0x55 0x89 0xe5 0x57 0x8b 0x7d
002b00d8: 0x0c 0x56 0x53 0x8b 0x5d 0x08 0x6a 0x23
002b00e0: 0x6a 0x00 0x68 0x80 0x05 0x00 0x00 0xe8
002b00e8: 0xf3 0xcf 0x00 0x00 0x83 0xc4 0x0c 0x83
002b00f0: 0x3d 0xe0 0x04 0x03 0x00 0x00 0xc6 0x05
002b00f8: 0x80 0x05 0x00 0x00 0x13 0x74 0x0d 0x53
Best regards,
Joe
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a
Re: KVM entry failed, hardware error
On 04.06.2012 20:28, Johannes Bauer wrote: What is your command line? bin/qemu-system-x86_64 -cpu host -enable-kvm -net nic -net user,smb=Share,restrict=on -drive media=disk,file=Windows7_x32.qcow2,if=virtio -m 2048 -smp 1 -nographic Just noticed that the output I just provided was for the 32 Bit version of Windows 7. Did the same (info pci and the memdump) for the 64 Bit version again and diffed them with meld -- they're *perfectly* identical. Just so there isn't any confusion. Best regards, Joe -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
KVM entry failed, hardware error
Hi list, when trying to install Windows7 in a qemu-kvm 1.0.1 installation on Gentoo on my host running Linux joequad 3.3.7 #1 SMP PREEMPT Sun Jun 3 12:05:59 CEST 2012 x86_64 Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz GenuineIntel GNU/Linux with a host CPU of processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Core(TM)2 Quad CPUQ9550 @ 2.83GHz stepping: 10 microcode : 0xa07 cpu MHz : 2003.000 cache size : 6144 KB physical id : 0 siblings: 4 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm dts tpr_shadow vnmi flexpriority bogomips: 5680.90 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: the installation first works fine but upon first reboot qemu terminates with: KVM: entry failed, hardware error 0x8021 If you're runnning 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=0010 EBX=0080 ECX= EDX=0080 ESI=0025da4a EDI=0007da4a EBP=1f20 ESP=0200 EIP=009b EFL=0002 [---] CPL=3 II=0 A20=1 SMM=0 HLT=0 ES =0020 0200 9300 CS =b000 002b f300 SS =0020 0200 f300 DS =0020 0200 9300 FS =0020 0200 9300 GS =0020 0200 9300 LDT= 8200 TR = 8b00 GDT= 002b 0027 IDT= 03ff CR0=0010 CR2= CR3= CR4= DR0= DR1= DR2= DR3= DR6=0ff0 DR7=0400 EFER= Code=02 00 00 ea 91 00 00 00 18 00 0f 20 c0 66 83 e0 fe 0f 22 c0 66 31 c0 8e d8 8e c0 8e d0 66 bc 00 04 00 00 8e e0 8e e8 ea 00 00 00 20 00 00 00 20 4a da which disassembles to 0: 02 00 add(%eax),%al 2: 00 ea add%ch,%dl 4: 91 xchg %eax,%ecx 5: 00 00 add%al,(%eax) 7: 00 18 add%bl,(%eax) 9: 00 0f add%cl,(%edi) b: 20 c0 and%al,%al d: 66 83 e0 fe and$0xfffe,%ax 11: 0f 22 c0mov%eax,%cr0 14: 66 31 c0xor%eax,%eax 17: 8e d8 mov%ax,%ds 19: 8e c0 mov%ax,%es 1b: 8e d0 mov%ax,%ss 1d: 66 bc 00 04 00 00 mov$0x400,%esp 23: 8e e0 mov%ax,%fs 25: 8e e8 mov%ax,%gs 27: ea 00 00 00 20 ljmp $0x2000,$0x0 Since the instruction clears PE of %cr0, I'm pretty sure it's trying to enter real mode again (for a very brief period no doubt) before firing up the OS. Since I believe my CPU is too old and does not support Unrestricted Guest, this causes qemu to barf. Is this assessment correct? Is there some way of getting qemu to switch to soft emulation in real mode and to use KVM in protected mode? Or is it impossible to run Windows 7 with kvm on a Core Quad (which possibly doesn't support Unrestricted Guest)? For reference, there's at least one more person having an identical problem (I've also posted in that thread): http://forums.gentoo.org/viewtopic-p-7054198.html To find out if my CPU really does not suport Unrestricted Guest I've also posted http://software.intel.com/en-us/forums/showthread.php?t=105687 Any help is greatly appreciated, Best regards, Joe -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM entry failed, hardware error
On 06/03/2012 03:18 PM, Johannes Bauer wrote: Hi list, when trying to install Windows7 in a qemu-kvm 1.0.1 installation on Gentoo on my host running Is that a 32-bit or 64-bit Windows 7? Linux joequad 3.3.7 #1 SMP PREEMPT Sun Jun 3 12:05:59 CEST 2012 x86_64 Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz GenuineIntel GNU/Linux with a host CPU of processor : 0 vendor_id : GenuineIntel cpu family: 6 model : 23 model name: Intel(R) Core(TM)2 Quad CPUQ9550 @ 2.83GHz stepping : 10 microcode : 0xa07 cpu MHz : 2003.000 cache size: 6144 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 4 apicid: 0 initial apicid: 0 fpu : yes fpu_exception : yes cpuid level : 13 wp: yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm dts tpr_shadow vnmi flexpriority bogomips : 5680.90 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: the installation first works fine but upon first reboot qemu terminates with: KVM: entry failed, hardware error 0x8021 If you're runnning 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=0010 EBX=0080 ECX= EDX=0080 ESI=0025da4a EDI=0007da4a EBP=1f20 ESP=0200 EIP=009b EFL=0002 [---] CPL=3 II=0 A20=1 SMM=0 HLT=0 ES =0020 0200 9300 CS =b000 002b f300 Pre-unrestricted mode hosts require cs.selector (first number) * 16 == cs.base (second number). This clearly isn't the case here. Since the instruction clears PE of %cr0, I'm pretty sure it's trying to enter real mode again (for a very brief period no doubt) before firing up the OS. Since I believe my CPU is too old and does not support Unrestricted Guest, this causes qemu to barf. Is this assessment correct? Is there some way of getting qemu to switch to soft emulation in real mode and to use KVM in protected mode? # rmmod kvm_intel # modprobe kvm_intel emulate_invalid_guest_state=1 Warning: experimental code. Or is it impossible to run Windows 7 with kvm on a Core Quad (which possibly doesn't support Unrestricted Guest)? It should be possible. Did you do anything special with the guest (install any software?) before rebooting? Is this repeatable? For reference, there's at least one more person having an identical problem (I've also posted in that thread): http://forums.gentoo.org/viewtopic-p-7054198.html Same cs.sel/cs.base as your report. To find out if my CPU really does not suport Unrestricted Guest I've also posted http://software.intel.com/en-us/forums/showthread.php?t=105687 You can run vmxcap [1] and see. [1] http://git.qemu.org/?p=qemu.git;a=blob_plain;f=scripts/kvm/vmxcap;hb=HEAD -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM entry failed, hardware error
On 03.06.2012 14:33, Avi Kivity wrote: when trying to install Windows7 in a qemu-kvm 1.0.1 installation on Gentoo on my host running Is that a 32-bit or 64-bit Windows 7? 64 bit. But I've also (in despair) tried installing 32 Bit Windows 7, with the exact same effect. EAX=0010 EBX=0080 ECX= EDX=0080 ESI=0025da4a EDI=0007da4a EBP=1f20 ESP=0200 EIP=009b EFL=0002 [---] CPL=3 II=0 A20=1 SMM=0 HLT=0 ES =0020 0200 9300 CS =b000 002b f300 Pre-unrestricted mode hosts require cs.selector (first number) * 16 == cs.base (second number). This clearly isn't the case here. I've checked with vmxcap and my PC indeed does not support unrestricted mode. My Laptop (on which the identical image works perfectly) does. # rmmod kvm_intel # modprobe kvm_intel emulate_invalid_guest_state=1 Warning: experimental code. Tried it out -- I don't get the error anymore, but qemu just hangs on boot with 100% CPU. :-( Or is it impossible to run Windows 7 with kvm on a Core Quad (which possibly doesn't support Unrestricted Guest)? It should be possible. Did you do anything special with the guest (install any software?) before rebooting? Is this repeatable? Nothing at all, just a standard installation. Did not even get to the point where I *could* install software (it reboots during the installation and that's where it doesn't come up anymore). I even tried to completing the installation on my laptop (which works), then copy the image back on my desktop PC: Same error. Any hints on how I could debug the hang with the emulation of invalid guest state? Or is there a more recent version (git?) than a 3.3.7 kernel that I should try out? Thanks for your help, Best regards, Joe -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM entry failed, hardware error
On 03.06.2012 14:33, Avi Kivity wrote: You can run vmxcap [1] and see. Ah, I forgot to attach the output of vmxcap, which might be of interest. First the host where it does not work: pin-based controls External interrupt exiting yes NMI exiting yes Virtual NMIs yes Activate VMX-preemption timerno primary processor-based controls Interrupt window exiting yes Use TSC offsetting yes HLT exiting yes INVLPG exiting yes MWAIT exitingyes RDPMC exitingyes RDTSC exitingyes CR3-load exiting forced CR3-store exitingforced CR8-load exiting yes CR8-store exitingyes Use TPR shadow yes NMI-window exiting yes MOV-DR exiting yes Unconditional I/O exitingyes Use I/O bitmaps yes Monitor trap flagno Use MSR bitmaps yes MONITOR exiting yes PAUSE exitingyes Activate secondary control yes secondary processor-based controls Virtualize APIC accesses yes Enable EPT no Descriptor-table exiting no Virtualize x2APIC mode no Enable VPID no WBINVD exiting yes Unrestricted guest no PAUSE-loop exiting no VM-Exit controls Save debug controls forced Host address-space size yes Load IA32_PERF_GLOBAL_CTRL yes Acknowledge interrupt on exityes Save IA32_PATno Load IA32_PATno Save IA32_EFER no Load IA32_EFER no Save VMX-preemption timer value no VM-Entry controls Load debug controls forced IA-64 mode guest yes Entry to SMM yes Deactivate dual-monitor treatmentyes Load IA32_PERF_GLOBAL_CTRL yes Load IA32_PATno Load IA32_EFER no Miscellaneous data VMX-preemption timer scale (log2)0 Store EFER.LMA into IA-32e mode guest control no HLT activity state yes Shutdown activity state yes Wait-for-SIPI activity state yes Number of CR3-target values 4 MSR-load/store count recommenation 0 MSEG revision identifier 0 VPID and EPT capabilities Execute-only EPT translationsno Page-walk length 4 no Paging-structure memory type UC no Paging-structure memory type WB no 2MB EPT pagesno 1GB EPT pagesno INVEPT supported no Single-context INVEPTno All-context INVEPT no INVVPID supportedno Individual-address INVVPID no Single-context INVVPID no All-context INVVPID no Single-context-retaining-globals INVVPID no Then the one where it does: pin-based controls External interrupt exiting yes NMI exiting yes Virtual NMIs yes Activate VMX-preemption timeryes primary processor-based controls Interrupt window exiting yes Use TSC offsetting yes HLT exiting yes INVLPG exiting yes MWAIT exitingyes RDPMC exitingyes RDTSC exitingyes CR3-load exiting default CR3-store exitingdefault CR8-load exiting yes CR8-store exitingyes Use TPR shadow yes NMI-window exiting yes MOV-DR exiting yes Unconditional I/O exitingyes Use I/O bitmaps yes Monitor trap flagyes Use MSR bitmaps yes MONITOR exiting yes PAUSE exitingyes Activate secondary control yes secondary processor-based controls Virtualize APIC accesses
Re: KVM entry failed, hardware error
On 06/03/2012 04:01 PM, Johannes Bauer wrote: On 03.06.2012 14:33, Avi Kivity wrote: when trying to install Windows7 in a qemu-kvm 1.0.1 installation on Gentoo on my host running Is that a 32-bit or 64-bit Windows 7? 64 bit. But I've also (in despair) tried installing 32 Bit Windows 7, with the exact same effect. EAX=0010 EBX=0080 ECX= EDX=0080 ESI=0025da4a EDI=0007da4a EBP=1f20 ESP=0200 EIP=009b EFL=0002 [---] CPL=3 II=0 A20=1 SMM=0 HLT=0 ES =0020 0200 9300 CS =b000 002b f300 Pre-unrestricted mode hosts require cs.selector (first number) * 16 == cs.base (second number). This clearly isn't the case here. Gleb points out that cs.base == gdt.base, which doesn't make a lot of sense. So some corruption has happened earlier. Please follow http://www.linux-kvm.org/page/Tracing and post the last few thousand lines somewhere. Trace a uniprocessor guest if the problem reproduces that way. I've checked with vmxcap and my PC indeed does not support unrestricted mode. My Laptop (on which the identical image works perfectly) does. # rmmod kvm_intel # modprobe kvm_intel emulate_invalid_guest_state=1 Warning: experimental code. Tried it out -- I don't get the error anymore, but qemu just hangs on boot with 100% CPU. :-( Not too surprising, this hasn't been tested in quite a while. Or is it impossible to run Windows 7 with kvm on a Core Quad (which possibly doesn't support Unrestricted Guest)? It should be possible. Did you do anything special with the guest (install any software?) before rebooting? Is this repeatable? Nothing at all, just a standard installation. Did not even get to the point where I *could* install software (it reboots during the installation and that's where it doesn't come up anymore). I even tried to completing the installation on my laptop (which works), then copy the image back on my desktop PC: Same error. That should help the tracing effort. Any hints on how I could debug the hang with the emulation of invalid guest state? Or is there a more recent version (git?) than a 3.3.7 kernel that I should try out? 3.3.7 should definitely work. Let's see what the traces tell us. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM entry failed, hardware error
On 03.06.2012 15:43, Avi Kivity wrote:
On 06/03/2012 04:01 PM, Johannes Bauer wrote:
On 03.06.2012 14:33, Avi Kivity wrote:
when trying to install Windows7 in a qemu-kvm 1.0.1 installation on
Gentoo on my host running
Is that a 32-bit or 64-bit Windows 7?
64 bit. But I've also (in despair) tried installing 32 Bit Windows 7,
with the exact same effect.
EAX=0010 EBX=0080 ECX= EDX=0080
ESI=0025da4a EDI=0007da4a EBP=1f20 ESP=0200
EIP=009b EFL=0002 [---] CPL=3 II=0 A20=1 SMM=0 HLT=0
ES =0020 0200 9300
CS =b000 002b f300
Pre-unrestricted mode hosts require cs.selector (first number) * 16 ==
cs.base (second number). This clearly isn't the case here.
Gleb points out that cs.base == gdt.base, which doesn't make a lot of
sense. So some corruption has happened earlier. Please follow
http://www.linux-kvm.org/page/Tracing and post the last few thousand
lines somewhere. Trace a uniprocessor guest if the problem reproduces
that way.
Tried that -- and failed miserably.
Something in the trace format appears to have changed. When using
trace-cmd report, I first get a parser warning:
trace-cmd: No such file or directory
bad op token {
failed to read event print fmt for kvm_emulate_insn
version = 6
CPU 0 is empty
cpus=4
The ENOENT errno doesn't correspond to that error, strace showed that
occuring much earlier in something unrelated. The warning is generated by:
#1 0x00412c66 in process_op (event=0x6537c0, arg=0x6564f0,
tok=0x7fffd508) at /home/joe/qemu/trace/trace-cmd/parse-events.c:1686
#2 0x00414eef in process_arg_token (event=0x6537c0,
arg=0x6564f0, tok=0x7fffd598, type=EVENT_OP) at
/home/joe/qemu/trace/trace-cmd/parse-events.c:2604
#3 0x00412727 in process_arg (event=0x6537c0, arg=0x6564f0,
tok=0x7fffd598) at /home/joe/qemu/trace/trace-cmd/parse-events.c:1514
#4 0x004146b4 in process_paren (event=0x6537c0, arg=0x6564f0,
tok=0x7fffd5f8) at /home/joe/qemu/trace/trace-cmd/parse-events.c:2352
#5 0x00414eb0 in process_arg_token (event=0x6537c0,
arg=0x6564f0, tok=0x7fffd678, type=EVENT_DELIM) at
/home/joe/qemu/trace/trace-cmd/parse-events.c:2596
#6 0x00412727 in process_arg (event=0x6537c0, arg=0x6564f0,
tok=0x7fffd678) at /home/joe/qemu/trace/trace-cmd/parse-events.c:1514
#7 0x00414f87 in event_read_print_args (event=0x6537c0,
list=0x656490) at /home/joe/qemu/trace/trace-cmd/parse-events.c:2637
#8 0x0041524f in event_read_print (event=0x6537c0) at
/home/joe/qemu/trace/trace-cmd/parse-events.c:2723
#9 0x00419040 in pevent_parse_event (pevent=0x63a0d0,
buf=0x653390 name: kvm_emulate_insn\nID:
29\nformat:\n\tfield:unsigned short
common_type;\toffset:0;\tsize:2;\tsigned:0;\n\tfield:unsigned char
common_flags;\toffset:2;\tsize:1;\tsigned:0;\n\tfield:unsigned char
common_preempt_..., size=1053, sys=0x640790 kvm) at
/home/joe/qemu/trace/trace-cmd/parse-events.c:4626
#10 0x0042190a in read_event_file (handle=0x63a030,
system=0x640790 kvm, size=1053, print=0) at
/home/joe/qemu/trace/trace-cmd/trace-input.c:386
#11 0x00421a90 in read_event_files (handle=0x63a030, print=0) at
/home/joe/qemu/trace/trace-cmd/trace-input.c:450
#12 0x00421cb3 in tracecmd_read_headers (handle=0x63a030) at
/home/joe/qemu/trace/trace-cmd/trace-input.c:539
#13 0x0040c6a5 in trace_report (argc=2, argv=0x7fffd9d8) at
/home/joe/qemu/trace/trace-cmd/trace-read.c:1025
#14 0x004057e7 in main (argc=2, argv=0x7fffd9d8) at
/home/joe/qemu/trace/trace-cmd/trace-cmd.c:147
The decoding that follows is complete garbage, which is why I think it's
of no use to you (i.e. the insn= part just displays some random
undefined memory from the looks).
Therefore, I've uploaded the compressed trace.dat file, so you can maybe
have a look why the report tool barfs and interpret it correctly. I
can't figure it out. The trace is here:
http://spornkuller.de/trace.dat.bz2
The trace was generated with a buffer of 4 (double of what was given
in the example), when it was lower I had overruns. This way I had none.
Also, to simulate a single cpu, I've run qemu with -smp 1, hopefully
that's correct.
I even tried to completing the installation on my laptop (which works),
then copy the image back on my desktop PC: Same error.
That should help the tracing effort.
Should I also generate a trace there and look for the corresponding
opcodes that fail on my main machine?
Best regards,
Joe
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
