linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: Tomas Racek <tracek@redhat.com>
Cc: Anthony Liguori <anthony@codemonkey.ws>,
	qemu-devel@nongnu.org, "H. Peter Anvin" <hpa@linux.intel.com>,
	linux-kernel@vger.kernel.org, Alan Cox <alan@linux.intel.com>,
	kvm-devel <kvm@vger.kernel.org>, Avi Kivity <avi@redhat.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: [Qemu-devel] x86, nops settings result in kernel crash
Date: Fri, 17 Aug 2012 10:09:56 +0200	[thread overview]
Message-ID: <20120817080956.GC24241@liondog.tnic> (raw)
In-Reply-To: <579203853.1924367.1345189436257.JavaMail.root@redhat.com>

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).

-- 
Regards/Gruss,
    Boris.

  reply	other threads:[~2012-08-17  8:10 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1104118228.1760802.1345121009530.JavaMail.root@redhat.com>
2012-08-16 13:35 ` x86, nops settings result in kernel crash Tomas Racek
2012-08-16 13:48   ` Borislav Petkov
2012-08-16 18:45     ` Tomas Racek
2012-08-16 18:53       ` Alan Cox
2012-08-16 21:30         ` H. Peter Anvin
2012-08-17  7:42           ` Tomas Racek
2012-08-16 21:51         ` [Qemu-devel] " Anthony Liguori
2012-08-17  7:43           ` Tomas Racek
2012-08-17  8:09             ` Borislav Petkov [this message]
2012-08-20 17:13               ` Tomas Racek
2012-08-21  7:22                 ` Michael Tokarev
2012-08-21  9:28                   ` Tomas Racek
2012-08-22  9:54                     ` Avi Kivity
2012-08-22 10:03                       ` [PATCH] x86, alternative: fix p6 nops on non-modular kernels Avi Kivity
2012-08-22 10:21                         ` [tip:x86/urgent] x86/alternatives: Fix " tip-bot for Avi Kivity
2012-08-22 10:33                         ` [PATCH] x86, alternative: fix " Tomas Racek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120817080956.GC24241@liondog.tnic \
    --to=bp@alien8.de \
    --cc=alan@linux.intel.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=anthony@codemonkey.ws \
    --cc=avi@redhat.com \
    --cc=borislav.petkov@amd.com \
    --cc=hpa@linux.intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=tracek@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).