RE: iommu=0 leading to panic when system defaults to using x2apic

["Jan Beulich" <JBeulich@novell.com>]

>>> On 11.12.10 at 01:07, "Kay, Allen M" <allen.m.kay@intel.com> 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?

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" <allen.m.kay@intel.com> 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