From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id 6677F1FF15C for ; Fri, 5 Sep 2025 12:50:14 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id E033512477; Fri, 5 Sep 2025 12:50:28 +0200 (CEST) Message-ID: <828b157d-48d4-4540-9d87-2bbfb2865045@proxmox.com> Date: Fri, 5 Sep 2025 12:50:24 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Proxmox VE development discussion , Daniel Kral References: <20250902112307.124706-1-d.kral@proxmox.com> <20250902112307.124706-5-d.kral@proxmox.com> Content-Language: en-US From: Fiona Ebner In-Reply-To: <20250902112307.124706-5-d.kral@proxmox.com> X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1757069406706 X-SPAM-LEVEL: Spam detection results: 0 AWL -0.024 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [proxmox.com, groups.io] Subject: Re: [pve-devel] [RFC qemu-server v2 3/4] fix #6378 (continued): warn intel-iommu users about iommu and host aw bits mismatch 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: , Reply-To: Proxmox VE development discussion Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" Am 02.09.25 um 1:23 PM schrieb Daniel Kral: > For certain host CPUs, such as Intel consumer-grade CPUs, there is a > frequent mismatch between the CPU's physical address width and the What do you mean by "frequent"? You already conditionalized with "For certain host CPUs". Do you mean "the default IOMMU's address witdth"? > IOMMU's address width. > > If a virtual machine is setup with an intel-iommu device, qemu allocates > and maps the (virtual) I/O address space (IOAS) for a VFIO passthrough > device with iommufd. > > In case of a mismatch of the address width of the host CPU and IOMMU > CPU, the guest physical address space (GPAS) and memory-type range > registers (MTRRs) are setup to the host CPU's address width, which > causes IOAS to be allocated and mapped outside of the IOMMU's maximum > guest address width (MGAW) and causes the following error from qemu (the > error message is copied from the user forum [0]): > > kvm: vfio_container_dma_map(0x5c9222494280, 0x380000000000, 0x10000, 0x78075ee70000) = -22 (Invalid argument) > > This error is rather confusing and unhelpful to users, so warn them > about a CPU physical address width that exceeds the IOMMU address width. > > [0] https://forum.proxmox.com/threads/vm-wont-start-with-pci-passthrough-after-upgrade-to-9-0.169586/page-3#post-795717 > After this commit, the test added by qemu-server 1/4 fails on my system: not ok 51 - 'q35-viommu-intel-aw-bits.conf' - Check if aw-bits are propagated correctly to intel-iommu device # Failed test ''q35-viommu-intel-aw-bits.conf' - Check if aw-bits are propagated correctly to intel-iommu device' # at ./run_config2command_tests.pl line 599. # got unexpected warning 'guest address width exceeds vIOMMU address width: 40 > 39' You'd need to mock the relevant parts to avoid querying the real host. > Signed-off-by: Daniel Kral > --- > I already talked about this with @Fiona off-list, but the code this > adds to qemu-server only for a warning is quite a lot, but is more > readable than the above error that is only issued when the VM is already > run. > > Particularily, I don't like the logic duplication of > get_cpu_address_width(...), which tries to copy what > target/i386/{,host-,kvm/kvm-}cpu.c do to retrieve the {,guest_}phys_bits > value, where I'd rather see this implemented in pve-qemu as in [0]. > > There are two qemu and edk2 discussion threads that might help in > deciding how to go with this patch [0] [1]. It could also be better to > implement this downstream in pve-qemu for now similar to [0], or of > course contribute to upstream with an actual fix. > > [0] https://lore.kernel.org/qemu-devel/20250130115800.60b7cbe6.alex.williamson@redhat.com/ > [1] https://edk2.groups.io/g/devel/topic/patch_v1/102359124 To avoid all the complexity and maintainability burden to stay compatible with how QEMU calculates, can we simply notify/warn users who set aw-bits that they might need to set guest-phys-bits to the same value too? > @@ -133,6 +133,17 @@ sub assert_valid_machine_property { > } > } > > +sub check_valid_iommu_address_width { > + my ($machine_conf, $machine_version, $cpu_aw_bits) = @_; > + if ($machine_conf->{viommu} && $machine_conf->{viommu} eq 'intel') { > + my $iommu_aw_bits_default = min_version($machine_version, 9, 2) ? 48 : 39; > + my $iommu_aw_bits = $machine_conf->{'aw-bits'} // $iommu_aw_bits_default; > + > + warn "guest address width exceeds vIOMMU address width: $cpu_aw_bits > $iommu_aw_bits\n" > + if $cpu_aw_bits && $iommu_aw_bits && $cpu_aw_bits > $iommu_aw_bits; Should mention that it can be fixed by setting the guest-phys-bits accordingly. _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel