• S
    x86, irq: Don't block IRQ0_VECTOR..IRQ15_VECTOR's on all cpu's · 97943390
    Suresh Siddha 提交于
    Currently IRQ0..IRQ15 are assigned to IRQ0_VECTOR..IRQ15_VECTOR's on
    all the cpu's.
    
    If these IRQ's are handled by legacy pic controller, then the kernel
    handles them only on cpu 0. So there is no need to block this vector
    space on all cpu's.
    
    Similarly if these IRQ's are handled by IO-APIC, then the IRQ affinity
    will determine on which cpu's we need allocate the vector resource for
    that particular IRQ. This can be done dynamically and here also there
    is no need to block 16 vectors for IRQ0..IRQ15 on all cpu's.
    
    Fix this by initially assigning IRQ0..IRQ15 to IRQ0_VECTOR..IRQ15_VECTOR's only
    on cpu 0. If the legacy controllers like pic handles these irq's, then
    this configuration will be fixed. If more modern controllers like IO-APIC
    handle these IRQ's, then we start with this configuration and as IRQ's
    migrate, vectors (/and cpu's) associated with these IRQ's change dynamically.
    
    This will freeup the block of 16 vectors on other cpu's which don't handle
    IRQ0..IRQ15, which can now be used for other IRQ's that the particular cpu
    handle.
    
    [ hpa: this also an architectural cleanup for future legacy-PIC-free
      configurations. ]
    [ hpa: fixed typo NR_LEGACY_IRQS -> NR_IRQS_LEGACY ]
    Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
    LKML-Reference: <1263932453.2814.52.camel@sbs-t61.sc.intel.com>
    Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
    97943390
vmiclock_32.c 8.9 KB