** Changed in: linux (Ubuntu Xenial)
       Status: In Progress => Fix Committed

You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.

  iommu - need to effectively disable iommu if "intel_iommu=off" is
  passed as a kernel parameter

Status in linux package in Ubuntu:
Status in linux source package in Xenial:
  Fix Committed

Bug description:

  * 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

  * 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 

  [Test Case]

  * Boot a kernel with "intel_iommu=on", and then kexec a new kernel with 
  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 

  [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 
  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.

To manage notifications about this bug go to:

Mailing list: https://launchpad.net/~kernel-packages
Post to     : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to