On Thu, Sep 10, 2026 at 04:13:07AM +0100, Patel, Atul wrote: > Hi Bruce, > > Thanks for the review, > No, the vf_id is not meant to be globally unique across the system - it stays > local to the PF, same as other devices. The pf_id here is fixed to a single > CPF (CPFL_HOST0_CPF_ID), and the control plane expects the vf_id in struct > cpchnl2_func_id to be relative to that PF (the header even documents it as > "indexing is relative to PF specified above"). > > The subtlety is purely in how those VFs are presented on the host side in the > vCPF model. The VFs belonging to that one PF are exposed to the host spread > across multiple PCI devices, with 8 functions each. So the PCI function > number alone isn't enough to recover the PF-relative vf_id - it wraps every 8 > functions. > > For example, with VFs enumerated on bus 0000:af: > PCI BDF device function -> vf_id > 0000:af:00.0 0 0 0 > 0000:af:00.1 0 1 1 > ... > 0000:af:00.7 0 7 7 > 0000:af:01.0 1 0 8 > 0000:af:01.1 1 1 9 > ... > 0000:af:01.7 1 7 15 > 0000:af:02.0 2 0 16 > > The macro just reconstructs that PF-relative index from the PCI address: > vf_id = device * 8 + function > > The previous code used pci_dev->addr.function directly, so it only worked for > the first device (VF 0-7) and collided for every VF on a subsequent device - > e.g. 0000:af:01.0 (VF 8) was incorrectly reported as VF 0. > Thanks, that is clear now.
/Bruce
