Re: [Xen-devel] Audit of NMI and MCE paths

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 04.12.12 at 21:04, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
> As an alternative, I suggest that we make ASSERT()s, BUG()s and WARN()s
> NMI/MCE safe, from a printk spinlock point of view.
> 
> Either we can modify the macros to do a console_force_unlock(), which is
> fine for BUG() and ASSERT(), but problematic for WARN() (and deferring
> the printing to a tasklet wont work if we want a stack trace). 
> Alternativly, we could change the console lock to be a recursive lock,
> at which point it is safe from the deadlock point of view.  Are there
> any performance concerns from changing to a recursive lock?

Not really, and the console lock isn't performance critical anyway.

> As for spinlocks themselves, as far as I can reason, recursive locks are
> safe to use, as are per-cpu spinlocks which are used exclusivly in the
> NMI handler or MCE handler (but not both), given the proviso that we
> have C level reentrance protection for do_{nmi,mce}().
> 
> For the {rd,wr}msr()s, we can assume that the Xen code is good and is
> not going to fault on access to the MSR, but we certainly cant guarantee
> this.

{rd,wr}msr() are of no concern - if they fault it's exactly like a #PF
or #GP from a bad memory reference: a bug that will bring down the
hypervisor. Their _safe counterparts are what needs to be looked
for, as there the fault is being recovered from (and it's this recovery's
side effect of re-enabling NMIs that we don't want).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel