> Frank, I still don't understand what you're trying to do here. What's the use case? What is the end goal that you're trying to get to? > > What information do you need about the VF, and why? SR-IOV works properly today without this stuff. > > If we can understand what you're trying to do, then maybe we can help. Sorry, I used to think of this issue is common, but maybe not. I'm hacking igb to add support of VF migration. Migration is emerging as a standard of PCI IOV, but has not implemented in intel 82576(igb). The idea is interact with VF's MMIO/PCI configuration in the physical machine, which only PF's driver exists. This work started by userspace. All I know is the PCI BDF of the VF, because give BDF to the VMM is enough to assign a VF to a VM. So here comes the first issue, neither userspace nor PF driver knows the map from VF's ID to BDF. My plan is communicating with PF's driver by sysfs, so I repeatly complain about the sysfs issue. PF can access VF's BAR when it knows VF's ID. On the other hand, PF can access VF's PCI configuration only when if knows VF's BDF. This is the second issue. Even when userspace calculated and gave it an id, PF driver still cannot access the PCI configuration of VF. Really thanks for your help. I'm new on both kernel scope and English scope. :) -- Frank Pan Computer Science and Technology Tsinghua University -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
