RE: [PATCH 3 of 3] kexec: disable iommu jumping into the kdump kernel

["Kay, Allen M" <allen.m.kay@intel.com>]

The functions iommu_enable_x2apic_IR()/iommu_disable_x2apic_IR() should really be architectural specific.  They should not be called from common code without going through iommu API. The reason it worked on AMD box is because it returns if the list acpi_drhd_units is empty.  On AMD box, this list is empty since it is only populated only on Intel VT-d enabled systems.  We will clean this up.

I don't know why is disable_intremap() called separately.  It seems to me we should be able to call disable_qinval() and disable_intremap() in vtd_suspend().

I will give it a try tomorrow and see if I can find a clue the code is written this way.

Allen

-----Original Message-----
From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] 
Sent: Thursday, May 19, 2011 7:32 AM
To: Andrew Cooper; Kay, Allen M
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] [PATCH 3 of 3] kexec: disable iommu jumping into the kdump kernel

> >>>What about AMD VI IOMMUs? Does it work when that IOMMU is used?
> >>>
> >>It worked on the AMD box I tested the code on.  Like the comment
> >>says - as far as I can tell, it is architecture independent code.
> >>>>+     */
> >>>>+    iommu_disable_x2apic_IR();
> >>>Can't that function be done in the suspend code of the IOMMU?
> >>There is a comment in iommu suspend stating that it cant and isn't
> >>done, but rather is left for the local/ioapic_suspend functions
> >>which dont properly work in the kexec path.
> >OK, how about just moving it out of driver/passthrought/vtd then?
> Because that code is fragile enough without me poking about in it.
> I would prefer someone with more knowledge about IOMMU to make that
> call.

OK. Lets CC him here then.