From: Keir Fraser <keir@xen.org>
To: Rafal Wojtczuk <rafal@invisiblethingslab.com>,
xen-devel@lists.xensource.com
Subject: Re: Bug: Xen panics with #UD in acpi_processor_idle()
Date: Mon, 22 Nov 2010 15:15:03 +0000 [thread overview]
Message-ID: <C9103978.AC86%keir@xen.org> (raw)
In-Reply-To: <20101122130207.GD11110@email>
[-- Attachment #1: Type: text/plain, Size: 4769 bytes --]
On 22/11/2010 13:02, "Rafal Wojtczuk" <rafal@invisiblethingslab.com> wrote:
> Hello,
>
> There seems to be an issue with handling of
> MSR_IA32_MISC_ENABLE_MONITOR_ENABLE bit in MSR_IA32_MISC_ENABLE. The effect
> is that Xen panics because of #UD after trying to execute "monitor"
> instruction. Most likely Xen does not bother to set this bit, leaving
> it to BIOS. If I understand correctly, it is mere reliability issue, not
> triggerable from any domain.
The issue appears to be be that we do not check for MWAIT support in CPUID,
same as native Linux would do (the flag in MISC_ENABLE MSR also affects
CPUID appropriately). Can you please try the attached patch? If it works I
will apply it to all our trees.
Thanks,
Keir
> The problem can be reproduced with Xen-4.0.1 or tip of xen-4.0-testing.hg,
> dom0 being 2.6.32.23-170.xendom0.fc12.x86_64 taken from
> http://fedorapeople.org/~myoung/dom0. Processor is i5-650 on Intel Q57.
> Panic happens just after starting dom0.
> I have verified (by adding rdmsr(MSR_IA32_MISC_ENABLE) in the panic code)
> that indeed MSR_IA32_MISC_ENABLE_MONITOR_ENABLE is not set (it is 810088).
> The same value is present in the msr when in init_done() function.
> If I hardcode setting this bit just before __monitor(), all is fine. So it
> looks like my crappy BIOS has not set this bit, and Xen has not either, yet
> it tried to use monitor/mwait ?
>
> Somehow offtopic: what is the purpose of cheating about
> MSR_IA32_MISC_ENABLE_MONITOR_ENABLE state to dom0 in rdmsr emulation ?
> xen-4.0-testing.hg/xen/arch/x86/traps.c:2364
> case MSR_IA32_MISC_ENABLE:
> if ( rdmsr_safe(regs->ecx, regs->eax, regs->edx) )
> goto fail;
> regs->eax &= ~(MSR_IA32_MISC_ENABLE_PERF_AVAIL |
> MSR_IA32_MISC_ENABLE_MONITOR_ENABLE);
> regs->eax |= MSR_IA32_MISC_ENABLE_BTS_UNAVAIL |
> MSR_IA32_MISC_ENABLE_PEBS_UNAVAIL |
> MSR_IA32_MISC_ENABLE_XTPR_DISABLE;
> break;
>
> Regards,
> Rafal Wojtczuk
>
> (XEN) ----[ Xen-4.0.2-rc1-pre x86_64 debug=n Not tainted ]----
> (XEN) CPU: 0
> (XEN) RIP: e008:[<ffff82c48018db7f>] acpi_processor_idle+0x3cf/0x810
> (XEN) RFLAGS: 0000000000010086 CONTEXT: hypervisor
> (XEN) rax: ffff8300cacfc000 rbx: ffff830121634840 rcx: 0000000000000000
> (XEN) rdx: 0000000000000000 rsi: 0000000000000020 rdi: 0000000000000000
> (XEN) rbp: ffff830121634900 rsp: ffff82c480367e80 r8: 000000020bc8ef41
> (XEN) r9: 0000000000000004 r10: ffff82c480397120 r11: 0000000000000001
> (XEN) r12: 00000000000000c0 r13: 0000000000f977e3 r14: ffff8300cacfc000
> (XEN) r15: 0000000000000002 cr0: 000000008005003b cr4: 00000000000026f0
> (XEN) cr3: 0000000119001000 cr2: ffff880000736860
> (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: e010 cs: e008
> (XEN) Xen stack trace from rsp=ffff82c480367e80:
> (XEN) ffffffffffffffff ffff82c48025f100 ffff82c48011f537 ffff8300cacfc000
> (XEN) ffffffffffffffff ffffffff817db6b0 0000000000000000 0000000000000000
> (XEN) 000000008037a980 000003c7000003c7 ffff82c48037e980 ffff82c480367f28
> (XEN) ffff82c48025fb00 ffff82c480367f28 ffff82c480367e18 ffff8300cacfc000
> (XEN) 0000000000000002 ffff82c48014f02e ffff8300cacfc000 ffff8300cb4f8000
> (XEN) 00000000ffffffff 0000000000000000 ffffffffffffffff 0000000000000000
> (XEN) ffffffff817db6b0 ffffffff81683f10 ffffffff81682000 0000000000000246
> (XEN) 0000000000015740 ffff8800077e6160 0000000000000000 0000000000000000
> (XEN) ffffffff810093aa 0000000000000246 0000000000000000 0000000000000001
> (XEN) 0000010000000000 ffffffff810093aa 000000000000e033 0000000000000246
> (XEN) ffffffff81683ef8 000000000000e02b 0000000000000000 0000000000000000
> (XEN) 0000000000000000 0000000000000000 0000000000000000 ffff8300cacfc000
> (XEN) Xen call trace:
> (XEN) [<ffff82c48018db7f>] acpi_processor_idle+0x3cf/0x810
> (XEN) [<ffff82c48011f537>] timer_softirq_action+0x227/0x370
> (XEN) [<ffff82c48014f02e>] idle_loop+0x2e/0x90
> (XEN)
> (XEN)
> (XEN) ****************************************
> (XEN) Panic on CPU 0:
> (XEN) FATAL TRAP: vector = 6 (invalid opcode)
> (XEN) ****************************************
> (XEN)
> (XEN) Reboot in five seconds...
>
> [root@f13q45 xen]# gdb xen-syms
> Reading symbols from /root/xen/xen-4.0-testing.hg/xen/xen-syms...done.
> (gdb) x/2i 0xffff82c48018db7f
> 0xffff82c48018db7f <acpi_processor_idle+975>: monitor %rax,%rcx,%rdx
> 0xffff82c48018db82 <acpi_processor_idle+978>: mfence
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
[-- Attachment #2: 00-mwait --]
[-- Type: application/octet-stream, Size: 609 bytes --]
diff -r e9156d9d996b xen/arch/x86/acpi/cpu_idle.c
--- a/xen/arch/x86/acpi/cpu_idle.c Tue Nov 16 11:54:48 2010 +0000
+++ b/xen/arch/x86/acpi/cpu_idle.c Mon Nov 22 15:12:15 2010 +0000
@@ -717,7 +717,8 @@
{
case ACPI_ADR_SPACE_FIXED_HARDWARE:
if ( xen_cx->reg.bit_width == VENDOR_INTEL &&
- xen_cx->reg.bit_offset == NATIVE_CSTATE_BEYOND_HALT )
+ xen_cx->reg.bit_offset == NATIVE_CSTATE_BEYOND_HALT &&
+ boot_cpu_has(X86_FEATURE_MWAIT) )
cx->entry_method = ACPI_CSTATE_EM_FFH;
else
cx->entry_method = ACPI_CSTATE_EM_HALT;
[-- Attachment #3: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
next prev parent reply other threads:[~2010-11-22 15:15 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-22 13:02 Bug: Xen panics with #UD in acpi_processor_idle() Rafal Wojtczuk
2010-11-22 14:04 ` Jan Beulich
2010-11-22 15:15 ` Keir Fraser [this message]
2010-11-22 15:43 ` Rafal Wojtczuk
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=C9103978.AC86%keir@xen.org \
--to=keir@xen.org \
--cc=rafal@invisiblethingslab.com \
--cc=xen-devel@lists.xensource.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).