From: Stoiko Ivanov <s.ivanov@proxmox.com>
To: Thomas Lamprecht <t.lamprecht@proxmox.com>
Cc: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH pve-kernel] d/rules: kconfig: do not enable intel_iommu by default
Date: Fri, 13 May 2022 12:03:14 +0200 [thread overview]
Message-ID: <20220513120314.2df86f9d@rosa.proxmox.com> (raw)
In-Reply-To: <4d537794-0ff8-5baf-513d-4dcdb3096d9a@proxmox.com>
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
prev parent reply other threads:[~2022-05-13 10:03 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
2022-05-13 10:03 ` Stoiko Ivanov [this message]
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=20220513120314.2df86f9d@rosa.proxmox.com \
--to=s.ivanov@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
--cc=t.lamprecht@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.