[Xen-changelog] [xen master] x86/traps: make the main trap handlers safe for use early during Xen boot

[patchbot@xxxxxxx]

commit d4f88fc5d63cdccef668d6490190318364e2472a
Author:     Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
AuthorDate: Fri May 16 17:37:18 2014 +0200
Commit:     Jan Beulich <jbeulich@xxxxxxxx>
CommitDate: Fri May 16 17:37:18 2014 +0200

    x86/traps: make the main trap handlers safe for use early during Xen boot
    
    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 preceded 
with
    a system_state check, so in the exceedingly unlikely case that Xen takes an
    x87/SIMD 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 complicated codepath, but appears safe.  For the possible
    injection of NMIs into dom0 there is a NULL domain pointer check.  The
    possible softirq raised for PCI SERR will be delivered 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@xxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
---
 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 46cb48e..fcd5b00 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);
--
generated by git-patchbot for /home/xen/git/xen.git#master

_______________________________________________
Xen-changelog mailing list
Xen-changelog@xxxxxxxxxxxxx
http://lists.xensource.com/xen-changelog