[SRU X] [PATCH 0/1] Need to effectively disable iommu if "intel_iommu=off" is passed as parameter

[Guilherme G. Piccoli]

[Impact]

* If the parameter "intel_iommu=off" is passed for the kernel in a boot
instance coming from a previously iommu-enabled kernel (like a kexec/kdump
scenario), currently Xenial kernel (4.4 version) is missing a patch to
effectively disable the iommu. As a result, the previous DMA mappings remain
and the new kernel will try to use them, which is wrong since we don't have
iommu initialized to translate the addresses.

* The upstream patch proposed to SRU here, 161b28aae165
("iommu/vt-d: Make sure IOMMUs are off when intel_iommu=off") fixes the
issue by effectively disabling the iommu in case it was requested.

* One important use case is in a scenario of iommu bug that is leading to a
kernel crash; kdump naturally will have the iommu tables copied from previous
kernel in kdump boot time, so if iommu tables are bogus, we could inherit the
bug in the kdump kernel preventing a successful dump.
Have the ability to disable iommu (given that the functionality is there) is
essential.


[Test Case]

* Boot a kernel with "intel_iommu=on", and then kexec a new kernel with
"intel_iommu=off" parameter. A kdump test is also possible, by changing the
kdump command-line to disable iommu (after booting a kernel with iommu enabled);
then, induce a crash and the issue will show.

* There are test results attached in the Launchpad bug.
The messages seen in kernel log when the issue happens are like:

[36.489918] DMAR: DRHD: handling fault status reg 202
[36.734830] DMAR: DMAR:[DMA Read] Request device [03:00.0] fault addr 3179a000
[36.734830] DMAR:[fault reason 06] PTE Read access is not set


[Regression potential]

* iommu operations are complex and subject to HW issues eventually. Having
iommu enabled and then boot a kernel with this component disabled is
inherently a "danger" operation from drivers (or any users of such mappings)
point-of-view. That said, I don't see a potential regression for this patch,
in a way currently an user can't disable iommu properly if it was once
enabled, and this simple patch fixes it

* Care should be taken of course to not confuse regressions with problems
induced by disabling the iommu after it was enabled before (which would show
that the patch works fine indeed, by allowing iommu to get disabled) - some
drivers/devices may require iommu to be enabled in order to work, in such case
disabling it would prevent the device to work.

Joerg Roedel (1):
  iommu/vt-d: Make sure IOMMUs are off when intel_iommu=off

 drivers/iommu/intel-iommu.c | 18 +++++++++++++++++-
 1 file changed, 17 insertions(+), 1 deletion(-)

-- 
2.19.2