Re: [Xen-devel] [PATCH 0 of 1] Kexec alteration

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 06/12/12 15:56, Andrew Cooper wrote:
> Hello,
>
> Fixing the root reentrant NMI/MCE issues is quickly turning into a
> substantially larger problem than initially thought.
>
> As a result, I have decided to submit the fixes in smaller chunks, in
> the hope that they are reviewed and integrated separately.  The first
> part is changes to the kexec path, from which I am now happy to drop the
> RFC tag.
>
> Please scrutinise carefully.
>
>
> The vague decided plan going forwards is:
>
>  * Implement spin_{un,}lock_recursive_irq{save,restore}()
>  * Audit users of mixed regular/recursive calls on the same spinlock
>  * Swap recursive spinlocks to be a separate type
>  * Fix the semantics of console_force_unlock
* Fix ASSERT() and BUG() to be NMI/MCE safe wrt console
>  * Continue audit of NMI and MCE paths, with console semantics fixed
>  * {Panic,NMI,MCE}-in-progress flags & reentrancy protection
>  * Ability to specify whether iret should be used on trap exit
>  * Implement "MCEs never iret, NMIs always iret" policy
>
> The plan for "things I think needs to happen" is:
>  * Extend spinlock debugging to know about NMI and MCE contexts
>  * Implement strict ordering constraints for spinlock debugging
>
> The "other things needing investigating" list includes:
>  * Interaction of paging changes and IDTs while purgatory is changing
>    processor modes
>
> ~Andrew

-- 
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com


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