group.of.nepali.translators team mailing list archive

[Kleber Sacilotto de Souza <kleber.souza@xxxxxxxxxxxxx>]

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

** Changed in: linux (Ubuntu Xenial)
   Importance: Undecided => High

** Changed in: linux (Ubuntu Xenial)
     Assignee: (unassigned) => Guilherme G. Piccoli (gpiccoli)

** Changed in: linux (Ubuntu)
       Status: Confirmed => Invalid

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1810328

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

Status in linux package in Ubuntu:
  Invalid
Status in linux source package in Xenial:
  In Progress

Bug description:
  [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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1810328/+subscriptions