If the parent bridge's [secondary, subordinate] window already covers
the VF bus (e.g., programmed by BIOS or a prior PF), skip allocating
PCI_RES_BUS. This avoids a duplicate rman allocation in the multi-PF
case while still allocating when growth is actually needed.
Details
Details
- Reviewers
imp jhb sumit.saxena_broadcom.com
Diff Detail
Diff Detail
- Lint
Lint Skipped - Unit
Tests Skipped
Event Timeline
Comment Actions
I need to think about this. I don't really want to have the PCI bus directly reading the config registers from the parent bridge. It's also true that you want to not release the bus until all VFs using that bus have been torn down, so you really kind of want a refcounted bus_alloc_resource here (in essence). It might be that just switching from RF_ACTIVE to RF_SHAREABLE when calling bus_alloc_resource is sufficient however.
Comment Actions
ok. I tried with "RF_SHAREABLE" but still the "bus_alloc_resource" was returning NULL for VFs created on other PFs.
Comment Actions
Hi john,
Please share your inputs on this. We have added the code and tested it for a couple of months and it is working as expected. I would appreciate your review and go-ahead.
Comment Actions
This is still a hack and layering violation, but I don't have any way to test the proper solution to see why it is failing for you as I don't have the hardware. For now, we can merge this, but we need to add a comment of /* XXX: This should not be directly accessing the bridge registers and does nothing to prevent some other device from releasing this bus number while another this PF is using it. */.
It would be nice to add tracing to figure out why using RF_SHAREABLE fails (e.g. which layer in the bus hierarchy does it actually fail, and then using devinfo -u output or the like to figure out why it is failing). It may just be that we need to fix some other places to also use RF_SHAREABLE to fix that approach. If it's not too hard, can you do that testing locally after merging this?