[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.


-----Original Message-----
From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@xxxxxxxxxx] 
Sent: Thursday, May 19, 2011 7:32 AM
To: Andrew Cooper; Kay, Allen M
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
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.

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.