(sorry for the double post - I mistyped the address of the list)
Hi Uri, Avi,
I think I debugged the
kvm: unhandled wrmsr: 0xc0000083
on guest reboot with recent KVM userspace.
The "root" cause is this commit from Uri:
commit 5e1accfc9e7a7d79244c862c04621f7ba23c6d38
Author: Uri Lublin <[EMAIL PROTECTED]>
Date: Tue Jun 19 20:28:02 2007 +0300
kvm: configure: for i386 machines make x86_64-softmmu the target
To execute the ifdef X86_64 blocks on both sides
diff --git a/configure b/configure
index e4d1ec6..d9292fe 100755
--- a/configure
+++ b/configure
@@ -74,7 +74,7 @@ fi
target_cpu() {
if [[ $(uname -m) = i?86 ]]; then
- echo i386
+ echo x86_64
else
uname -m
fi
which enabled the compilation of code depending on TARGET_X86_64.
Problems arise when the host is in 32 bit mode; Avi fixed part of the
issue with d9ff68d1 (masking the LM bit when the host is 32 bit).
The MSR issue is caused by load_regs (qemu/qemu-kvm.c); at line 304 (git
current) you can see:
#ifdef TARGET_X86_64
set_msr_entry(&msrs[n++], MSR_CSTAR, env->cstar);
set_msr_entry(&msrs[n++], MSR_KERNELGSBASE, env->kernelgsbase);
set_msr_entry(&msrs[n++], MSR_FMASK, env->fmask);
set_msr_entry(&msrs[n++], MSR_LSTAR , env->lstar);
#endif
But the kernel side part (vmx.c) cannot handle those MSRs when using a
32 bit kernel (hence the "unhandled wrmsr").
As a side note: MSC_CSTAR (syscall target for compat mode) is supported
*only* on AMD processors (there's no syscall on Intel in 32 bit mode);
is it safe to use it unconditionally? (AFAICS vmx.c would do wrmsrl,
maybe it's not documented but supported?).
In order to fix this bug I hijacked "lm_capable_kernel" (introduced by
Avi) so that {load,save}_regs don't touch 64bit-only MSRs while the host
is in 32bit mode:
---
qemu-kvm.c | 22 +++++++++++++---------
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/qemu/qemu-kvm.c b/qemu/qemu-kvm.c
index 4ba93d8..b8065db 100644
--- a/qemu/qemu-kvm.c
+++ b/qemu/qemu-kvm.c
@@ -9,6 +9,7 @@
#endif
int kvm_allowed = KVM_ALLOWED_DEFAULT;
+static int lm_capable_kernel;
#ifdef USE_KVM
@@ -302,10 +303,12 @@ static void load_regs(CPUState *env)
set_msr_entry(&msrs[n++], MSR_STAR, env->star);
set_msr_entry(&msrs[n++], MSR_IA32_TSC, env->tsc);
#ifdef TARGET_X86_64
- set_msr_entry(&msrs[n++], MSR_CSTAR, env->cstar);
- set_msr_entry(&msrs[n++], MSR_KERNELGSBASE, env->kernelgsbase);
- set_msr_entry(&msrs[n++], MSR_FMASK, env->fmask);
- set_msr_entry(&msrs[n++], MSR_LSTAR , env->lstar);
+ if (lm_capable_kernel) {
+ set_msr_entry(&msrs[n++], MSR_CSTAR, env->cstar);
+ set_msr_entry(&msrs[n++], MSR_KERNELGSBASE, env->kernelgsbase);
+ set_msr_entry(&msrs[n++], MSR_FMASK, env->fmask);
+ set_msr_entry(&msrs[n++], MSR_LSTAR , env->lstar);
+ }
#endif
rc = kvm_set_msrs(kvm_context, env->cpu_index, msrs, n);
@@ -439,10 +442,12 @@ static void save_regs(CPUState *env)
msrs[n++].index = MSR_STAR;
msrs[n++].index = MSR_IA32_TSC;
#ifdef TARGET_X86_64
- msrs[n++].index = MSR_CSTAR;
- msrs[n++].index = MSR_KERNELGSBASE;
- msrs[n++].index = MSR_FMASK;
- msrs[n++].index = MSR_LSTAR;
+ if (lm_capable_kernel) {
+ msrs[n++].index = MSR_CSTAR;
+ msrs[n++].index = MSR_KERNELGSBASE;
+ msrs[n++].index = MSR_FMASK;
+ msrs[n++].index = MSR_LSTAR;
+ }
#endif
rc = kvm_get_msrs(kvm_context, env->cpu_index, msrs, n);
if (rc == -1) {
@@ -1001,7 +1006,6 @@ static void do_cpuid_ent(struct kvm_cpuid_entry *e,
uint32_t function,
if (function == 0x80000001) {
uint32_t h_eax, h_edx;
struct utsname utsname;
- int lm_capable_kernel;
host_cpuid(function, &h_eax, NULL, NULL, &h_edx);
uname(&utsname);
get_msr_entry should be fine, cpu_save/cpu_load (used by savevm -
qemu/vl.c) may need a similar fix.
The patch stops the "unhandled wrmsr", but reboot is still not working
(guest is stuck using 100% of the CPU). The last working userspace is
KVM-28, and I tested it with recent kernel modules. Any idea on this
one?
Luca
--
Runtime error 6D at f000:a12f : user incompetente
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
