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

On Thu Oct 2, 2025 at 2:01 PM CEST, Jason Gunthorpe
wrote:
> On Thu, Oct 02, 2025 at 12:52:10AM +0200, Danilo Krummrich wrote:
>
>> Indicating whether the driver supports VFs through a boolean in struct
>> pci_driver is about the same effort (well, maybe slightly more), but
solves the
>> problem in a cleaner way since it avoids probe() being called in the
first
>> place. Other existing drivers benefit from that as well.
>
> I'm strongly against that idea.
>
> Drivers should not be doing things like this, giving them core code
> helpers to do something they should not do is the wrong direction.
>
> I think this patchset should be simply dropped. Novacore should try to
> boot on a VF and fail if it isn't setup.
Why? What about other upstream drivers that clearly assert that they don't
support VFs? Why would we want to force them to try to boot to a point where
they "naturally" fail?

I think there's nothing wrong with allowing drivers to
"officially" assert that
they're intended for PFs only.

Here are a few examples of drivers that have the same requirement:

https://elixir.bootlin.com/linux/v6.17/source/drivers/net/ethernet/realtek/rtase/rtase_main.c#L2195
https://elixir.bootlin.com/linux/v6.17/source/drivers/net/ethernet/intel/ice/ice_main.c#L5266
https://elixir.bootlin.com/linux/v6.17/source/drivers/net/ethernet/intel/igb/igb_main.c#L3221

On Thu, Oct 02, 2025 at 02:08:27PM +0200, Danilo Krummrich wrote:
> Why? What about other upstream drivers that clearly assert that they
don't
> support VFs?
They shouldn't be doing that either. There is lots of junk in Linux,
that doesn't mean it should be made first-class to encourage more
people to do the wrong thing.
> Why would we want to force them to try to boot to a point where
> they "naturally" fail?
We want them to work.
 
>
https://elixir.bootlin.com/linux/v6.17/source/drivers/net/ethernet/realtek/rtase/rtase_main.c#L2195
>
https://elixir.bootlin.com/linux/v6.17/source/drivers/net/ethernet/intel/ice/ice_main.c#L5266
>
https://elixir.bootlin.com/linux/v6.17/source/drivers/net/ethernet/intel/igb/igb_main.c#L3221
This usage seems wrong to me:

commit 50ac7479846053ca8054be833c1594e64de496bb
Author: Anirudh Venkataramanan <anirudh.venkataramanan at intel.com>
Date:   Wed Jul 28 12:39:10 2021 -0700

    ice: Prevent probing virtual functions
    
    The userspace utility "driverctl" can be used to change/override
the
    system's default driver choices. This is useful in some situations
    (buggy driver, old driver missing a device ID, trying a workaround,
    etc.) where the user needs to load a different driver.
    
    However, this is also prone to user error, where a driver is mapped
    to a device it's not designed to drive. For example, if the ice driver
    is mapped to driver iavf devices, the ice driver crashes.
    
    Add a check to return an error if the ice driver is being used to
    probe a virtual function.

Decoding this.. There is actually an "iavf" driver, and it does have
special PCI IDs for VFs:

static const struct pci_device_id iavf_pci_tbl[] = {
        {PCI_VDEVICE(INTEL, IAVF_DEV_ID_VF), 0},
        {PCI_VDEVICE(INTEL, IAVF_DEV_ID_VF_HV), 0},
        {PCI_VDEVICE(INTEL, IAVF_DEV_ID_X722_VF), 0},
        {PCI_VDEVICE(INTEL, IAVF_DEV_ID_ADAPTIVE_VF), 0},

In normal cases iavf will probe to the SRIOV VFS just fine.

The above is saying if the user mis-uses driverctl to bind the ice
driver to a function that doesn't have matching PCI IDs then the
kernel crashes. Yeah. I'm pretty sure that is true for a lot of
drivers. Bind them to HW not in their ID tables and their are not
going to work right.

I would have rejected a patch like this. The ID table is already
correct and properly excludes VFs.

Jason