On 04/06/2016 04:38 PM, Ian Munsie wrote:
+ /* try fixed PHB numbering first, by checking archs and reading + * the respective device-tree property. */ + if (machine_is(pseries)) { + regs = of_get_property(dn, "reg", NULL); + if (regs) + return (int)(be32_to_cpu(regs[1]) & 0xFFFF); + } else if (machine_is(powernv)) { + prop64 = of_get_property(dn, "ibm,opal-phbid", NULL); + if (prop64) + return (int)(be64_to_cpup(prop64) & 0xFFFF); + }I think these cases should still set the bit in phb_bitmap, otherwise a virtual PHB (e.g. as used in cxl/cxlflash) will be assigned PHB 0, and since that is already taken it will fail - we're already seeing a failure in Ubuntu Xenial since Canonical picked this patch up already (though have not confirmed that this is definitely the cause yet). There might also be some interesting races to think about here if a virtual PHB grabs a PHB number before the real one gets a chance.
This is a very interesting case I didn't think before. Thanks for pointing this Ian.
We can, as you suggested, set the bitmap in any case to avoid conflicts with virtual PHBs.
And in the case a virtual PHB grabs the bitmap before, we just need to add Michael's suggested check and fallback to bitmap PHB numbering in this case.
Do you think this is enough to avoid issues with cxl'a virtual PHBs? Thanks, Guilherme -- 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
