From nobody Thu Apr 2 01:54:50 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 455964CA278 for ; Tue, 3 Mar 2026 21:15:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772572556; cv=none; b=NIX1TLxhWJuSmrobkIwu/pdGg6MrhEnGy68olpE7lpuqc1Bt2IWp9ilKL+GPVRl7eeUZuEE3kJbVjqo2qpy/6xcMlwgd94ZjL2Kik+69SC5K6Y8MwQvbCSKpoIx/46y3Wl5kIqNioQQ6ZoDsYlzSemasEkEJfz2jxFnAfmFgbVw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772572556; c=relaxed/simple; bh=aIeoCt7uogRc0fVC6+4FHa1SGMowdDhKrl+UTRXZUrA=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=nl0/Lk0OOsElOpqJgcyr1ky/OCWmCLRA+4q73/amTr/rfiV440uK0KePlG8YyTYdXnO7tElu5irucXWLZ/4g0QJRPsAX38U2hvsLua8OxxEO52PuMMjw809NqgC52uwauCWUD93AdCsxlwHqgJHqEKGM5RT4k8IGqN8Gl+obEpQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=ClSPKbLW; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=BH5zR2yy; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="ClSPKbLW"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="BH5zR2yy" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1772572553; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=62xgaFtJ6odD5MPfFUAjLdRekJQ/qnRaVs4d4H+RycE=; b=ClSPKbLWZNGN7BuHje3qvLZ7qVruJgZQlQ6Dzt90mRjvMLJOgyuwOe+iLQmRQtehu3M1Eu aSQSrjDKm+qViaKWCQQupOBQPImtlkLD1m9E9esi1+5kppZbDOfiVFmiuqnQNeh/b92YUz pxiThj/9P3Lw7yb/ihg7WMAwOf58mYs= Received: from mail-qt1-f197.google.com (mail-qt1-f197.google.com [209.85.160.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-253-qRtZdmSKOzOVbXbJfZQ-Bw-1; Tue, 03 Mar 2026 16:15:52 -0500 X-MC-Unique: qRtZdmSKOzOVbXbJfZQ-Bw-1 X-Mimecast-MFC-AGG-ID: qRtZdmSKOzOVbXbJfZQ-Bw_1772572552 Received: by mail-qt1-f197.google.com with SMTP id d75a77b69052e-5033b62efa7so456800781cf.1 for ; Tue, 03 Mar 2026 13:15:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1772572552; x=1773177352; darn=vger.kernel.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:from:to:cc:subject:date:message-id :reply-to; bh=62xgaFtJ6odD5MPfFUAjLdRekJQ/qnRaVs4d4H+RycE=; b=BH5zR2yyYm5YGR4PZLS0xBoOxJrvBLB2Kg101tTeQlqusNMYR0du2T6vMPj1TtGmrX Rv3kaKqZp60D9EuhME6OYwqcd4WtGAqWTpvhDkqLK+D4tUg0ZNm8QMusn4OCTa2E8OrT idjiTIxleiaVzJMmvHGnuvT2EMF8ZkU4zGUNoLDUXiXgj0PGhlolJuWA3kslV9r5RBHN CQljfmcO67ONgTBd6rl+euma9GTjFYqqqWy3/6WJ6wFdjljerOmrVfnj+TP9a4VAKQuR 33cA8QJT2BnYnRXGcZWCfv1FSy8woG2tR7BL9LokePIfKaAFcKj/HzVHCbx9XfdlceRV JGow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772572552; x=1773177352; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:x-gm-gg:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=62xgaFtJ6odD5MPfFUAjLdRekJQ/qnRaVs4d4H+RycE=; b=jhu2XnxjsF/1Lyam0ZrVxgckkAflqZII5/eTRlbd3juCR+x8ZxV6PXPVUbYOpg8v4C U8OKnRms2DX9XiZU/08C+d7z0GBBrxFiFKMJBDq0rweVeoB6mVv+LEDXbxb4Y7e/zPxR FjG8f7m8F8rg5sRQW990BAtKEUEJXPfrkaiB8cJMPZzIb+uJLoSVgKfGrrzeenVqUixw yX6VdhNkljA8s9ucUKmv9IpgR+jznhpLpTp+DbtMYfz4XEtpCPUo+f62vrP2r31etKkx oAkh7NFRorR+aZtv3kcFX8yGuJFgLgCHuamMER1eaAzs3iy6EwJ+6uWTGSaPrf7hv14e wrmw== X-Forwarded-Encrypted: i=1; AJvYcCWHRNPx7OTMSOn/kltyz7UsC0pFBG0wU/WUdQZ9HjQrJCb55q+fBNP8njLFj1WmwIlwB++aQUaoUF1OsU0=@vger.kernel.org X-Gm-Message-State: AOJu0YwgbQzDPlozidTr52SEdMs4iZH2uiUvP0CUo6CO5TaTFETq4neS 9Si8fipGn3Yw1gwCJuVFVLgeKDL0HHvDa2GJhkAewu83Xioq3jkHK87WRQOSuImy30Mw0BZgjIx XY+PsWrZoPCliUNWjS6mdyjtxMNNOf9GBPoPWMviiKSCu4/JshOjwJT1CZlgnmiy8jQ== X-Gm-Gg: ATEYQzzXn5yzHBv1Wy+LfLgP5CU7hag58jvPKS0ykBv4hPPJrXsmSwfiRvbF1kQLtFO W9c65YKqSV8iV7EwF3uo8LNFGPNjsUunE353B5qVuOfGwcPaRqaODVc3sPLSA7U4fS8wCdCRC7s jgAUrvkDGHHET4QS4wG406238rth+pAW1qapc3Io5rgTtkz2sF9dce5QJsoH53HlP9KW2q1inWW Lg8sPpsyOhsJ0FOx7RBXSCUIvl8X95cssbSwp874BJL+QYjqm6Utdxy66E5VX3EAc57AFkoaOIg 06n4ir0Q8cZxcWyoNWHvr0Ws1yBnYOD2C2Fl42H7V3Q5oBNTi8dUnvKIa6CBKXeh51ZMHM7KvoF 7/xSp7LT19n2JHdhLiHqL2xmq8w== X-Received: by 2002:ac8:7d53:0:b0:503:2ea0:ef2a with SMTP id d75a77b69052e-507528a83e7mr213703711cf.18.1772572551545; Tue, 03 Mar 2026 13:15:51 -0800 (PST) X-Received: by 2002:ac8:7d53:0:b0:503:2ea0:ef2a with SMTP id d75a77b69052e-507528a83e7mr213703051cf.18.1772572551032; Tue, 03 Mar 2026 13:15:51 -0800 (PST) Received: from [172.16.1.8] ([2607:f2c0:b1e3:9a00:3c7:56c2:f819:96d2]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-5074481c0e5sm156286991cf.0.2026.03.03.13.15.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 03 Mar 2026 13:15:50 -0800 (PST) From: Peter Colberg Date: Tue, 03 Mar 2026 16:15:29 -0500 Subject: [PATCH v3 09/10] rust: pci: add physfn(), to return PF device for VF device Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260303-rust-pci-sriov-v3-9-4443c35f0c88@redhat.com> References: <20260303-rust-pci-sriov-v3-0-4443c35f0c88@redhat.com> In-Reply-To: <20260303-rust-pci-sriov-v3-0-4443c35f0c88@redhat.com> To: Danilo Krummrich , Bjorn Helgaas , =?utf-8?q?Krzysztof_Wilczy=C5=84ski?= , Miguel Ojeda , Alex Gaynor , Gary Guo , =?utf-8?q?Bj=C3=B6rn_Roy_Baron?= , Benno Lossin , Andreas Hindborg , Alice Ryhl , Trevor Gross , Abdiel Janulgue , Daniel Almeida , Robin Murphy , Greg Kroah-Hartman , Dave Ertman , Ira Weiny , Leon Romanovsky , David Airlie , Simona Vetter , Jonathan Corbet , Xu Yilun , Tom Rix , Moritz Fischer , "Rafael J. Wysocki" , Boqun Feng Cc: linux-pci@vger.kernel.org, rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org, Alexandre Courbot , Alistair Popple , Joel Fernandes , John Hubbard , Zhi Wang , nouveau@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-doc@vger.kernel.org, linux-fpga@vger.kernel.org, driver-core@lists.linux.dev, Peter Colberg , Jason Gunthorpe X-Mailer: b4 0.14.2 Add a method to return the Physical Function (PF) device for a Virtual Function (VF) device in the bound device context. Unlike for a PCI driver written in C, guarantee that when a VF device is bound to a driver, the underlying PF device is bound to a driver, too, by always setting the flag managed_sriov in the pci_driver structure. In case SR-IOV has been enabled by a C driver that has not set the flag managed_sriov in pci_driver, return an error from physfn(). This change depends on commit a995fe1a3aa7 ("rust: driver: drop device private data post unbind") to also uphold the safety guarantee in case a (broken) PF driver re-enables SR-IOV in its unbind() callback. That commit extends the lifetime of the device private data beyond the remove_callback() wrapper. In particular, that commit ensures that the device private data for the PF device is still alive until after the function pci_iov_remove() is called and forcibly re-disables SR-IOV, which means the data can be safely accessed by VF drivers until then. Suggested-by: Danilo Krummrich Signed-off-by: Peter Colberg --- Changes in v3: - Replace SR_IOV -> SR-IOV in description. Changes in v2: - Uphold safety guarantee when PF driver is written in C. - Let physfn() return error if driver flag managed_sriov is unset. --- rust/kernel/pci.rs | 53 ++++++++++++++++++++++++++++++++++++++++++++++++++= +++ 1 file changed, 53 insertions(+) diff --git a/rust/kernel/pci.rs b/rust/kernel/pci.rs index 581930d0afe98ccc29d729e4d9aab75b4144e46c..3b11f73a9f2b69a02fe003b8fea= dd61864adc8c0 100644 --- a/rust/kernel/pci.rs +++ b/rust/kernel/pci.rs @@ -525,6 +525,59 @@ pub fn pci_class(&self) -> Class { } } =20 +impl Device { + /// Returns the Physical Function (PF) device for a Virtual Function (= VF) device. + /// + /// # Examples + /// + /// The following example illustrates how to obtain the private driver= data of the PF device, + /// where `vf_pdev` is the VF device of reference type `&Device`= or `&Device`. + /// + /// ``` + /// # use kernel::{device::Core, pci}; + /// /// A PCI driver that binds to both the PF and its VF devices. + /// struct MyDriver; + /// + /// impl MyDriver { + /// fn connect(vf_pdev: &pci::Device) -> Result { + /// let pf_pdev =3D vf_pdev.physfn()?; + /// let pf_drvdata =3D pf_pdev.as_ref().drvdata::()?; + /// Ok(()) + /// } + /// } + /// ``` + #[cfg(CONFIG_PCI_IOV)] + pub fn physfn(&self) -> Result<&Device> { + if !self.is_virtfn() { + return Err(EINVAL); + } + + // SAFETY: `self.as_raw()` returns a valid pointer to a `struct pc= i_dev`. + // `physfn` is a valid pointer to a `struct pci_dev` since `is_vir= tfn()` is `true`. + let pf_dev =3D unsafe { (*self.as_raw()).__bindgen_anon_1.physfn }; + + // SAFETY: `pf_dev` is a valid pointer to a `struct pci_dev`. + // `driver` is either NULL or a valid pointer to a `struct pci_dri= ver`. + let pf_drv =3D unsafe { (*pf_dev).driver }; + if pf_drv.is_null() { + return Err(EINVAL); + } + + // SAFETY: `pf_drv` is a valid pointer to a `struct pci_driver`. + if !unsafe { (*pf_drv).managed_sriov } { + return Err(EINVAL); + } + + // SAFETY: `physfn` may be cast to a `Device` since= the + // driver flag `managed_sriov` forces SR-IOV to be disabled when t= he + // PF driver is unbound, i.e., all VF devices are destroyed. This + // guarantees that the underlying PF device is bound to a driver + // when the VF device is bound to a driver, which is the case since + // `Device::physfn()` requires a `&Device` reference. + Ok(unsafe { &*pf_dev.cast() }) + } +} + impl Device { /// Enable memory resources for this device. pub fn enable_device_mem(&self) -> Result { --=20 2.53.0