On 10/1/25 11:30 AM, Jason Gunthorpe wrote: > 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.
This is a solid use case, even though we don't yet have it for GPUs. > >> 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. So we'll need to add some support to nova-core, in order for that to happen. It's not there yet, of course. > > 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. > OK, so I really like this design direction, and we can go in that direction. However, I'd like to start with this tiny patchset first, because: a) It's only one "if" statement to delete, when we decide to start letting nova-core support VFs directly. b) This series simplifies handling of VFs for the first use case, which is vGPU running on VFIO. thanks, -- John Hubbard
