On Wed, Mar 07, 2012 at 07:53:16PM +0900, Fernando Luis Vázquez Cao wrote: > On 03/01/2012 08:19 AM, Eric W. Biederman wrote: > > >Don Zickus<[email protected]> writes: > >>It probably is, except I never hacked on idt code before and my assembly > >>isn't that good. I have been trying to find examples to copy from to give > >>it a try. So far I was using early_idt_handlers with early_printk to see > >>if I could capture some printk messages while jumping from the first > >>kernel to the second kernel (when the other early_idt_handlers would kick > >>in for the second kernel). > >> > >>Tips? Better examples? > >That is a particularly good example. When I took a quick look earlier > >that is the first place we reload the idt in the kernel boot so that is > >one of two places that needs to be modified. > > Hi Eric, Don > > Sorry for chiming in so late. > > We run into the same NMI problems and wrote some patches that tackle > the kernel boot side of things. They have been extensively tested using > qemu-kvm and things seem to be working as expected (after receiving an > early NMI the kernel continues without problem; after the iret there is no > stack corruption or register corruption).
What happens if NMI happens while we are still in purgatory code? Thanks Vivek _______________________________________________ kexec mailing list [email protected] http://lists.infradead.org/mailman/listinfo/kexec
