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.
next prev parent 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).