From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [45.144.208.40]) by lore.proxmox.com (Postfix) with ESMTPS id 0ECF61FF0B7 for ; Tue, 25 Aug 2026 15:16:10 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id 789AC215D3; Tue, 25 Aug 2026 15:16:09 +0200 (CEST) Message-ID: Date: Tue, 25 Aug 2026 15:16:05 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta Subject: Re: [PATCH pve-docs 0/2] qm: pci passthrough: the AtomicOps caveat of the all-functions form To: Yao Xu , pve-devel@lists.proxmox.com References: <20260824170828.42821-1-Xy2462381442@gmail.com> Content-Language: en-US From: Dominik Csapak In-Reply-To: <20260824170828.42821-1-Xy2462381442@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1787663734814 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.742 Adjusted score from AWL reputation of From: address DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment (newer systems) RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: U2NDIUFIKPNUIIH5UP4QA4CF2JBBIU5Q X-Message-ID-Hash: U2NDIUFIKPNUIIH5UP4QA4CF2JBBIU5Q X-MailFrom: d.csapak@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On 8/25/26 10:10 AM, Yao Xu wrote: > Passing a card with the shortened ``00:02`' syntax quietly costs the > guest PCIe AtomicOps. QEMU adds AtomicOp completer support to the > emulated root port only for a single-function device, so the port ends > up advertising none, and nothing in the config or the logs points at > the cause. The failure surfaces as a driver or ROCm problem several > layers away. > > Patch 1 documents this next to the paragraph that introduces the > syntax. Patch 2 appends the function to the GPU example below it, which > currently pairs pcie=on with the all-functions form and would hit the > caveat as written. > > Verified on Proxmox VE 9.2.4 with QEMU 11.0.2 and two RX 7900 XT > (gfx1100) in one q35 guest; the reproduction is in patch 1. > > Yao Xu (2): > qm: pci passthrough: note the AtomicOps caveat of all-functions form > qm: pci passthrough: name the function in the GPU example > > qm-pci-passthrough.adoc | 17 ++++++++++++++++- > 1 file changed, 16 insertions(+), 1 deletion(-) > Hi, thanks for the contribution, did you already see our developer docs: https://pve.proxmox.com/wiki/Developer_Documentation ? especially the part about the CLA. I have a question: how is this handled on real hardware, since I guess that works just fine there? (The cards in question do have multiple functions...) If yes, I'd rather have this reported as a bug on the QEMU side, rather have a behavior documented that might change with any release. From my experience, in most situations, you want to pass the card through as it is on the host, e.g. with functions. Also, the way the note is phrased makes it sound like this is something everyone needs, while it's probably only relevant for some use cases. In that case we could rephrase the note to something like: Note for multi-GPU ROCm users: QEMU (up to version x.y as of 2026) only advertises... or something similar. Best regards Dominik