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

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

[Kenni Lund]

Hi

When updating to kernel 2.6.29.1, I'm unable to boot my Windows XP Pro 32bit guest. The problem is consistent (actually on both of my laptops, with two different WinXP guests) and it is fixed immediately when downgrading to kernel 2.6.28.8 or an older kernel version.


Scenario:
I'm booting the guest with the command
qemu-kvm -smp 2 -m 1024 -net nic -net user -daemonize -vnc :1 -hda /data/virtualization/winxp.img -boot c

I connect with VNC and see the QEMU BIOS, followed by the Windows menu which lets me select if I want to boot Windows in safe mode or not. It counts down from 30, but when it get to 0 or once I hit the "Start Windows Normally" it freezes and nothing more happens.

The following is written to dmesg when qemu-kvm is launched:
kvm: 4609: cpu1 unhandled wrmsr: 0xc0010117 data 0
kvm: 4609: cpu0 unhandled wrmsr: 0xc0010117 data 0


Further information:
KVM version: 84+85 (userspace only, kernel modules from stock kernel)

I've tested -no-kvm-irqchip and -no-kvm-pit as the bugs-page describes, but it doesn't make a difference.

Adding -no-kvm actually FIXES the issue and make Windows boot...so it doesn't seem to be QEMU related.

# uname -a
Linux T61 2.6.29-ARCH #1 SMP PREEMPT Fri Apr 17 12:46:01 UTC 2009 i686 Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz GenuineIntel GNU/Linux

# lsmod|grep kvm
kvm_intel              39208  0
kvm                   144944  1 kvm_intel


Is this a known problem with this kernel version? If not, what can I do to help debugging it further?

Best Regards
Kenni Lund

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

[Bernhard Held]

> When updating to kernel 2.6.29.1, I'm unable to boot my Windows XP Pro 32bit guest. The problem is consistent (actually on both of my laptops, with two different WinXP guests) and it is fixed immediately when downgrading to kernel 2.6.28.8 or an older kernel version.
Works for me with modules from kvm-85.

Bernhard

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

[Marcelo Tosatti]

Kenni,

On Thu, Apr 23, 2009 at 07:21:34PM +0200, Kenni Lund wrote:
> Hi
> 
> When updating to kernel 2.6.29.1, I'm unable to boot my Windows XP Pro 32bit guest. The problem is consistent (actually on both of my laptops, with two different WinXP guests) and it is fixed immediately when downgrading to kernel 2.6.28.8 or an older kernel version.
> 
> 
> Scenario:
> I'm booting the guest with the command
> qemu-kvm -smp 2 -m 1024 -net nic -net user -daemonize -vnc :1 -hda /data/virtualization/winxp.img -boot c
> 
> I connect with VNC and see the QEMU BIOS, followed by the Windows menu which lets me select if I want to boot Windows in safe mode or not. It counts down from 30, but when it get to 0 or once I hit the "Start Windows Normally" it freezes and nothing more happens.
> 
> The following is written to dmesg when qemu-kvm is launched:
> kvm: 4609: cpu1 unhandled wrmsr: 0xc0010117 data 0
> kvm: 4609: cpu0 unhandled wrmsr: 0xc0010117 data 0

This message are supposedly harmless (and you should also see them with
2.6.28.8).

Can you try the kvm-85 modules? Can't spot anything obvious between
2.6.28->2.6.29 which would cause such breakage.

> Further information:
> KVM version: 84+85 (userspace only, kernel modules from stock kernel)
> 
> I've tested -no-kvm-irqchip and -no-kvm-pit as the bugs-page describes, but it doesn't make a difference.
> 
> Adding -no-kvm actually FIXES the issue and make Windows boot...so it doesn't seem to be QEMU related.
> 
> # uname -a
> Linux T61 2.6.29-ARCH #1 SMP PREEMPT Fri Apr 17 12:46:01 UTC 2009 i686 Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz GenuineIntel GNU/Linux
> 
> # lsmod|grep kvm
> kvm_intel              39208  0
> kvm                   144944  1 kvm_intel
> 
> 
> Is this a known problem with this kernel version? If not, what can I do to help debugging it further?

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

[Avi Kivity]

Kenni Lund wrote:
>>
>> It won't help - I reproduced the issue. Instead, try passing the
>> parameter '-cpu qemu32' (or '-cpu qemu64,-nx').
>>     
>
> Adding the parameter '-cpu qemu32' (32bit host + 32 bit guest) makes the WinXP guest boot.
> ...but is this parameter equal to '-no-kvm'? Eg. with emulated CPU?
>   

No, as you can tell from the speed (and 'info kvm' output).

'-cpu qemu32' means use the cpu features exposed by the virtual qemu32 
cpu.  The default is qemu64, which includes 64-bit support and NX.  Your 
host kernel doesn't have NX support, but qemu erronously reports that it 
does, causing Windows to get confused.

-- 
error compiling committee.c: too many arguments to function

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

[Kenni Lund]

>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').

Adding the parameter '-cpu qemu32' (32bit host + 32 bit guest) makes the WinXP guest boot.
...but is this parameter equal to '-no-kvm'? Eg. with emulated CPU?

Best Regards
Kenni Lund

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

[Avi Kivity]

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').

-- 
error compiling committee.c: too many arguments to function

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

[Avi Kivity]

[-- Attachment #1: Type: text/plain, Size: 3324 bytes --]

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.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.


[-- Attachment #2: fix-efer-reads.patch --]
[-- Type: text/plain, Size: 454 bytes --]

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;

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

[Kenni Lund]

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?

Best Regards
Kenni Lund

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

[Eino Malinen]

> So 2.6.29 worked and 2.6.29.1 did not?  What is your host cpu type?  Are 
> you running an i386 or x86_64 host?

The issue was solved by forcing -cpu to 32-bit variant. Originally I was 
trying to run 64-bit guest with 32-bit host. Sorry about not checking the 
obvious solution first...

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

[Avi Kivity]

Eino Malinen wrote:
>> Can you try a bisect?
>>     
>
> I confirm having the same trouble with kvm. Bisect with the vanilla kernel 
> gave the following result:
>
> (f438349...|BISECTING)$ git bisect log
> # bad: [8d7bff2d72660d9d60aa371ae3d1356bbf329a09] Linux 2.6.29.1
> # good: [8e0ee43bc2c3e19db56a4adaa9a9b04ce885cd84] Linux 2.6.29
> git bisect start 'v2.6.29.1' 'v2.6.29' '--' 'arch/x86/kvm/' 'virt/kvm/'
> # bad: [f438349efb8247cd0c1d453a4131b1f801bf5691] KVM: VMX: Don't allow 
> uninhibited access to EFER on i386
> git bisect bad f438349efb8247cd0c1d453a4131b1f801bf5691
>
> Are the commits splitted more precisely in kvm.git?
>   
No (and this is pretty fine granularity -- that commit is a one liner).

So 2.6.29 worked and 2.6.29.1 did not?  What is your host cpu type?  Are 
you running an i386 or x86_64 host?

-- 
error compiling committee.c: too many arguments to function

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

[Eino Malinen]

> Can you try a bisect?

I confirm having the same trouble with kvm. Bisect with the vanilla kernel 
gave the following result:

(f438349...|BISECTING)$ git bisect log
# bad: [8d7bff2d72660d9d60aa371ae3d1356bbf329a09] Linux 2.6.29.1
# good: [8e0ee43bc2c3e19db56a4adaa9a9b04ce885cd84] Linux 2.6.29
git bisect start 'v2.6.29.1' 'v2.6.29' '--' 'arch/x86/kvm/' 'virt/kvm/'
# bad: [f438349efb8247cd0c1d453a4131b1f801bf5691] KVM: VMX: Don't allow 
uninhibited access to EFER on i386
git bisect bad f438349efb8247cd0c1d453a4131b1f801bf5691

Are the commits splitted more precisely in kvm.git?

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

[Avi Kivity]

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?

If you bisect only kvm patches it should be pretty fast.  The following 
commands should do it:

  git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6-stable.git

(if you already have a linux git tree somewhere, do 'git remote add -f 
stable 
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6-stable.git' 
instead)

  git bisect start v2.6.29.1 v2.6.28 -- arch/x86/kvm virt/kvm

git will check out a test version, build it and test, and respond with 
'git bisect bad' or 'git bisect good'.  Rinse and repeat.

-- 
error compiling committee.c: too many arguments to function

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

[Kenni Lund]

 On Thu 23/04/09 23:57 , Bernhard Held bheld@mgpi.de sent:
> > When updating to kernel 2.6.29.1, I'm unable to
> > boot my Windows XP Pro 32bit guest. The problem is consistent (actually on
> > both of my laptops, with two different WinXP guests) and it is fixed
> > immediately when downgrading to kernel 2.6.28.8 or an older kernel
> > version.
> Works for me with modules from kvm-85.

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.

Best Regards
Kenni Lund