Re: [Qemu-devel] x86, nops settings result in kernel crash

[Tomas Racek]

----- Original Message -----
> On Fri, Aug 17, 2012 at 03:43:56AM -0400, Tomas Racek wrote:
> > Well, I've added some debug statements to the code:
> > 
> > void __init arch_init_ideal_nops(void)
> > {
> >         switch (boot_cpu_data.x86_vendor) {
> >         case X86_VENDOR_INTEL:
> >                 /*
> >                  * Due to a decoder implementation quirk, some
> >                  * specific Intel CPUs actually perform better with
> >                  * the "k8_nops" than with the SDM-recommended
> >                  NOPs.
> >                  */
> >                 if (boot_cpu_data.x86 == 6 &&
> >                     boot_cpu_data.x86_model >= 0x0f &&
> >                     boot_cpu_data.x86_model != 0x1c &&
> >                     boot_cpu_data.x86_model != 0x26 &&
> >                     boot_cpu_data.x86_model != 0x27 &&
> >                     boot_cpu_data.x86_model < 0x30) {
> >                         printk("NOPS: Option 1\n");
> >                         ideal_nops = k8_nops;
> >                 } else if (boot_cpu_has(X86_FEATURE_NOPL)) {
> >                         printk("NOPS: Option 2\n");
> >                            ideal_nops = p6_nops;
> >                 } else {
> >                         printk("NOPS: Option 3\n");
> > #ifdef CONFIG_X86_64
> >                         ideal_nops = k8_nops;
> > #else
> >                         ideal_nops = intel_nops;
> > #endif
> >                 }
> >                 break;
> >         default:
> > #ifdef CONFIG_X86_64
> >                 ideal_nops = k8_nops;
> > #else
> >                 if (boot_cpu_has(X86_FEATURE_K8))
> >                         ideal_nops = k8_nops;
> >                 else if (boot_cpu_has(X86_FEATURE_K7))
> >                         ideal_nops = k7_nops;
> >                 else
> >                         ideal_nops = intel_nops;
> > #endif
> >         }
> > }
> > 
> > This gives me Option 1 with "-cpu host" and Option 2 without.
> 
> This looks like an emulation bug. The interesting thing is that your
> both traces from the bugzilla point to generic_make_request_checks
> but
> it could also be due to timing.
> 
> Decoding the instruction stream in the second trace in the bugzilla
> gives:
> 
> [ 278.595106] Code: 03 48 89 03 48 8b 57 70 48 89 53 10 48 2b 01 8b
> 3f 48 89 45 98 48 8b 82 90 00 00 00 89 7d 94 48 8b 80 60 02 00 00 48
> 89 45 88 ac <17> 00 00 c8 45 85 e4 74 30 48 8b 43 10 48 8b 40 08 48
> 8b 40 48
> All code
> ========
>    0:   03 48 89                add    -0x77(%rax),%ecx
>    3:   03 48 8b                add    -0x75(%rax),%ecx
>    6:   57                      push   %rdi
>    7:   70 48                   jo     0x51
>    9:   89 53 10                mov    %edx,0x10(%rbx)
>    c:   48 2b 01                sub    (%rcx),%rax
>    f:   8b 3f                   mov    (%rdi),%edi
>   11:   48 89 45 98             mov    %rax,-0x68(%rbp)
>   15:   48 8b 82 90 00 00 00    mov    0x90(%rdx),%rax
>   1c:   89 7d 94                mov    %edi,-0x6c(%rbp)
>   1f:   48 8b 80 60 02 00 00    mov    0x260(%rax),%rax
>   26:   48 89 45 88             mov    %rax,-0x78(%rbp)
>   2a:   ac                      lods   %ds:(%rsi),%al
>   2b:*  17                      (bad)       <-- trapping instruction
>   2c:   00 00                   add    %al,(%rax)
>   2e:   c8 45 85 e4             enterq $0x8545,$0xe4
>   32:   74 30                   je     0x64
>   34:   48 8b 43 10             mov    0x10(%rbx),%rax
>   38:   48 8b 40 08             mov    0x8(%rax),%rax
>   3c:   48 8b 40 48             mov    0x48(%rax),%rax
>         ...
> 
> Code starting with the faulting instruction
> ===========================================
>    0:   17                      (bad)
>    1:   00 00                   add    %al,(%rax)
>    3:   c8 45 85 e4             enterq $0x8545,$0xe4
>    7:   74 30                   je     0x39
>    9:   48 8b 43 10             mov    0x10(%rbx),%rax
>    d:   48 8b 40 08             mov    0x8(%rax),%rax
>   11:   48 8b 40 48             mov    0x48(%rax),%rax
> 
> 
> and an instruction with opcode 0x17 in 64-bit mode is, AFAICT,
> invalid (on 32-bit it is "pop %ss" according to this thing:
> http://www.onlinedisassembler.com).

I can provide you with more different traces if it can help. But I thought that maybe it will be more useful for you to try it on your own. So I've prepared some minimal debian installation which you could download here (apx 163M bzipped):

http://fi.muni.cz/~xracek/debian.img.bz2

Password:
root/asdfgh

Here is my config for guest kernel:

http://fi.muni.cz/~xracek/config

I use

qemu-kvm -m 1500 -hda debian.img -kernel linux/arch/x86/boot/bzImage -append "root=/dev/sda1"

After logging in just run "sh runtest.sh". This leads to crash in my case (host: Intel Core i5-2540M, kernel 3.5.2-1.fc17.x86_64, qemu 1.0.1).

Regards,

Tom

> 
> --
> Regards/Gruss,
>     Boris.
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/