From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id E1B921FF15C for ; Fri, 5 Sep 2025 14:52:50 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 097AB14A22; Fri, 5 Sep 2025 14:53:03 +0200 (CEST) Message-ID: <03689eea-7824-4139-8ff8-4917d9bc62ec@proxmox.com> Date: Fri, 5 Sep 2025 14:52:29 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Daniel Kral , Proxmox VE development discussion References: <20250902112307.124706-1-d.kral@proxmox.com> <20250902112307.124706-5-d.kral@proxmox.com> <828b157d-48d4-4540-9d87-2bbfb2865045@proxmox.com> Content-Language: en-US From: Fiona Ebner In-Reply-To: X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1757076731376 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. [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 05.09.25 um 1:38 PM schrieb Daniel Kral: > On Fri Sep 5, 2025 at 12:50 PM CEST, Fiona Ebner wrote: >> Am 02.09.25 um 1:23 PM schrieb Daniel Kral: >> >>> 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? > > Hm, the reason for this warning is for people that get the above > vfio_container_dma_map(...) error, which was happening before aw-bits > was increased from 39 to 48 bits with qemu 9.2 already. > > Now that the default value for aw-bits is 48 bits, the people that have > less than 48 bits physical address width will set aw-bits more often, as > their machine cannot start anyway because of the fatal aw-bits > host > aw-bits error. > > So we could go for that warning at all times, but that leave out users > who don't have aw-bits set (e.g. machine version set to < 9.2) or other > cases that could come in the future (e.g. when CPUs with 5-level paging > are more present).. > > But I agree with you about the maintainability burden, so maybe we'll > just do a warning whenever aw-bits is set, then guest-phys-bits should > also be set to a value guest-phys-bits = aw-bits? Ah, I wasn't aware this issue could also happen without aw-bits set. As discussed off-list: The simple notice/warning when aw-bits is set (and vfio is used) would still catch most newly affected people. Would be nice to have the aw-bits feature available, so that users can work around the regression. The other warning is best done in QEMU itself and it just seems like there was no follow-up series for that yet [0]. We could also go ahead and apply/backport the warning [1] ourselves without waiting for upstream. Still would be good to briefly ask the author if this is still planned or if it should/can be picked up. [0]: https://lore.kernel.org/qemu-devel/20250206131438.1505542-1-clg@redhat.com/ [1]: https://lore.kernel.org/qemu-devel/20250130134346.1754143-9-clg@redhat.com/ _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel