2012/3/7 Vivek Goyal <vgoyal at redhat.com>: > 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<dzickus at redhat.com> ?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? > yes, you are right. that is too late to set that in arch/x86/kernel/head64.c i even not get print out "early console in decompress_kernel" from arch/x86/boot/compressed/misc.c::decompress_kernel() Yinghai
