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

On 9/30/25 6:39 PM, Alexandre Courbot wrote:
> On Wed Oct 1, 2025 at 10:26 AM JST, John Hubbard wrote:
>> On 9/30/25 5:26 PM, Alexandre Courbot wrote:
>>> On Wed Oct 1, 2025 at 7:07 AM JST, 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 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.
>>>
>>> Naive question: will guests also see the passed-through VF as a VF?
If
>>> so, wouldn't this change also prevents guests from using Nova?
>>
>> I'm also new to this area. I would expect that guests *must* see
>> these as PFs, otherwise...nothing makes any sense.
> 
> But if the guest sees the passed-through VF as a PF, won't it try to
> do things it is not supposed to do like loading the GSP firmware (which
> is managed by the host)?
Yes. A non-paravirtualized guest will attempt to behave just like a
bare metal driver would behave. It's the job of the various layers
of virtualization to intercept and modify such things appropriately.

Looking ahead: if the VFIO experts come back and tell us that guests
see these as VFs, then there is still a way forward, because we
talked about loading nova-core with a "vfio_mode" kernel module
parameter. So then it becomes "if vfio_mode, then skip VFs".


thanks,
-- 
John Hubbard

On 1.10.2025 4.45, John Hubbard wrote:
> On 9/30/25 6:39 PM, Alexandre Courbot wrote:
>> On Wed Oct 1, 2025 at 10:26 AM JST, John Hubbard wrote:
>>> On 9/30/25 5:26 PM, Alexandre Courbot wrote:
>>>> On Wed Oct 1, 2025 at 7:07 AM JST, 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 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.
>>>>
>>>> Naive question: will guests also see the passed-through VF as a
VF? If
>>>> so, wouldn't this change also prevents guests from using
Nova?
>>>
pdev->virtfn (VF) is set to "true" when admin enabling VFs via the
sysfs
and PF driver. Presumably, pdev->virtfn will be "false" all the
time in
the guest.
>>> I'm also new to this area. I would expect that guests *must*
see
>>> these as PFs, otherwise...nothing makes any sense.
>>
>> But if the guest sees the passed-through VF as a PF, won't it try
to
>> do things it is not supposed to do like loading the GSP firmware (which
>> is managed by the host)?
>
The guest driver will read PMC_BOOT_1 and check PMC_BOOT_1_VGPU_VF flag 
to tell if it is running on a VF or a PF.

https://github.com/NVIDIA/open-gpu-kernel-modules/blob/main/src/nvidia/arch/nvalloc/unix/src/os-hypervisor.c#L945
> Yes. A non-paravirtualized guest will attempt to behave just like a
> bare metal driver would behave. It's the job of the various layers
> of virtualization to intercept and modify such things appropriately.
> 
> Looking ahead: if the VFIO experts come back and tell us that guests
> see these as VFs, then there is still a way forward, because we
> talked about loading nova-core with a "vfio_mode" kernel module
> parameter. So then it becomes "if vfio_mode, then skip VFs".
> 
> 
> thanks,