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

[Keir Fraser <keir@xen.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" <keir@xen.org> 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" <allen.m.kay@intel.com> 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" <JBeulich@novell.com> wrote:
>> 
>>>>>> 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?
>> 
>> 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" <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
>>> 
>>> 
>> 
>> 
> 
>