On 23/10/18 15:01, Jason Andryuk wrote: > On Tue, Oct 23, 2018 at 7:15 AM Andrew Cooper <[email protected]> > wrote: >> On 23/10/18 11:59, Sergey Dyasli wrote: >>> In certain scenarios, NMIs might be disabled during Xen boot process. >>> Such situation will cause alternative_instructions() to: >>> >>> panic("Timed out waiting for alternatives self-NMI to hit"); >>> >>> This bug was originally seen when using Tboot to boot Xen. >>> >>> To prevent this from happening, enable NMIs during cpu_init() and >>> during __start_xen() for BSP. >>> >>> Signed-off-by: Sergey Dyasli <[email protected]> >> Reviewed-by: Andrew Cooper <[email protected]> > FYI, Ross and Eric came up with a tboot patch recently added to OpenXT: > https://github.com/OpenXT/xenclient-oe/blob/master/recipes-openxt/tboot/tboot-1.9.6/0023-tboot-Unmask-NMI-potentially-masked-during-SENTER.patch > > Using this Xen patch with the tboot one reverted works too. > > Tested-by: Jason Andryuk <[email protected]>
:( Can bugs like this please be reported upstream? Given the observation of "Tboot hands off with NMIs disabled", the fix is very easy. On the subject of having NMIs disabled, it is definitely a more robust way of handing off between components. Until Xen has transitioned the BSP and APs into 64bit mode and fully set the IDT up, NMIs are fatal to the system. Furthermore, I've got some plans to suggest we do this on the kexec path as well. XenServer has one example where we crash from a GPU related error, and a slightly delayed NMI arrives, usually when we're in purgatory. ~Andrew _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
