[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20120309.095902.310070570.d.hatayama@jp.fujitsu.com>
Date: Fri, 09 Mar 2012 09:59:02 +0900 ( )
From: HATAYAMA Daisuke <d.hatayama@...fujitsu.com>
To: fernando@....ntt.co.jp
Cc: ebiederm@...ssion.com, dzickus@...hat.com,
linux-tip-commits@...r.kernel.org, torvalds@...ux-foundation.org,
kexec@...ts.infradead.org, linux-kernel@...r.kernel.org,
mingo@...hat.com, tglx@...utronix.de, hpa@...or.com, mingo@...e.hu,
yinghai@...nel.org, akpm@...ux-foundation.org, vgoyal@...hat.com
Subject: Re: [tip:x86/debug] x86/kdump: No need to disable ioapic/ lapic in
crash path
From: Fernando Luis Vázquez Cao <fernando@....ntt.co.jp>
Subject: Re: [tip:x86/debug] x86/kdump: No need to disable ioapic/ lapic in crash path
Date: Wed, 07 Mar 2012 19:53:16 +0900
> On 03/01/2012 08:19 AM, Eric W. Biederman wrote:
>
>> Don Zickus<dzickus@...hat.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).
>
> I will be replying to this email with the patches.
>
Should the following also be fixed?
/*
* Do not allocate memory (or fail in any way) in machine_kexec().
* We are past the point of no return, committed to rebooting now.
*/
void machine_kexec(struct kimage *image)
{
unsigned long page_list[PAGES_NR];
void *control_page;
int save_ftrace_enabled;
<cut>
/*
* The gdt & idt are now invalid.
* If you want to load them you must set up your own idt & gdt.
*/
set_gdt(phys_to_virt(0), 0);
set_idt(phys_to_virt(0), 0); <--- This
Thanks.
HATAYAMA, Daisuke
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists