public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
	Stoiko Ivanov <s.ivanov@proxmox.com>
Subject: Re: [pve-devel] [PATCH pve-kernel] d/rules: kconfig: do not enable intel_iommu by default
Date: Fri, 13 May 2022 11:31:42 +0200	[thread overview]
Message-ID: <4d537794-0ff8-5baf-513d-4dcdb3096d9a@proxmox.com> (raw)
In-Reply-To: <20220513085739.545309-1-s.ivanov@proxmox.com>

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.




  reply	other threads:[~2022-05-13  9:32 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-13  8:57 Stoiko Ivanov
2022-05-13  9:31 ` Thomas Lamprecht [this message]
2022-05-13 10:03   ` Stoiko Ivanov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4d537794-0ff8-5baf-513d-4dcdb3096d9a@proxmox.com \
    --to=t.lamprecht@proxmox.com \
    --cc=pve-devel@lists.proxmox.com \
    --cc=s.ivanov@proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal