[Kernel-packages] [Bug 1810328] Re: iommu - need to effectively disable iommu if "intel_iommu=off" is passed as a kernel parameter
** Tags added: cscc
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
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:
Fix Released
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
--
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
[Kernel-packages] [Bug 1810328] Re: iommu - need to effectively disable iommu if "intel_iommu=off" is passed as a kernel parameter
This bug was fixed in the package linux - 4.4.0-142.168 --- linux (4.4.0-142.168) xenial; urgency=medium * linux: 4.4.0-142.168 -proposed tracker (LP: #1811846) * Packaging resync (LP: #1786013) - [Packaging] update helper scripts * iptables connlimit allows more connections than the limit when using multiple CPUs (LP: #1811094) - netfilter: xt_connlimit: don't store address in the conn nodes - SAUCE: netfilter: xt_connlimit: remove the 'addr' parameter in add_hlist() - netfilter: nf_conncount: expose connection list interface - netfilter: nf_conncount: Fix garbage collection with zones - netfilter: nf_conncount: fix garbage collection confirm race - netfilter: nf_conncount: don't skip eviction when age is negative * CVE-2017-5715 - SAUCE: x86/speculation: Cleanup IBPB runtime control handling - SAUCE: x86/speculation: Cleanup IBRS runtime control handling - SAUCE: x86/speculation: Use x86_spec_ctrl_base in entry/exit code - SAUCE: x86/speculation: Move RSB_CTXSW hunk * Xenial update: 4.4.167 upstream stable release (LP: #1811077) - media: em28xx: Fix use-after-free when disconnecting - Revert "wlcore: Add missing PM call for wlcore_cmd_wait_for_event_or_timeout()" - rapidio/rionet: do not free skb before reading its length - s390/qeth: fix length check in SNMP processing - usbnet: ipheth: fix potential recvmsg bug and recvmsg bug 2 - kvm: mmu: Fix race in emulated page table writes - xtensa: enable coprocessors that are being flushed - xtensa: fix coprocessor context offset definitions - Btrfs: ensure path name is null terminated at btrfs_control_ioctl - ALSA: wss: Fix invalid snd_free_pages() at error path - ALSA: ac97: Fix incorrect bit shift at AC97-SPSA control write - ALSA: control: Fix race between adding and removing a user element - ALSA: sparc: Fix invalid snd_free_pages() at error path - ext2: fix potential use after free - dmaengine: at_hdmac: fix memory leak in at_dma_xlate() - dmaengine: at_hdmac: fix module unloading - btrfs: release metadata before running delayed refs - USB: usb-storage: Add new IDs to ums-realtek - usb: core: quirks: add RESET_RESUME quirk for Cherry G230 Stream series - misc: mic/scif: fix copy-paste error in scif_create_remote_lookup - Kbuild: suppress packed-not-aligned warning for default setting only - exec: avoid gcc-8 warning for get_task_comm - disable stringop truncation warnings for now - kobject: Replace strncpy with memcpy - unifdef: use memcpy instead of strncpy - kernfs: Replace strncpy with memcpy - ip_tunnel: Fix name string concatenate in __ip_tunnel_create() - drm: gma500: fix logic error - scsi: bfa: convert to strlcpy/strlcat - staging: rts5208: fix gcc-8 logic error warning - kdb: use memmove instead of overlapping memcpy - iser: set sector for ambiguous mr status errors - uprobes: Fix handle_swbp() vs. unregister() + register() race once more - MIPS: ralink: Fix mt7620 nd_sd pinmux - mips: fix mips_get_syscall_arg o32 check - drm/ast: Fix incorrect free on ioregs - scsi: scsi_devinfo: cleanly zero-pad devinfo strings - ALSA: trident: Suppress gcc string warning - scsi: csiostor: Avoid content leaks and casts - kgdboc: Fix restrict error - kgdboc: Fix warning with module build - leds: call led_pwm_set() in leds-pwm to enforce default LED_OFF - leds: turn off the LED and wait for completion on unregistering LED class device - leds: leds-gpio: Fix return value check in create_gpio_led() - Input: xpad - quirk all PDP Xbox One gamepads - Input: matrix_keypad - check for errors from of_get_named_gpio() - Input: elan_i2c - add ELAN0620 to the ACPI table - Input: elan_i2c - add ACPI ID for Lenovo IdeaPad 330-15ARR - Input: elan_i2c - add support for ELAN0621 touchpad - btrfs: Always try all copies when reading extent buffers - Btrfs: fix use-after-free when dumping free space - ARC: change defconfig defaults to ARCv2 - arc: [devboards] Add support of NFSv3 ACL - mm: cleancache: fix corruption on missed inode invalidation - usb: gadget: dummy: fix nonsensical comparisons - iommu/vt-d: Fix NULL pointer dereference in prq_event_thread() - iommu/ipmmu-vmsa: Fix crash on early domain free - can: rcar_can: Fix erroneous registration - batman-adv: Expand merged fragment buffer for full packet - bnx2x: Assign unique DMAE channel number for FW DMAE transactions. - qed: Fix PTT leak in qed_drain() - qed: Fix reading wrong value in loop condition - net/mlx4_core: Zero out lkey field in SW2HW_MPT fw command - net/mlx4_core: Fix uninitialized variable compilation warning - net/mlx4: Fix UBSAN warning of signed integer overflow - net: faraday: ftmac100: remove netif_running(netdev) check before disabling interrupts
[Kernel-packages] [Bug 1810328] Re: iommu - need to effectively disable iommu if "intel_iommu=off" is passed as a kernel parameter
Verification was done in Xenial kernel 4.4.0-142, available in -proposed
pocket.
Basically, a regular boot with "intel_iommu=on" was completed, and then we
kexec'ed
the same kernel, but now with "intel_iommu=off". Everything works as expected;
before this patch inclusion, we saw DMAR errors (as mentioned in the
description here) and the storage controller (hpsa driver) didn't work.
Thanks,
Guilherme
** Tags removed: verification-needed-xenial
** Tags added: verification-done-xenial
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
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:
Fix Committed
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
--
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
[Kernel-packages] [Bug 1810328] Re: iommu - need to effectively disable iommu if "intel_iommu=off" is passed as a kernel parameter
This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
xenial' to 'verification-done-xenial'. If the problem still exists,
change the tag 'verification-needed-xenial' to 'verification-failed-
xenial'.
If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.
See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you!
** Tags added: verification-needed-xenial
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
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:
Fix Committed
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
--
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
[Kernel-packages] [Bug 1810328] Re: iommu - need to effectively disable iommu if "intel_iommu=off" is passed as a kernel parameter
** 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.
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:
Fix Committed
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
--
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
[Kernel-packages] [Bug 1810328] Re: iommu - need to effectively disable iommu if "intel_iommu=off" is passed as a kernel parameter
** 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 Kernel
Packages, which is subscribed to linux in Ubuntu.
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
--
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
[Kernel-packages] [Bug 1810328] Re: iommu - need to effectively disable iommu if "intel_iommu=off" is passed as a kernel parameter
** Also affects: linux (Ubuntu Xenial)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
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:
Confirmed
Status in linux source package in Xenial:
New
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
--
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
[Kernel-packages] [Bug 1810328] Re: iommu - need to effectively disable iommu if "intel_iommu=off" is passed as a kernel parameter
Patch submitted to kernel-team mailing list:
https://lists.ubuntu.com/archives/kernel-team/2019-January/097452.html
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
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:
Confirmed
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
--
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
[Kernel-packages] [Bug 1810328] Re: iommu - need to effectively disable iommu if "intel_iommu=off" is passed as a kernel parameter
** Attachment added: "Issue scenario (iommu couldn't get disabled without the
patch)"
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1810328/+attachment/5226416/+files/iommu-missing
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
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:
Confirmed
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
--
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
[Kernel-packages] [Bug 1810328] Re: iommu - need to effectively disable iommu if "intel_iommu=off" is passed as a kernel parameter
** Attachment added: "Fix scenario (iommu correctly disabled with the proposed
patch)"
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1810328/+attachment/5226417/+files/iommu-patched
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
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:
Confirmed
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
--
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
