xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Xen-devel <xen-devel@lists.xen.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Keir Fraser <keir@xen.org>, Jan Beulich <JBeulich@suse.com>,
	Tim Deegan <tim@xen.org>
Subject: [PATCH RFC 3/9] x86/traps: Make the main trap handlers safe for use early during Xen boot
Date: Thu, 15 May 2014 10:48:13 +0100	[thread overview]
Message-ID: <1400147299-31772-4-git-send-email-andrew.cooper3@citrix.com> (raw)
In-Reply-To: <1400147299-31772-1-git-send-email-andrew.cooper3@citrix.com>

Most of this patch is an analysis of the safety of the trap handlers.

Traps 0, 4, 5, 9-12, 16, 17 and 19 all end up in do_trap().  do_trap() is
mostly safe, performing an exception table search and possibly panic()s.

There is one complication with traps 16 and 19 which will see about calling
the fpu_exception_callback.  This involves following current which is not
valid early on boot.  The has_hvm_container_vcpu(curr) check is preceeded with
a system_state check, so in the exceedingly unlikely case that Xen takes an
x87/SIMP trap while booting, it will panic() instead of following a bogus
current vcpu.

Traps 1, 3, 6-8, 13 and 15 are completely safe with respect to running during
early boot.  They all have well formed and obvious differences between faults
in Xen and faults in guests, with the Xen faults doing little more than
exception table walks or panic()s.

Trap 2 is a complicted codepath, but appears safe.  For the possible injection
of NMIs into dom0 there is a NULL domian pointer check.  The possible softirq
raised for PCI SERR will be devered until we start the idle vcpu, but is safe.

Trap 14 is very complicated.  The code is certainly unsafe for boot as
fixup_page_fault() will dereference current to find the running domain.  There
exists an explicit do_early_page_fault() handler which shall continue to be
used.

Trap 18 has a default handler before the MCE infrastructure is set up, which
has always been unsafe and liable to deadlock itself with the console lock.
As it is expected never to trigger, and if it did we would be in serious
problems, the simple printk() is replaced with a fatal error path.

Trap 20 (Virtualisation Exception) is currently not implemented.  It is fatal
one way or another, and will become more explicitly so with later changes.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Keir Fraser <keir@xen.org>
CC: Jan Beulich <JBeulich@suse.com>
CC: Tim Deegan <tim@xen.org>
---
 xen/arch/x86/cpu/mcheck/mce.c |    5 +++--
 xen/arch/x86/traps.c          |    3 ++-
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
index a81952c..5488411 100644
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -72,8 +72,9 @@ custom_param("mce_verbosity", mce_set_verbosity);
 /* Handle unconfigured int18 (should never happen) */
 static void unexpected_machine_check(struct cpu_user_regs *regs, long error_code)
 {
-    printk(XENLOG_ERR "CPU#%d: Unexpected int18 (Machine Check).\n",
-           smp_processor_id());
+    console_force_unlock();
+    printk("Unexpected Machine Check Exception");
+    fatal_trap(TRAP_machine_check, regs);
 }
 
 
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 1de70af..65e4609 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -561,7 +561,8 @@ static void do_trap(struct cpu_user_regs *regs, int use_error_code)
     }
 
     if ( ((trapnr == TRAP_copro_error) || (trapnr == TRAP_simd_error)) &&
-         has_hvm_container_vcpu(curr) && curr->arch.hvm_vcpu.fpu_exception_callback )
+         system_state >= SYS_STATE_active && has_hvm_container_vcpu(curr) &&
+         curr->arch.hvm_vcpu.fpu_exception_callback )
     {
         curr->arch.hvm_vcpu.fpu_exception_callback(
             curr->arch.hvm_vcpu.fpu_exception_callback_arg, regs);
-- 
1.7.10.4

  parent reply	other threads:[~2014-05-15  9:48 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-15  9:48 [PATCH RFC 0/9] x86: Improvements to trap handling Andrew Cooper
2014-05-15  9:48 ` [PATCH RFC 1/9] x86/traps: Names for system descriptor types Andrew Cooper
2014-05-15  9:56   ` Andrew Cooper
2014-05-15 10:08   ` Jan Beulich
2014-05-15 10:26     ` Andrew Cooper
2014-05-15 12:10       ` Jan Beulich
2014-05-15  9:48 ` [PATCH RFC 2/9] x86/traps: Make panic and reboot paths safe during early boot Andrew Cooper
2014-05-15 10:19   ` Jan Beulich
2014-05-15 10:53     ` Andrew Cooper
2014-05-15 12:12       ` Jan Beulich
2014-05-15 15:46         ` Andrew Cooper
2014-05-15 15:59           ` Jan Beulich
2014-05-15  9:48 ` Andrew Cooper [this message]
2014-05-15 10:20   ` [PATCH RFC 3/9] x86/traps: Make the main trap handlers safe for use early during Xen boot Jan Beulich
2014-05-15  9:48 ` [PATCH RFC 4/9] x86/misc: Early cleanup Andrew Cooper
2014-05-15 10:32   ` Jan Beulich
2014-05-15 10:38     ` Andrew Cooper
2014-05-15  9:48 ` [PATCH RFC 5/9] x86/traps: Functional prep work Andrew Cooper
2014-05-15 10:36   ` Jan Beulich
2014-05-15 10:45     ` Andrew Cooper
2014-05-15 12:15       ` Jan Beulich
2014-05-15 12:42         ` Andrew Cooper
2014-05-15  9:48 ` [PATCH RFC 6/9] x86/boot: Install trap handlers much earlier on boot Andrew Cooper
2014-05-15 10:53   ` Jan Beulich
2014-05-15 11:05     ` Andrew Cooper
2014-05-15 12:21       ` Jan Beulich
2014-05-15  9:48 ` [PATCH RFC 7/9] x86/boot: Drop pre-C IDT patching Andrew Cooper
2014-05-15  9:48 ` [PATCH RFC 8/9] x86/irqs: Move interrupt-stub generation out of C Andrew Cooper
2014-05-15 13:06   ` Jan Beulich
2014-05-15  9:48 ` [PATCH RFC 9/9] x86/misc: Post cleanup Andrew Cooper
2014-05-15 13:14   ` Jan Beulich
2014-05-15 13:17     ` Andrew Cooper
2014-05-16  8:49 ` [PATCH RFC 0/9] x86: Improvements to trap handling Wu, Feng

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=1400147299-31772-4-git-send-email-andrew.cooper3@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=keir@xen.org \
    --cc=tim@xen.org \
    --cc=xen-devel@lists.xen.org \
    /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).