Re: kvm_amd BUG: unable to handle kernel NULL pointer dereference at 00000014

[Avi Kivity <avi@redhat.com>]

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