On 16.08.2010, at 15:49, Serge Belyshev wrote: > Alexander Graf <agraf@xxxxxxx> writes: > >> Hrm - try to use the following (probably whitespace broken and 100% untested) hacky patch: >> >> diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c >> index 56c9b6b..bde9ee3 100644 >> --- a/arch/x86/kvm/svm.c >> +++ b/arch/x86/kvm/svm.c >> @@ -429,9 +429,11 @@ static int svm_hardware_enable(void *garbage) >> struct desc_struct *gdt; >> int me = raw_smp_processor_id(); >> >> +#if 0 >> rdmsrl(MSR_EFER, efer); >> if (efer & EFER_SVME) >> return -EBUSY; >> +#endif >> > > I tested a bit different hack keeping rdmsrl but removing the if() and > it works fine for me: > > Index: linux/arch/x86/kvm/svm.c > =================================================================== > --- linux.orig/arch/x86/kvm/svm.c > +++ linux/arch/x86/kvm/svm.c > @@ -429,8 +429,7 @@ static int svm_hardware_enable(void *gar > int me = raw_smp_processor_id(); > > rdmsrl(MSR_EFER, efer); > - if (efer & EFER_SVME) > - return -EBUSY; > + printk(KERN_DEBUG "svm_hardware_enable: efer %x on %d\n", efer, me); Ouch, yes. Thanks for not taking my patch ;). The efer read is of course still mandatory. > > if (!has_svm()) { > printk(KERN_ERR "svm_hardware_enable: err EOPNOTSUPP on %d\n", > > Here is an example of its output: > > [231441.358111] svm_hardware_enable: efer 1d01 on 0 > [231441.358117] svm_hardware_enable: efer d01 on 3 > [231441.358124] svm_hardware_enable: efer d01 on 2 > [231441.358135] svm_hardware_enable: efer d01 on 1 > [231675.168967] svm_hardware_enable: efer d01 on 0 > [231675.168972] svm_hardware_enable: efer d01 on 1 > [231675.168983] svm_hardware_enable: efer d01 on 2 > [231675.168995] svm_hardware_enable: efer d01 on 3 > > > After reboot, the first kvm run always reports efer = 1d01 on the first cpu. > In all subsequent runs before reboot efer stays d01 on all cpus. Happy broken BIOS fun. Oh well, I guess you can live with the patched version and normal end-users will just update their BIOSes. Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html