[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] iommu=0 leading to panic when system defaults to using x2apic
On 10/12/2010 10:58, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote: >>>> On 10.12.10 at 11:06, Keir Fraser <keir@xxxxxxx> 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 > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |