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

[ebiederm@xmission.com (Eric W. Biederman)]

Neil Horman <nhorman@redhat.com> writes:

>> 
>> ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1

Ben, what chipset is this?

>
> Ok, I think from what I understand of what we're reading here, the apic2 = -1
> and pin2 = -1 indicate that the 8259 has no direct connection to any cpu, which
> means that on shutdown disable_IO_APIC should take us into virtual wire mode.
> As such enabling the APIC early in boot should fix us, but more consisely,
> rewriting the entry in the IOAPIC to deliver int0 to the only running cpu should
> accomplish the same goal for this problem.  Does that sound reasonable (at least
> as a test to ensure we understand the problem) to everyone?

Close.  There are two options with virtual wire mode.  
- Either the local apic is in virtual wire mode, and somehow the
  legacy interrupts make it to the local cpu.
- Or an ioapic is in virtual wire mode and the legacy interrupt
  controller is connected to it.

So I guess fundamentally for any SMP system that only supports the
cpu being in local apic mode and only routes interrupts to the boot
strap processor we could be in trouble.  That is what our current
information about your system suggests.

However most systems actually connect the i8254 PIC interrupt
controller to the ioapic in virtual wire mode.  As I recall the
standard mapping is to ioapic 0, pin 0.  With ioapic 0, pin 2 being
the timer interrupt (Possibly it is the other way around).

So as a test we could feed those values into ioapic_8259 and see
if the kdump case works.  I believe we prefer putting the ioapic
into virtual wire mode over putting the cpu into virtual wire
mode.  We can only control which cpu receives the legacy interrupts if
we are putting the ioapic in virtual wire mode.

It may also be an interesting test to just enable the timer for the
ioapic in early boot, as you have suggested.  I don't have a clue what
that will do.

Eric