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@xxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxx] 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@xxxxxxxxxxxxxxxxxxx
>> Subject: Re: [Xen-devel] iommu=0 leading to panic when system defaults to
>> using x2apic
>>
>> On 13/12/2010 08:15, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:
>>
>>>>>> On 11.12.10 at 01:07, "Kay, Allen M" <allen.m.kay@xxxxxxxxx> 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@xxxxxxxxx] 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@xxxxxxxxxxxxxxxxxxx; 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@xxxxxxxxx> 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
>>>
>>>
>>
>>
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home