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

[Jason Gunthorpe <jgg@nvidia.com>]

On Wed, Oct 01, 2025 at 12:16:31PM -0600, Alex Williamson wrote:
> I think the question would be whether a "bare" VF really provides a
> useful device for nova-core to bind to or if we're just picking it
> up

It really should work, actual linux containers are my goto reason for
people wanting to use VF's without a virtualization layer.

> fair bit of software emulation/virtualization in the host vGPU driver to
> turn the VF into something that can work like a PF in the VM and I
> don't know that we can require nova-core to make use of a VF without
> that emulation/virtualization layer.  For example, aren't VRAM
> allocations for a VF done as part of profiling the VF through the vGPU
> host driver? 

The VF profiling should be designed to work without VFIO.

It is was one thing to have the VFIO variant driver profile mediated
devices that only it can create, but now that it is a generic VF
without mediation it doesn't make sense anymore.

The question is how much mediation does the variant driver insert
between the VM and the VF, and from what I can see that is mostly
limited to config space..

IOW, I would expect nova-core on the PF has a way to profile and
activate the VF to a usable state and then nova-core can run either
through a vm or directly on the VF.

At least this is how all the NIC drivers have their SRIOV support
designed today.

Jason