diff mbox

Unable to boot guest on kernel 2.6.29.1 with kvm-84 or kvm-85

Message ID 49FBFB6D.7060207@redhat.com (mailing list archive)
State New, archived
Headers show

Commit Message

Avi Kivity May 2, 2009, 7:51 a.m. UTC
Kenni Lund wrote:
> Avi Kivity avi@redhat.com wrote:
>   
>> Kenni Lund wrote:
>>     
>>> Ok, but as I write in my message, I'm using the
>>>       
>> KVM modules from the latest> upstream kernel, not the kvm-85
>> modules.>
>>     
>>> According to the KVM download page, http://www.linux-kvm.org/page/Downloads,> any kernel above 2.6.25 should work with the
>>>       
>> latest KVM userspace. This has> been true until now in my case, but it breaks
>> with 2.6.29.1 and that's the reason> why I'm posting this bug report.
>>     
>>>   
>>>       
>> Can you try a bisect?
>>     
>
> Yes, sorry for the late reply. I did the bisect as requested and it returned the following results:
>
> # bad: [8d7bff2d72660d9d60aa371ae3d1356bbf329a09] Linux 2.6.29.1
> # good: [4a6908a3a050aacc9c3a2f36b276b46c0629ad91] Linux 2.6.28 
> git bisect start 'v2.6.29.1' 'v2.6.28' '--' 'arch/x86/kvm' 'virt/kvm'
> # good: [b82091824ee4970adf92d5cd6d57b12273171625] KVM: Prevent trace call into unloaded module text
> git bisect good b82091824ee4970adf92d5cd6d57b12273171625                                            
> # good: [7f59f492da722eb3551bbe1f8f4450a21896f05d] KVM: use cpumask_var_t for cpus_hardware_enabled 
> git bisect good 7f59f492da722eb3551bbe1f8f4450a21896f05d                                            
> # good: [19de40a8472fa64693eab844911eec277d489f6c] KVM: change KVM to use IOMMU API                 
> git bisect good 19de40a8472fa64693eab844911eec277d489f6c                                            
> # good: [2aaf69dcee864f4fb6402638dd2f263324ac839f] KVM: MMU: Map device MMIO as UC in EPT
> git bisect good 2aaf69dcee864f4fb6402638dd2f263324ac839f
> # good: [682edb4c01e690c7c7cd772dbd6f4e0fd74dc572] KVM: Fix assigned devices circular locking dependency
> git bisect good 682edb4c01e690c7c7cd772dbd6f4e0fd74dc572
> # bad: [f438349efb8247cd0c1d453a4131b1f801bf5691] KVM: VMX: Don't allow uninhibited access to EFER on i386
> git bisect bad f438349efb8247cd0c1d453a4131b1f801bf5691
> # good: [516a1a7e9dc80358030fe01aabb3bedf882db9e2] KVM: VMX: Flush volatile msrs before emulating rdmsr
> git bisect good 516a1a7e9dc80358030fe01aabb3bedf882db9e2
>
> ----------------
> And the final output:
>
> f438349efb8247cd0c1d453a4131b1f801bf5691 is first bad commit
> commit f438349efb8247cd0c1d453a4131b1f801bf5691
> Author: Avi Kivity 
> Date:   Thu Mar 26 23:05:03 2009 +0000
>
>     KVM: VMX: Don't allow uninhibited access to EFER on i386
>
>     upstream commit: 16175a796d061833aacfbd9672235f2d2725df65
>
>     vmx_set_msr() does not allow i386 guests to touch EFER, but they can still
>     do so through the default: label in the switch.  If they set EFER_LME, they
>     can oops the host.
>
>     Fix by having EFER access through the normal channel (which will check for
>     EFER_LME) even on i386.
>
>     Reported-and-tested-by: Benjamin Gilbert 
>     Cc: stable@kernel.org
>     Signed-off-by: Avi Kivity 
>     Signed-off-by: Chris Wright 
>
> :040000 040000 cf7848d35c136beee6665e67839080d450977af0 0a39980481dd346306b2ac54dbe916741515f1f1 M      arch
>
> ----------------
>
> FYI, I also tested 2.6.29.2 and the issue still exists.
>
> Do you need more information?
>
>   

Please try the attached patch.

Comments

Avi Kivity May 3, 2009, 10:14 a.m. UTC | #1
Avi Kivity wrote:
> Kenni Lund wrote:
>> Avi Kivity avi@redhat.com wrote:
>>  
>>> Kenni Lund wrote:
>>>    
>>>> Ok, but as I write in my message, I'm using the
>>>>       
>>> KVM modules from the latest> upstream kernel, not the kvm-85
>>> modules.>
>>>    
>>>> According to the KVM download page, 
>>>> http://www.linux-kvm.org/page/Downloads,> any kernel above 2.6.25 
>>>> should work with the
>>>>       
>>> latest KVM userspace. This has> been true until now in my case, but 
>>> it breaks
>>> with 2.6.29.1 and that's the reason> why I'm posting this bug report.
>>>    
>>>>         
>>> Can you try a bisect?
>>>     
>>
>> Yes, sorry for the late reply. I did the bisect as requested and it 
>> returned the following results:
>>
>> # bad: [8d7bff2d72660d9d60aa371ae3d1356bbf329a09] Linux 2.6.29.1
>> # good: [4a6908a3a050aacc9c3a2f36b276b46c0629ad91] Linux 2.6.28 git 
>> bisect start 'v2.6.29.1' 'v2.6.28' '--' 'arch/x86/kvm' 'virt/kvm'
>> # good: [b82091824ee4970adf92d5cd6d57b12273171625] KVM: Prevent trace 
>> call into unloaded module text
>> git bisect good 
>> b82091824ee4970adf92d5cd6d57b12273171625                                            
>> # good: [7f59f492da722eb3551bbe1f8f4450a21896f05d] KVM: use 
>> cpumask_var_t for cpus_hardware_enabled git bisect good 
>> 7f59f492da722eb3551bbe1f8f4450a21896f05d                                            
>> # good: [19de40a8472fa64693eab844911eec277d489f6c] KVM: change KVM to 
>> use IOMMU API                 git bisect good 
>> 19de40a8472fa64693eab844911eec277d489f6c                                            
>> # good: [2aaf69dcee864f4fb6402638dd2f263324ac839f] KVM: MMU: Map 
>> device MMIO as UC in EPT
>> git bisect good 2aaf69dcee864f4fb6402638dd2f263324ac839f
>> # good: [682edb4c01e690c7c7cd772dbd6f4e0fd74dc572] KVM: Fix assigned 
>> devices circular locking dependency
>> git bisect good 682edb4c01e690c7c7cd772dbd6f4e0fd74dc572
>> # bad: [f438349efb8247cd0c1d453a4131b1f801bf5691] KVM: VMX: Don't 
>> allow uninhibited access to EFER on i386
>> git bisect bad f438349efb8247cd0c1d453a4131b1f801bf5691
>> # good: [516a1a7e9dc80358030fe01aabb3bedf882db9e2] KVM: VMX: Flush 
>> volatile msrs before emulating rdmsr
>> git bisect good 516a1a7e9dc80358030fe01aabb3bedf882db9e2
>>
>> ----------------
>> And the final output:
>>
>> f438349efb8247cd0c1d453a4131b1f801bf5691 is first bad commit
>> commit f438349efb8247cd0c1d453a4131b1f801bf5691
>> Author: Avi Kivity Date:   Thu Mar 26 23:05:03 2009 +0000
>>
>>     KVM: VMX: Don't allow uninhibited access to EFER on i386
>>
>>     upstream commit: 16175a796d061833aacfbd9672235f2d2725df65
>>
>>     vmx_set_msr() does not allow i386 guests to touch EFER, but they 
>> can still
>>     do so through the default: label in the switch.  If they set 
>> EFER_LME, they
>>     can oops the host.
>>
>>     Fix by having EFER access through the normal channel (which will 
>> check for
>>     EFER_LME) even on i386.
>>
>>     Reported-and-tested-by: Benjamin Gilbert     Cc: stable@kernel.org
>>     Signed-off-by: Avi Kivity     Signed-off-by: Chris Wright
>> :040000 040000 cf7848d35c136beee6665e67839080d450977af0 
>> 0a39980481dd346306b2ac54dbe916741515f1f1 M      arch
>>
>> ----------------
>>
>> FYI, I also tested 2.6.29.2 and the issue still exists.
>>
>> Do you need more information?
>>
>>   
>
> Please try the attached patch.
>

It won't help - I reproduced the issue.  Instead, try passing the 
parameter '-cpu qemu32' (or '-cpu qemu64,-nx').
diff mbox

Patch

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index e8a5649..6dcfab1 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -905,9 +905,9 @@  static int vmx_get_msr(struct kvm_vcpu *vcpu, u32 msr_index, u64 *pdata)
 	case MSR_GS_BASE:
 		data = vmcs_readl(GUEST_GS_BASE);
 		break;
+#endif
 	case MSR_EFER:
 		return kvm_get_msr_common(vcpu, msr_index, pdata);
-#endif
 	case MSR_IA32_TIME_STAMP_COUNTER:
 		data = guest_read_tsc();
 		break;