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 4A4DC71AD5 for ; Fri, 13 May 2022 11:32:14 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 24F012FF02 for ; Fri, 13 May 2022 11:31:44 +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)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS id 4C1712FEBC for ; Fri, 13 May 2022 11:31:43 +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 1A6CE434C2 for ; Fri, 13 May 2022 11:31:43 +0200 (CEST) Message-ID: <4d537794-0ff8-5baf-513d-4dcdb3096d9a@proxmox.com> Date: Fri, 13 May 2022 11:31:42 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:101.0) Gecko/20100101 Thunderbird/101.0 Content-Language: en-GB To: Proxmox VE development discussion , Stoiko Ivanov References: <20220513085739.545309-1-s.ivanov@proxmox.com> From: Thomas Lamprecht In-Reply-To: <20220513085739.545309-1-s.ivanov@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL 1.463 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 NICE_REPLY_A -2.888 Looks like a legit reply (A) 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 09:32:14 -0000 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 > --- > 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.