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

[Khaled Elmously]

Changed
(backported from commit 161b28aae1651aa7ad63ec14753aa8a751154340 upstream)
to
(backported from commit 161b28aae1651aa7ad63ec14753aa8a751154340)


On 2019-01-02 17:40:15 , Guilherme G. Piccoli wrote:
> [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
> 
> 
> -- 
> kernel-team mailing list
> kernel-team at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/kernel-team