From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: kvm_amd BUG: unable to handle kernel NULL pointer dereference at 00000014 Date: Mon, 07 Mar 2011 14:50:14 +0200 Message-ID: <4D74D486.2080206@redhat.com> References: <4D736090.1000300@redhat.com> <20110307121138.GD17719@amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IVAN ANGELOV , "kvm@vger.kernel.org" , Ingo Molnar , x86@kernel.org To: "Roedel, Joerg" Return-path: Received: from mx1.redhat.com ([209.132.183.28]:7728 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752052Ab1CGMve (ORCPT ); Mon, 7 Mar 2011 07:51:34 -0500 In-Reply-To: <20110307121138.GD17719@amd.com> Sender: kvm-owner@vger.kernel.org List-ID: On 03/07/2011 02:11 PM, Roedel, Joerg wrote: > (CC'ing x86 Maintainers) > > On Sun, Mar 06, 2011 at 05:23:12AM -0500, Avi Kivity wrote: > > On 03/04/2011 12:34 AM, IVAN ANGELOV wrote: > > > Hello, > > > This provided dmesg message and kernel behavior appear when trying to > > > run qemu-kvm with kvm_amd module. Without kvm_amd qemu-kvm runs fine > > > but a slower. I managed to see that this happens with 2.6.38-rc6 , > > > 2.6.38-rc7 vanilla kernels compiled using kernel-package. OS ubuntu > > > natty. Using the standard toolchain and gcc from ubuntu: gcc version > > > 4.5.2 (Ubuntu/Linaro 4.5.2-3ubuntu3) > > > I reverted to 2.6.37.2 linux kernel, compiled with the very same tools > > > and machine I use qemu-kvm with kvm_amd module without any problems. > > > If I can provide some extra info about that please let me know. > > > This issue also appears with the kernel provided by the Ubuntu > > > distribution: 2.6.38-5-generic-pae #32-Ubuntu SMP Tue Feb 22 17:48:56 > > > UTC 2011 i686 athlon i386 GNU/Linux , I suspect it is somehow related > > > to the 2.6.38 kernel series. > > > cpuinfo - phenom ii x4 955 mildly overclocked - 4 fields like this is > > > the whole cpuinfo. > > > > > > c: 65 a1 14 00 00 00 mov %gs:0x14,%eax > > > > faults, gsbase == NULL. > > > > But arch/x86/include/asm/percpu.h says: > > > > #ifdef CONFIG_X86_64 > > #define __percpu_seg gs > > #define __percpu_mov_op movq > > #else > > #define __percpu_seg fs > > #define __percpu_mov_op movl > > #endif > > > > > > So we should be using %fs, not %gs. > > There is no access to per_cpu variables at the start of x86_decode_insn. > I did a bit of investigation and it turns out that the faulting > instruction is inserted into the code by the gcc because the > CONFIG_CC_STACKPROTECTOR is enabled. > The user tested this is Ubuntu 11.04 alpha-something i386 and this > distro uses gcc 4.5.2. So CC_STACKPROTECTOR seems to be harmful with > this gcc version but I am not sure whether this counts as a gcc bug. Ah, looks like %gs is the expected segment on i386 with -fstack-protector. So we must disable lazy gs reload in that scenario. -- error compiling committee.c: too many arguments to function