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

On Thu, Oct 02, 2025 at 02:29:09PM +0000, Zhi Wang
wrote:
> On 2.10.2025 16.42, Jason Gunthorpe wrote:
> > On Thu, Oct 02, 2025 at 12:59:59PM +0000, Zhi Wang wrote:
> >> On 2.10.2025 14.58, Jason Gunthorpe wrote:
> >>> On Wed, Oct 01, 2025 at 09:13:33PM +0000, Zhi Wang wrote:
> >>>
> >>>> Right, I also mentioned the same use cases of NIC/GPU in
another reply
> >>>> to Danilo. But what I get is NVIDIA doesn't use bare
metal VF to support
> >>>> linux container, 
> >>>
> >>> I don't think it matter what "NVIDIA" does -
this is the upstream
> >>> architecture it should be followed unless there is some
significant
> >>> reason.
> >>
> >> Hmm. Can you elaborate why?
> >>
> >> From the device vendor's stance, they know what is the best
approach
> >> to offer the better the user experience according to their device
> >> characteristic.
> > 
> > You can easially push the code to nova core not vfio and make it work
> > generically, some significant reason is needed beyond "the vendor
> > doesn't want to".
You'd have to be more specific, I didn't see really any mediation
stuff in the vfio driver to explain why the VF in the VM would act so
differently that it "couldn't work"

Even if there is some small FW issue, it is better to still structure
things in the normal way and assume it will get fixed sometime later
than to forever close that door.

Jason

On 2.10.2025 17.31, Jason Gunthorpe wrote:
> On Thu, Oct 02, 2025 at 02:29:09PM +0000, Zhi Wang wrote:
>> On 2.10.2025 16.42, Jason Gunthorpe wrote:
>>> On Thu, Oct 02, 2025 at 12:59:59PM +0000, Zhi Wang wrote:
>>>> On 2.10.2025 14.58, Jason Gunthorpe wrote:
>>>>> On Wed, Oct 01, 2025 at 09:13:33PM +0000, Zhi Wang wrote:
>>>>>
>>>>>> Right, I also mentioned the same use cases of NIC/GPU
in another reply
>>>>>> to Danilo. But what I get is NVIDIA doesn't use
bare metal VF to support
>>>>>> linux container, 
>>>>>
>>>>> I don't think it matter what "NVIDIA" does -
this is the upstream
>>>>> architecture it should be followed unless there is some
significant
>>>>> reason.
>>>>
>>>> Hmm. Can you elaborate why?
>>>>
>>>> From the device vendor's stance, they know what is the best
approach
>>>> to offer the better the user experience according to their
device
>>>> characteristic.
>>>
>>> You can easially push the code to nova core not vfio and make it
work
>>> generically, some significant reason is needed beyond "the
vendor
>>> doesn't want to".
> 
> You'd have to be more specific, I didn't see really any mediation
> stuff in the vfio driver to explain why the VF in the VM would act so
> differently that it "couldn't work"
> 
From the device vendor?s perspective, we have no support or use case for
a bare-metal VF model, not now and not in the foreseeable future. Even
hypothetically, such support would not come from nova-core.ko, since
that would defeat the purpose of maintaining a trimmed-down kernel
module where minimizing the attack surface and preserving strict
security boundaries are primary design goals.
> Even if there is some small FW issue, it is better to still structure
> things in the normal way and assume it will get fixed sometime later
> than to forever close that door.
> 
> Jason