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

[Keir Fraser <keir@xen.org>]

On 10/12/2010 10:58, "Jan Beulich" <JBeulich@novell.com> wrote:

>>>> On 10.12.10 at 11:06, Keir Fraser <keir@xen.org> wrote:
>> Are you looking at xen-4.0? I think you should look at latest xen-unstable
> 
> I looked at 4.0 in parallel with -unstable (non-staging) as of
> yesterday.

Even before yesterday, xen-unstable benefits from c/s 22388, which is
intended to work around the iommu=0/x2apic=0 dependency a bit. Not sure if
it is fully satisfactory. And it is not backported to 4.0 as yet because,
well, I don't understand this crap enough, basically.

>> and we can backpoprt patches if that is more satisfactory. I did a big
>> cleanup patch yesterday which makes the code smaller and clearer than it
> 
> I'll have a look at what you did...

My change (c/s 22475) is larger, but should have no semantic change. It just
tries to make things smaller and cleaner. For that alone maybe we will
backport it to 4.0 too.

>> was, yet I don't understand the dependencies between x2apic-enabled-by-bios
>> and the need for interrupt remapping, and all that stuff.
> 
> ... after hopefully those dependencies got clarified by one of the
> original authors.

That would be nice. It feels like if BIOS has enabled x2apic we ought to be
able to soldier on with it and not need to panic. Couldn't we ignore the
x2apic-ness? Or turn it off? What about AMD boxes that support x2apic on the
CPUs yet of course do not have VT-d irq remapping? Lots of questions, few
answers. :-)

 -- Keir

> Jan
>