Re: [PATCH RFC 3/9] x86/traps: Make the main trap handlers safe for use early during Xen boot

["Jan Beulich" <JBeulich@suse.com>]

>>> On 15.05.14 at 11:48, <andrew.cooper3@citrix.com> wrote:
> 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>

Reviewed-by: Jan Beulich <jbeulich@suse.com>