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]

Date:	Fri, 30 Nov 2007 09:42:50 -0500
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Ben Woodard <woodard@...hat.com>
Cc:	Neil Horman <nhorman@...hat.com>, Andi Kleen <andi@...stfloor.org>,
	kexec@...ts.infradead.org, linux-kernel@...r.kernel.org,
	Andi Kleen <ak@...e.de>, hbabu@...ibm.com,
	"Eric W. Biederman" <ebiederm@...ssion.com>
Subject: Re: [PATCH] kexec: force x86_64 arches to boot kdump kernels on
	boot cpu

[..]
>> Can you print the LAPIC registers (print_local_APIC) during normal boot
>> and during kdump boot and paste here?
>
> Here are the ones from a normal bootup.
>
> I was unable to get info from a kdump boot. I haven't figured out why yet. 
> With the same patch that I used to capture this, when I tried to kdump the 
> kernel, it paused a second or two after the backtrace and then dropped to 
> BIOS and came up normally.
>
> Here is a little trick, at the point where we are trying to get the info to 
> print out, the kernel command line hasn't been completely parsed yet. That 
> tricked me for part of the day. I had apic=debug on the command line but 
> the logic in print_local_APIC saw the default value because the kernel 
> command line had yet to be parsed.
>
> 2007-11-29 17:58:07 ***Here is the info you requested
> 2007-11-29 17:58:07
> 2007-11-29 17:58:07 printing local APIC contents on CPU#0/0:
> 2007-11-29 17:58:07 ... APIC ID:      00000000 (0)
> 2007-11-29 17:58:07 ... APIC VERSION: 80050010
> 2007-11-29 17:58:07 ... APIC TASKPRI: 00000000 (00)
> 2007-11-29 17:58:07 ... APIC ARBPRI: 00000000 (00)
> 2007-11-29 17:58:07 ... APIC PROCPRI: 00000000
> 2007-11-29 17:58:07 ... APIC EOI: 00000000
> 2007-11-29 17:58:07 ... APIC RRR: 00000002
> 2007-11-29 17:58:07 ... APIC LDR: 00000000
> 2007-11-29 17:58:07 ... APIC DFR: ffffffff
> 2007-11-29 17:58:07 ... APIC SPIV: 0000010f
> 2007-11-29 17:58:07 ... APIC ISR field:
> 2007-11-29 17:58:07 ... APIC TMR field:
> 2007-11-29 17:58:07 ... APIC IRR field:
> 2007-11-29 17:58:07 ... APIC ESR: 00000000
> 2007-11-29 17:58:07 ... APIC ICR: 00004630
> 2007-11-29 17:58:07 ... APIC ICR2: 07000000
> 2007-11-29 17:58:07 ... APIC LVTT: 00010000
> 2007-11-29 17:58:07 ... APIC LVTPC: 00010000
> 2007-11-29 17:58:07 ... APIC LVT0: 00000700

Ok so here boot cpu LVT0 has been set to deliver any interrupt on pin
LINT0 as ExtInt. We do the same thing for kdump cpu local apic too.

I am not sure who is the guy in system who encodes the interrupt message
from 8259 to be put on hypertransport and on what basis do they decide
whether it should go to only cpu0 or a broadcast one. Looks like in this
case it is going to cpu0 only. That means we are left with no choice but
to work on patch to initialize IOAPIC early.

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