Public bug reported:
[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.
* Attached to this Launchpad are 2 files with the kdump test case:
"iommu-missing" shows
the issue in a Trusty HWE kernel - without the fix patch, we can see messages
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
In our case, the rootfs couldn't be initialized since the SCSI adapter
wasn't initialized due to the DMAR failures (hpsa driver). Also,
Solarflare NIC (sfc driver) couldn't get initialized too.
The patch fixed those error messages and the rootfs was mounted (see file
"iommu-patched").
Notice the succeeding case couldn't kdump for other reasons, not strictly
related to the proposed patch here.
[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.
** Affects: linux (Ubuntu)
Importance: High
Assignee: Guilherme G. Piccoli (gpiccoli)
Status: Confirmed
** Tags: sts
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1810328
Title:
iommu - need to effectively disable iommu if "intel_iommu=off" is
passed as a kernel parameter
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1810328/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
