From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: Unable to boot guest on kernel 2.6.29.1 with kvm-84 or kvm-85 Date: Sun, 03 May 2009 13:14:04 +0300 Message-ID: <49FD6E6C.1070800@redhat.com> References: <58515.1241218329@kelu.dk> <49FBFB6D.7060207@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org To: kelu@kelu.dk Return-path: Received: from mx2.redhat.com ([66.187.237.31]:49191 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751367AbZECKO3 (ORCPT ); Sun, 3 May 2009 06:14:29 -0400 In-Reply-To: <49FBFB6D.7060207@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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