From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 2580828F935; Wed, 1 Oct 2025 10:32:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759314731; cv=none; b=N74K4r/NA7J0tvZu4fCCiIraL0UIJtrktZWuzqpVLpqspVAq6nJck7O4PKfDTsDEdZeh++8AJpNUaBI7o5l+hddnVKBQHIl15YUYjVTYRbNrRnShBzQUgzWPja0jTKEaj2hb/mPKkNW2/fCiti2W43dGXvljFe8P90xVXssUXS8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759314731; c=relaxed/simple; bh=P+YFqwjAsyQVj+ajZA/B1KBSZKrqZK9v+m3Wiyc2kV0=; h=Mime-Version:Content-Type:Date:Message-Id:Subject:Cc:To:From: References:In-Reply-To; b=nKJkltrwx5ICbdouXDiXS0l0yUg1XJQP1Dby6K5UnH4pSmf8WbYKVZ2iTnmvd3ebfAZ5rrQHk5Ezakxs5bxqEBGlnGzpvvPkLlWp3shyH9HznneVR9qVdxHZ63GkoBFVEwE/lV/xrebFhRu/9e9Cgy5CmEcs9lKt+WFV72V3+Ac= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=tKoY2KnL; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="tKoY2KnL" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 45AD1C4CEF4; Wed, 1 Oct 2025 10:32:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1759314728; bh=P+YFqwjAsyQVj+ajZA/B1KBSZKrqZK9v+m3Wiyc2kV0=; h=Date:Subject:Cc:To:From:References:In-Reply-To:From; b=tKoY2KnL8Xj76oTVo6g45E3T5ntWA8T8f6WWl5EpA50rhnXgrX2/kqqr0xjJ19izW P/6MMZw0S7kFN2T7z2C8MLi4fVhnnuZD7wriXPiBnITh2FI7KK0KUG5HwPOeYshj13 9pxzZtdM8rWiQA4U6VX0A7np0iOnn+5Jhb89q/+sRJWc7B3yFTiWDN4B5MebDNe4Vf zor/ax/V2JBHOiqkIKrHVcylkoDQdbldtm/B6vWL4nB8R3YPW7/3TddnoIbjNl7LGH SrZEE7ds/mGwl3LLCQtgGhwpbCgTRGEQdEADKiHn0J50zuq8zcDPsCawnFe3YSiNs3 cuTjOCLJqxG8A== Precedence: bulk X-Mailing-List: rust-for-linux@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Wed, 01 Oct 2025 12:32:02 +0200 Message-Id: Subject: Re: [PATCH 0/2] rust: pci: expose is_virtfn() and reject VFs in nova-core Cc: "Alexandre Courbot" , "Joel Fernandes" , "Timur Tabi" , "Zhi Wang" , "Surath Mitra" , "David Airlie" , "Simona Vetter" , "Bjorn Helgaas" , =?utf-8?q?Krzysztof_Wilczy=C5=84ski?= , "Miguel Ojeda" , "Alex Gaynor" , "Boqun Feng" , "Gary Guo" , =?utf-8?q?Bj=C3=B6rn_Roy_Baron?= , "Benno Lossin" , "Andreas Hindborg" , "Alice Ryhl" , "Trevor Gross" , , , , "LKML" To: "John Hubbard" , "Alistair Popple" From: "Danilo Krummrich" References: <20250930220759.288528-1-jhubbard@nvidia.com> In-Reply-To: On Wed Oct 1, 2025 at 3:22 AM CEST, John Hubbard wrote: > On 9/30/25 5:29 PM, Alistair Popple wrote: >> On 2025-10-01 at 08:07 +1000, John Hubbard wrote..= . >>> Post-Kangrejos, the approach for NovaCore + VFIO has changed a bit: the >>> idea now is that VFIO drivers, for NVIDIA GPUs that are supported by >>> NovaCore, should bind directly to the GPU's VFs. (An earlier idea was t= o >>> let NovaCore bind to the VFs, and then have NovaCore call into the uppe= r >>> (VFIO) module via Aux Bus, but this turns out to be awkward and is no >>> longer in favor.) So, in order to support that: >>> >>> Nova-core must only bind to Physical Functions (PFs) and regular PCI >>> devices, not to Virtual Functions (VFs) created through SR-IOV. >>> >>> Add a method to check if a PCI device is a Virtual Function (VF). This >>> allows Rust drivers to determine whether a device is a VF created >>> through SR-IOV. This is required in order to implement VFIO, because >>> drivers such as NovaCore must only bind to Physical Functions (PFs) or >>> regular PCI devices. The VFs must be left unclaimed, so that a VFIO >>> kernel module can claim them. >>=20 >> Curiously based on a quick glance I didn't see any other drivers doing t= his >> which makes me wonder why we're different here. But it seems likely thei= r >> virtual functions are supported by the same driver rather than requiring= a >> different VF specific driver (or I glanced too quickly!). > > I haven't checked into that, but it sounds reasonable. There are multiple cases: Some devices have different PCI device IDs for their physical and virtual functions and different drivers handling then. One example for that is Inte= l IXGBE. But there are also some drivers, which do a similar check and just stop pro= bing if they detect a virtual function. So, this patch series does not do anything uncommon. >> I'm guessing the proposal is to fail the probe() function in nova-core f= or >> the VFs - I'm not sure but does the driver core continue to try probing = other >> drivers if one fails probe()? It seems like this would be something best >> filtered on in the device id table, although I understand that's not pos= sible >> today. Yes, the driver core keeps going until it finds a driver that succeeds prob= ing or no driver is left to probe. (This behavior is also the reason for the na= me probe() in the first place.) However, nowadays we ideally know whether a driver fits a device before pro= be() is called, but there are still exceptions; with PCI virtual functions we've= just hit one of those. Theoretically, we could also indicate whether a driver handles virtual func= tions through a boolean in struct pci_driver, which would be a bit more elegant. If you want I can also pick this up with my SR-IOV RFC which will probably = touch the driver structure as well; I plan to send something in a few days.