Nouveau - Oct 2025 - [PATCH 0/2] rust: pci: expose is_virtfn() and reject VFs in nova-core

On 2025-10-01 at 08:07 +1000, John Hubbard <jhubbard at nvidia.com>
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
to
> let NovaCore bind to the VFs, and then have NovaCore call into the upper
> (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.
Curiously based on a quick glance I didn't see any other drivers doing this
which makes me wonder why we're different here. But it seems likely their
virtual functions are supported by the same driver rather than requiring a
different VF specific driver (or I glanced too quickly!).

I'm guessing the proposal is to fail the probe() function in nova-core for
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
possible
today.
> Use is_virtfn() in NovaCore, in preparation for it to be used in a VFIO
> scenario.
> 
> I've based this on top of today's driver-core-next [1], because the
> first patch belongs there, and the second patch applies cleanly to either
> driver-core-next or drm-rust-next. So this seems like the easiest to
> work with.
> 
> 
> [1]
https://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core.git/
> 
> John Hubbard (2):
>   rust: pci: add is_virtfn(), to check for VFs
>   gpu: nova-core: reject binding to SR-IOV Virtual Functions
> 
>  drivers/gpu/nova-core/driver.rs | 5 +++++
>  rust/kernel/pci.rs              | 6 ++++++
>  2 files changed, 11 insertions(+)
> 
> 
> base-commit: 6d97171ac6585de698df019b0bfea3f123fd8385
> -- 
> 2.51.0
>

On 9/30/25 5:29 PM, Alistair Popple wrote:
> On 2025-10-01 at 08:07 +1000, John Hubbard <jhubbard at nvidia.com>
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 to
>> let NovaCore bind to the VFs, and then have NovaCore call into the
upper
>> (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.
> 
> Curiously based on a quick glance I didn't see any other drivers doing
this
> which makes me wonder why we're different here. But it seems likely
their
> 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.
> 
> I'm guessing the proposal is to fail the probe() function in nova-core
for
> 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
possible
> today.
Yes, from my experience with building Nouveau and Nova and running both
on the same system, with 2 GPUs: when Nova gets probed first, because Nova
is a work in progress, however far it gets, it still fails the probe in
the end.

And then Nouveau gets probed, and claims the GPU.

thanks,
-- 
John Hubbard