Re: [Xen-devel] iommu=0 leading to panic when system defaults to using x2apic

[Keir Fraser <keir@xxxxxxx>]

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