[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-changelog] [xen-4.0-testing] x86/IO-APIC: refine EOI-ing of migrating level interrupts
# HG changeset patch # User Jan Beulich <jbeulich@xxxxxxxx> # Date 1331110232 0 # Node ID 17992e40806abbc796f1d11722a63e682200d63e # Parent bf902d6661e36a7bd779d7e2501fa54cd698bfd4 x86/IO-APIC: refine EOI-ing of migrating level interrupts Rather than going through all IO-APICs and calling io_apic_eoi_vector() for the vector in question, just use eoi_IO_APIC_irq(). This in turn allows to eliminate quite a bit of other code. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> Tested-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx> xen-unstable changeset: 24155:0d50e704834f xen-unstable date: Fri Nov 18 09:18:41 2011 +0100 --- diff -r bf902d6661e3 -r 17992e40806a xen/arch/x86/io_apic.c --- a/xen/arch/x86/io_apic.c Thu Feb 23 10:41:33 2012 +0000 +++ b/xen/arch/x86/io_apic.c Wed Mar 07 08:50:32 2012 +0000 @@ -73,10 +73,6 @@ #define ioapic_has_eoi_reg(apic) (mp_ioapics[(apic)].mpc_apicver >= 0x20) -#define io_apic_eoi_vector(apic, vector) io_apic_eoi((apic), (vector), -1) -#define io_apic_eoi_pin(apic, pin) io_apic_eoi((apic), -1, (pin)) - - /* * This is performance-critical, we want to do it O(1) * @@ -212,16 +208,13 @@ spin_unlock_irqrestore(&ioapic_lock, flags); } -/* EOI an IO-APIC entry. One of vector or pin may be -1, indicating that - * it should be worked out using the other. This function expect that the - * ioapic_lock is taken, and interrupts are disabled (or there is a good reason - * not to), and that if both pin and vector are passed, that they refer to the +/* EOI an IO-APIC entry. Vector may be -1, indicating that it should be + * worked out using the pin. This function expects that the ioapic_lock is + * being held, and interrupts are disabled (or there is a good reason not + * to), and that if both pin and vector are passed, that they refer to the * same redirection entry in the IO-APIC. */ static void __io_apic_eoi(unsigned int apic, unsigned int vector, unsigned int pin) { - /* Ensure some useful information is passed in */ - BUG_ON( (vector == -1 && pin == -1) ); - /* Prefer the use of the EOI register if available */ if ( ioapic_has_eoi_reg(apic) ) { @@ -238,42 +231,6 @@ struct IO_APIC_route_entry entry; bool_t need_to_unmask = 0; - /* If pin is unknown, search for it */ - if ( pin == -1 ) - { - unsigned int p; - for ( p = 0; p < nr_ioapic_registers[apic]; ++p ) - { - entry = __ioapic_read_entry(apic, p, TRUE); - if ( entry.vector == vector ) - { - pin = p; - /* break; */ - - /* Here should be a break out of the loop, but at the - * Xen code doesn't actually prevent multiple IO-APIC - * entries being assigned the same vector, so EOI all - * pins which have the correct vector. - * - * Remove the following code when the above assertion - * is fulfilled. */ - __io_apic_eoi(apic, vector, p); - } - } - - /* If search fails, nothing to do */ - - /* if ( pin == -1 ) */ - - /* Because the loop wasn't broken out of (see comment above), - * all relevant pins have been EOI, so we can always return. - * - * Re-instate the if statement above when the Xen logic has been - * fixed.*/ - - return; - } - entry = __ioapic_read_entry(apic, pin, TRUE); if ( ! entry.mask ) @@ -300,17 +257,6 @@ } } -/* EOI an IO-APIC entry. One of vector or pin may be -1, indicating that - * it should be worked out using the other. This function disables interrupts - * and takes the ioapic_lock */ -static void io_apic_eoi(unsigned int apic, unsigned int vector, unsigned int pin) -{ - unsigned int flags; - spin_lock_irqsave(&ioapic_lock, flags); - __io_apic_eoi(apic, vector, pin); - spin_unlock_irqrestore(&ioapic_lock, flags); -} - /* * Saves all the IO-APIC RTE's */ @@ -1808,11 +1754,7 @@ /* Manually EOI the old vector if we are moving to the new */ if ( vector && i != vector ) - { - int ioapic; - for (ioapic = 0; ioapic < nr_ioapics; ioapic++) - io_apic_eoi_vector(ioapic, i); - } + eoi_IO_APIC_irq(irq); v = apic_read(APIC_TMR + ((i & ~0x1f) >> 1)); _______________________________________________ Xen-changelog mailing list Xen-changelog@xxxxxxxxxxxxx http://lists.xensource.com/xen-changelog
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |