linux-kernel - Re: [PATCH] kexec: force x86_64 arches to boot kdump kernels on boot cpu

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200711271543.11809.ak@suse.de>
Date:	Tue, 27 Nov 2007 15:43:11 +0100
From:	Andi Kleen <ak@...e.de>
To:	Neil Horman <nhorman@...driver.com>
Cc:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Neil Horman <nhorman@...hat.com>, hbabu@...ibm.com,
	vgoyal@...ibm.com, kexec@...ts.infradead.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] kexec: force x86_64 arches to boot kdump kernels on boot cpu

> 
> As for solution 2, that brings me to my previous question.  Is that really as
> simple as just not moving the apic to legacy mode?  It would seem some
> additional programming would be in order to route the interrupt in question to
> the proper cpu.

The Linux kernel right now relies on being in legacy mode at bootup.
So obviously kexec has to switch back to that.

Not relying on legacy mode would require moving APIC setup much earlier which
is difficult because that's quite fragile. Longer term it might be a good
idea though anyways -- at least the timer code was always fragile
and eliminating one failure case and only ever running it in true
APIC mode would be probably a good thing.

-Andi

-
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/