• Konrad Rzeszutek Wilk's avatar
    xen/x86: Workaround 'x86/ioapic: Add register level checks to detect bogus io-apic entries' · 2531d64b
    Konrad Rzeszutek Wilk authored
    The above mentioned patch checks the IOAPIC and if it contains
    -1, then it unmaps said IOAPIC. But under Xen we get this:
    
    BUG: unable to handle kernel NULL pointer dereference at 0000000000000040
    IP: [<ffffffff8134e51f>] xen_irq_init+0x1f/0xb0
    PGD 0
    Oops: 0002 [#1] SMP
    CPU 0
    Modules linked in:
    
    Pid: 1, comm: swapper/0 Not tainted 3.2.10-3.fc16.x86_64 #1 Dell Inc. Inspiron
    1525                  /0U990C
    RIP: e030:[<ffffffff8134e51f>]  [<ffffffff8134e51f>] xen_irq_init+0x1f/0xb0
    RSP: e02b: ffff8800d42cbb70  EFLAGS: 00010202
    RAX: 0000000000000000 RBX: 00000000ffffffef RCX: 0000000000000001
    RDX: 0000000000000040 RSI: 00000000ffffffef RDI: 0000000000000001
    RBP: ffff8800d42cbb80 R08: ffff8800d6400000 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000000 R12: 00000000ffffffef
    R13: 0000000000000001 R14: 0000000000000001 R15: 0000000000000010
    FS:  0000000000000000(0000) GS:ffff8800df5fe000(0000) knlGS:0000000000000000
    CS:  e033 DS: 0000 ES: 0000 CR0:000000008005003b
    CR2: 0000000000000040 CR3: 0000000001a05000 CR4: 0000000000002660
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    Process swapper/0 (pid: 1, threadinfo ffff8800d42ca000, task ffff8800d42d0000)
    Stack:
     00000000ffffffef 0000000000000010 ffff8800d42cbbe0 ffffffff8134f157
     ffffffff8100a9b2 ffffffff8182ffd1 00000000000000a0 00000000829e7384
     0000000000000002 0000000000000010 00000000ffffffff 0000000000000000
    Call Trace:
     [<ffffffff8134f157>] xen_bind_pirq_gsi_to_irq+0x87/0x230
     [<ffffffff8100a9b2>] ? check_events+0x12+0x20
     [<ffffffff814bab42>] xen_register_pirq+0x82/0xe0
     [<ffffffff814bac1a>] xen_register_gsi.part.2+0x4a/0xd0
     [<ffffffff814bacc0>] acpi_register_gsi_xen+0x20/0x30
     [<ffffffff8103036f>] acpi_register_gsi+0xf/0x20
     [<ffffffff8131abdb>] acpi_pci_irq_enable+0x12e/0x202
     [<ffffffff814bc849>] pcibios_enable_device+0x39/0x40
     [<ffffffff812dc7ab>] do_pci_enable_device+0x4b/0x70
     [<ffffffff812dc878>] __pci_enable_device_flags+0xa8/0xf0
     [<ffffffff812dc8d3>] pci_enable_device+0x13/0x20
    
    The reason we are dying is b/c the call acpi_get_override_irq() is used,
    which returns the polarity and trigger for the IRQs. That function calls
    mp_find_ioapics to get the 'struct ioapic' structure - which along with the
    mp_irq[x] is used to figure out the default values and the polarity/trigger
    overrides. Since the mp_find_ioapics now returns -1 [b/c the IOAPIC is filled
    with 0xffffffff], the acpi_get_override_irq() stops trying to lookup in the
    mp_irq[x] the proper INT_SRV_OVR and we can't install the SCI interrupt.
    
    The proper fix for this is going in v3.5 and adds an x86_io_apic_ops
    struct so that platforms can override it. But for v3.4 lets carry this
    work-around. This patch does that by providing a slightly different variant
    of the fake IOAPIC entries.
    Signed-off-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    2531d64b
mmu.c 57.6 KB