[pve-devel] [PATCH pve-kernel] d/rules: kconfig: do not enable intel_iommu by default

[pve-devel] [PATCH pve-kernel] d/rules: kconfig: do not enable intel_iommu by default

[Stoiko Ivanov]

enabling this causes quite a few issues with older hardware
(hp g8, and the like) - and most of our guides do call for enabling it
where needed (pci passthrough).

the setting was off in the 5.13 series.

following reports of disabling intel_iommu explicitly fixing the
issues in our community forum:
https://forum.proxmox.com/threads/.109368

Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
---
tested by installing on a HP G8 (and starting a minimal VM and running
stress-ng -d 2 for a minute), and on 2 VMs

alternatively we could document this in the 7.2 release notes and ask
users of problematic hardware to set this explicitly

 debian/rules | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/rules b/debian/rules
index 1ec1147..d648d95 100755
--- a/debian/rules
+++ b/debian/rules
@@ -44,6 +44,7 @@ PVE_CONFIG_OPTS= \
 -m CONFIG_BLK_DEV_NVME \
 -e CONFIG_NLS_ISO8859_1 \
 -d CONFIG_INPUT_EVBUG \
+-d CONFIG_INTEL_IOMMU_DEFAULT_ON \
 -d CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND \
 -d CONFIG_CPU_FREQ_DEFAULT_GOV_SCHEDUTIL \
 -e CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE \
-- 
2.30.2

Re: [pve-devel] [PATCH pve-kernel] d/rules: kconfig: do not enable intel_iommu by default

[Thomas Lamprecht]

Am 5/13/22 um 10:57 schrieb Stoiko Ivanov:
> enabling this causes quite a few issues with older hardware
> (hp g8, and the like) - and most of our guides do call for enabling it
> where needed (pci passthrough).
> 
> the setting was off in the 5.13 series.
> 
> following reports of disabling intel_iommu explicitly fixing the
> issues in our community forum:
> https://forum.proxmox.com/threads/.109368
> 
> Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
> ---
> tested by installing on a HP G8 (and starting a minimal VM and running
> stress-ng -d 2 for a minute), and on 2 VMs
> 
> alternatively we could document this in the 7.2 release notes and ask
> users of problematic hardware to set this explicitly

This all resembles quite a bit the switch from nested KVM to be enabled,
which we caught upfront and actively disabled to avoid trouble on migration
due to QEMU not being yet ready for that change, and only enabled it in the
next major release (6.0 IIRC) where we could be sure that a new enough QEMU
is available.

The difference here is that:
* we may never be sure that all setups out there support IOMMU, at least not
  if we don't get another major divider like the switch from 32bit to 64bit
  was

* we already switched it on now, sow disabling it may also break some setups
  that never did so manually.

FWIW, we could also disable this dynamically with a modprobe cfg file that
disables it if:
- not manually enabled already (grep for that)
- an older CPU (family) is present, where the cutoff would need to be
  decided


No hard feelings for that, technically simpler would be the KConfig switch
back of yours, but not sure if best for the growing use of IOMMU and modern
systems.

Re: [pve-devel] [PATCH pve-kernel] d/rules: kconfig: do not enable intel_iommu by default

[Stoiko Ivanov]

On Fri, 13 May 2022 11:31:42 +0200
Thomas Lamprecht <t.lamprecht@proxmox.com> wrote:

> Am 5/13/22 um 10:57 schrieb Stoiko Ivanov:
> ..snip..
> > alternatively we could document this in the 7.2 release notes and ask
> > users of problematic hardware to set this explicitly  
> 
> This all resembles quite a bit the switch from nested KVM to be enabled,
> which we caught upfront and actively disabled to avoid trouble on migration
> due to QEMU not being yet ready for that change, and only enabled it in the
> next major release (6.0 IIRC) where we could be sure that a new enough QEMU
> is available.
> 
> The difference here is that:
> * we may never be sure that all setups out there support IOMMU, at least not
>   if we don't get another major divider like the switch from 32bit to 64bit
>   was
agreed - I think we want to switch to default enabled eventually - my idea
was to have it even more visible during a major version-upgrade ...
OTOH since we just released 7.2 and have a known-issues section - I think
adding it there and linking to that should work fine.

> 
> * we already switched it on now, sow disabling it may also break some setups
>   that never did so manually.
my gut-feeling would be that most people who need it enabled (for
pci-passtrough) would follow the docs (of the past years) and set it
explicitly [0] - but you're right - it's a regression we would need to
document too.

> FWIW, we could also disable this dynamically with a modprobe cfg file that
> disables it if:
> - not manually enabled already (grep for that)
> - an older CPU (family) is present, where the cutoff would need to be
>   decided

maybe I'm missing something - but intel_iommu is builtin (not a module) -
and options for those need to be provided on the kernel commandline [1]?

and while (semi-optionally) shipping a modprobe.conf snippet could work,
I wouldn't want to `sed` in our user's `/etc/default/grub`,
`/etc/kernel/cmdline` in a postinst.
we could add it to the NEWS file for the packages - to give it some
visibility though)?


[0] we should update our docs on pci-passthrough (mostly meant as note to
myself) 

[1]
https://www.kernel.org/doc/html/v4.14/admin-guide/kernel-parameters.html