Irrespective of the IO-APIC vector sharing suppression patch just sent
the logic in this function needs to iterate over all RTEs, since
multiple pins within an IO-APIC may still use the same vector. This is
due to the irq_2_pin[] mapping not necessarily being 1:1.
Consequently we should remove the commented out code as well as the
respective comments provisioned for the point in time when vector
sharing between unrelated RTEs would be disabled.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
--- a/xen/arch/x86/io_apic.c
+++ b/xen/arch/x86/io_apic.c
@@ -281,36 +281,15 @@ static void __io_apic_eoi(unsigned int a
/* If pin is unknown, search for it */
if ( pin == -1 )
{
- unsigned int p;
- for ( p = 0; p < nr_ioapic_entries[apic]; ++p )
+ for ( pin = 0; pin < nr_ioapic_entries[apic]; ++pin )
{
- entry = __ioapic_read_entry(apic, p, TRUE);
+ entry = __ioapic_read_entry(apic, pin, 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);
- }
+ __io_apic_eoi(apic, vector, pin);
}
/* 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;
}
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
On 11/11/11 16:07, Jan Beulich wrote:> Irrespective of the IO-APIC vector sharing suppression patch just sent > the logic in this function needs to iterate over all RTEs, since > multiple pins within an IO-APIC may still use the same vector.Why? The whole point of preventing vector sharing for IO-APICs is to prevent two or more RTEs referencing the same vector. ~Andrew> This is > due to the irq_2_pin[] mapping not necessarily being 1:1. > > Consequently we should remove the commented out code as well as the > respective comments provisioned for the point in time when vector > sharing between unrelated RTEs would be disabled. > > Signed-off-by: Jan Beulich <jbeulich@suse.com> > > --- a/xen/arch/x86/io_apic.c > +++ b/xen/arch/x86/io_apic.c > @@ -281,36 +281,15 @@ static void __io_apic_eoi(unsigned int a > /* If pin is unknown, search for it */ > if ( pin == -1 ) > { > - unsigned int p; > - for ( p = 0; p < nr_ioapic_entries[apic]; ++p ) > + for ( pin = 0; pin < nr_ioapic_entries[apic]; ++pin ) > { > - entry = __ioapic_read_entry(apic, p, TRUE); > + entry = __ioapic_read_entry(apic, pin, 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); > - } > + __io_apic_eoi(apic, vector, pin); > } > > /* 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; > } > > > >-- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>> On 11.11.11 at 17:49, Andrew Cooper <andrew.cooper3@citrix.com> wrote: > On 11/11/11 16:07, Jan Beulich wrote: >> Irrespective of the IO-APIC vector sharing suppression patch just sent >> the logic in this function needs to iterate over all RTEs, since >> multiple pins within an IO-APIC may still use the same vector. > > Why? The whole point of preventing vector sharing for IO-APICs is to > prevent two or more RTEs referencing the same vector.If that was really the case on *all* systems, then we wouldn''t need the chains of IRQs hanging off irq_2_pin[] entries. Obviously there are or have been or could theoretically be systems that do make use of this. BUT again after some more thinking about this over the weekend (and after fixing the issue pointed out in the other response regarding the other patch) I think we can actually convert the function to behave the way you intended it to after dealing with the vector sharing issue: The call sites are then only __eoi_IO_APIC_irq() (which already traverses the chain from irq_2_pin[]) and clear_IO_APIC_pin() (which explicitly wants to deal with just a single (apic, pin) tuple, the uses in the timer interrupt related boot time code having been bogus in this respect even before your original change to the EOI logic, as they imply that no other (apic, pin) tuple also represents the timer IRQ). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 14/11/11 09:08, Jan Beulich wrote:>>>> On 11.11.11 at 17:49, Andrew Cooper <andrew.cooper3@citrix.com> wrote: >> On 11/11/11 16:07, Jan Beulich wrote: >>> Irrespective of the IO-APIC vector sharing suppression patch just sent >>> the logic in this function needs to iterate over all RTEs, since >>> multiple pins within an IO-APIC may still use the same vector. >> Why? The whole point of preventing vector sharing for IO-APICs is to >> prevent two or more RTEs referencing the same vector. > If that was really the case on *all* systems, then we wouldn''t need > the chains of IRQs hanging off irq_2_pin[] entries. Obviously there are > or have been or could theoretically be systems that do make use of this. > > BUT again after some more thinking about this over the weekend > (and after fixing the issue pointed out in the other response regarding > the other patch) I think we can actually convert the function to > behave the way you intended it to after dealing with the vector > sharing issue: The call sites are then only __eoi_IO_APIC_irq() (which > already traverses the chain from irq_2_pin[]) and clear_IO_APIC_pin() > (which explicitly wants to deal with just a single (apic, pin) tuple, the > uses in the timer interrupt related boot time code having been bogus in > this respect even before your original change to the EOI logic, as they > imply that no other (apic, pin) tuple also represents the timer IRQ). > > Jan >Ah yes. I was silly and had not considered that possibility. Realistically, I doubt there are many boxes still around which have shared ISA interrupts, but we should deal with the case. -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>> On 14.11.11 at 15:07, Andrew Cooper <andrew.cooper3@citrix.com> wrote:> > On 14/11/11 09:08, Jan Beulich wrote: >>>>> On 11.11.11 at 17:49, Andrew Cooper <andrew.cooper3@citrix.com> wrote: >>> On 11/11/11 16:07, Jan Beulich wrote: >>>> Irrespective of the IO-APIC vector sharing suppression patch just sent >>>> the logic in this function needs to iterate over all RTEs, since >>>> multiple pins within an IO-APIC may still use the same vector. >>> Why? The whole point of preventing vector sharing for IO-APICs is to >>> prevent two or more RTEs referencing the same vector. >> If that was really the case on *all* systems, then we wouldn''t need >> the chains of IRQs hanging off irq_2_pin[] entries. Obviously there are >> or have been or could theoretically be systems that do make use of this. >> >> BUT again after some more thinking about this over the weekend >> (and after fixing the issue pointed out in the other response regarding >> the other patch) I think we can actually convert the function to >> behave the way you intended it to after dealing with the vector >> sharing issue: The call sites are then only __eoi_IO_APIC_irq() (which >> already traverses the chain from irq_2_pin[]) and clear_IO_APIC_pin() >> (which explicitly wants to deal with just a single (apic, pin) tuple, the >> uses in the timer interrupt related boot time code having been bogus in >> this respect even before your original change to the EOI logic, as they >> imply that no other (apic, pin) tuple also represents the timer IRQ). >> >> Jan >> > > Ah yes. I was silly and had not considered that possibility. > Realistically, I doubt there are many boxes still around which have > shared ISA interrupts, but we should deal with the case.But I''ll withdraw the patch nevertheless, in favor of a more radical cleanup (removing the pin == -1 case altogether). See my response on the other thread. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Possibly Parallel Threads
- Bug#625438: [PATCH] xen: ioapic: avoid gcc 4.6 warnings about uninitialised variables
- Bug#625438: [PATCH] xen: ioapic: avoid gcc 4.6 warnings about uninitialised variables
- [PATCH] AMD IOMMU: add missing checks
- [PATCH] x86: allow Dom0 read-only access to IO-APICs
- refactoring io_apic.c