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: change IO-APIC ack method default forsingle

To: "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] x86: change IO-APIC ack method default forsingle IO-APIC systems
From: "Jan Beulich" <jbeulich@xxxxxxxxxx>
Date: Wed, 21 Jan 2009 14:51:26 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 21 Jan 2009 06:52:34 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C59CE34A.1AB6%keir.fraser@xxxxxxxxxxxxx>
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: <49773D8A.76E4.0078.0@xxxxxxxxxx> <C59CE34A.1AB6%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> Keir Fraser <keir.fraser@xxxxxxxxxxxxx> 21.01.09 15:35 >>>
>On 21/01/2009 14:21, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:
>
>> "ioapic_ack=old". With that knowledge I think it is now reasonable to
>> include that patch in -unstable, as the introduction of the 'new' ack
>> method was only to address issues with certain chipsets silently
>> setting up alternative IRQ routes when RTEs in secondary IO-APICs got
>> masked.
>
>I don't specifically recall that this issue required two IO-APICs. In fact I
>think it did not. It was actually something to do with the chipset trying to
>distinguish between an OS using 'legacy' routing versus 'mp-bios' routing,
>via a rather distasteful IO-APIC hack. Unfortunately the hack was not that
>uncommon and I don't think those chipsets had more than one IO-APIC.

I'm rather certain that it did involve multiple IO-APICs. What the chipsets
were trying to cover was the ACPI vs. no-ACPI case, since secondary IO-APICs
generally can be (or should I say are being/have been at that time on "certain"
OSes) discovered only with ACPI. Hence when an IRQ normally going to a
secondary IO-APIC's pin go masked in that IO-APIC, a replacement route
was automatically established (and not torn down when the mask bit got
cleared again) to a pin of the primary IO-APIC.

>Overall I think ack_type new has worked quite well. I was actually about to
>remove the old ack_type! (But now I won't ;-) I'm not inclined to take this
>patch though.

If I had an affected system to debug the issue, I'd try to do so (though
remembering how long it took to understand the original issue I'm hesitant
to say so). With the above explanation I hope you may reconsider...

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel