From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: iommu=0 leading to panic when system defaults to using x2apic Date: Tue, 14 Dec 2010 07:59:53 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Kay, Allen M" , Jan Beulich , "Zhang, Yang Z" Cc: "xen-devel@lists.xensource.com" , "Han, Weidong" List-Id: xen-devel@lists.xenproject.org Also, even if we continued to use cluster mode for IPIs (in the hope of devising a more efficient group IPI algorithm in future) that doesn't stop us from always exposing physical mode to IOAPICs and MSI devices. -- Keir On 14/12/2010 07:44, "Keir Fraser" wrote: > Well, if it is a restriction imposed by cluster mode, you know the next > question is obvious: Why do we bother with cluster mode at all? I don't see > that it yields us any advantage over physical mode, and we could use > physical mode without interrupt remapping, that would seem to be a big bonus > and simplification? Could we just kill our x2apic cluster mode logic? > > -- Keir > > On 14/12/2010 02:25, "Kay, Allen M" wrote: > >> Keir/Jan, >> >> My understanding is that cluster mode requires it. I will get back to you >> guys after I dig out the details on this - did not get a chance to do this >> today. >> >> Allen >> >> -----Original Message----- >> From: Keir Fraser [mailto:keir.xen@gmail.com] On Behalf Of Keir Fraser >> Sent: Monday, December 13, 2010 1:03 AM >> To: Jan Beulich; Kay, Allen M; Zhang, Yang Z >> Cc: Han, Weidong; xen-devel@lists.xensource.com >> Subject: Re: [Xen-devel] iommu=0 leading to panic when system defaults to >> using x2apic >> >> On 13/12/2010 08:15, "Jan Beulich" wrote: >> >>>>>> On 11.12.10 at 01:07, "Kay, Allen M" wrote: >>>> Yes, interrupt remapping is needed to be the intermediary between legacy >>>> IOxAPIC and MSI devices and the new x2APIC in the CPU. >>> >>> But isn't this only when there are APIC IDs beyond 255? >> >> Apparently not, since even Linux requires irq remapping even when none of >> the APIC IDs are greater than 255. Unless running on kvm or xen. I don't >> fully understand this particular restriction, mind you. >> >> Actually, my guess is that x2apic mode requires a different format of APIC >> message with a 32-bit APICID field, legacy IOxAPIC and MSI devices do not >> support the new message format, and so irq remapping hardware is required to >> bridge the two formats, even if no actual irq remapping is occurring. >> >> Is that a canny guess, Allen? >> >> -- Keir >> >>> Jan >>> >>>> -----Original Message----- >>>> From: Keir Fraser [mailto:keir.xen@gmail.com] On Behalf Of Keir Fraser >>>> Sent: Friday, December 10, 2010 10:50 AM >>>> To: Kay, Allen M; Jan Beulich; Zhang, Yang Z >>>> Cc: xen-devel@lists.xensource.com; Han, Weidong >>>> Subject: Re: [Xen-devel] iommu=0 leading to panic when system defaults to >>>> using x2apic >>>> >>>> Ah, and the interrupt remapping dependency is because PCI(e) devices cannot >>>> address 32-bit APIC IDs? >>>> >>>> -- Keir >>>> >>>> On 10/12/2010 18:26, "Kay, Allen M" wrote: >>>> >>>>> The architectural requirement is actually between interrupt remapping and >>>>> x2apic. Since interrupt remapping is part of the VT-d feature so current >>>>> software requires all VT-d features enabled in order for x2apic to be >>>> enabled. >>>>> >>>>> Strictly speaking DMA remapping is not required for x2apic. However, >>>>> queued >>>>> invalidation is required since interrupt remapping requires queued >>>>> invalidation. So x2apic dependency is as follows: >>>>> >>>>> x2apic->interrupt remapping->queued invalidation >>>>> >>>>> Due to historical reasons, the new VT-d features were built on top of the >>>>> old >>>>> ones as they become available. Is there a requirement to separate this >>>>> out? >>>>> If so, we will need to re-design iommu boot parameter which took a while >>>>> to >>>>> get it right so most systems can now boot successfully. >>>>> >>>>> Allen >>> >>> >> >> > >