From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Roedel, Joerg" Subject: Re: kvm_amd BUG: unable to handle kernel NULL pointer dereference at 00000014 Date: Mon, 7 Mar 2011 13:11:38 +0100 Message-ID: <20110307121138.GD17719@amd.com> References: <4D736090.1000300@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: IVAN ANGELOV , "kvm@vger.kernel.org" , Ingo Molnar , To: Avi Kivity Return-path: Received: from ch1outboundpool.messaging.microsoft.com ([216.32.181.185]:21309 "EHLO ch1outboundpool.messaging.microsoft.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752663Ab1CGMLq (ORCPT ); Mon, 7 Mar 2011 07:11:46 -0500 Content-Disposition: inline In-Reply-To: <4D736090.1000300@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: (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. Joerg -- AMD Operating System Research Center Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach General Managers: Alberto Bozzo, Andrew Bowd Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632