WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH] x86: clean up __io_apic_eoi()

To: "Andrew Cooper" <andrew.cooper3@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] x86: clean up __io_apic_eoi()
From: "Jan Beulich" <JBeulich@xxxxxxxx>
Date: Mon, 14 Nov 2011 09:08:15 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 14 Nov 2011 01:11:00 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4EBD5213.3030407@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4EBD5639020000780006077C@xxxxxxxxxxxxxxxxxxxx> <4EBD5213.3030407@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> On 11.11.11 at 17:49, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel