From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 7145571AF9 for ; Fri, 13 May 2022 12:03:48 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 6182E4B7 for ; Fri, 13 May 2022 12:03:18 +0200 (CEST) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS id A91984A8 for ; Fri, 13 May 2022 12:03:16 +0200 (CEST) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 5C13842881 for ; Fri, 13 May 2022 12:03:16 +0200 (CEST) Date: Fri, 13 May 2022 12:03:14 +0200 From: Stoiko Ivanov To: Thomas Lamprecht Cc: Proxmox VE development discussion Message-ID: <20220513120314.2df86f9d@rosa.proxmox.com> In-Reply-To: <4d537794-0ff8-5baf-513d-4dcdb3096d9a@proxmox.com> References: <20220513085739.545309-1-s.ivanov@proxmox.com> <4d537794-0ff8-5baf-513d-4dcdb3096d9a@proxmox.com> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.198 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record T_SCC_BODY_TEXT_LINE -0.01 - Subject: Re: [pve-devel] [PATCH pve-kernel] d/rules: kconfig: do not enable intel_iommu by default X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2022 10:03:48 -0000 On Fri, 13 May 2022 11:31:42 +0200 Thomas Lamprecht 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