On Wed, Jun 20, 2012 at 1:32 AM, Jiang Liu <jiang.liu@xxxxxxxxxx> wrote: > Hi Yinghai, > > Yes, I'm going to adopt solution two as you suggested. > On the other hand, the MMCFG caching is kept due to following > considerations: > 1) To emit a warning message if MMCFG entries in MCFG table only > partially covers buses under a PCI host bridge. Taku reported that > he has a system which exhibits such a behavior. Interesting. that should have one overal checking after _CBA entry is added into pci_mmcfg_list. We limit root bus bus range after busn_alloc is there. aka dump the bus range above mmcfg. or user need to disable mmcfg. > 2) To cross-check that MMCFG addresses returned by MCFG table and > _CBA method are consistent if both are available (though that > violates the PCI FW/ACPI specifications). now we are adding support for pci hostbridge plug. so we should better to stick with spec instead of trying to workaround possible FW problem. Do spoil them too much. my point is: MCFG is static. so the range from MCFG can not be changed after they pass the sanity checking. later if _CBA is trying come again with overlapping, just through that away. then if _CBA is good, then just record the range, and later release the range according the storage during hostbridge removal. > 3) In future, we may try to remove MMCFG entry constructed from > MCFG table when hot-removing a PCI host bridge. We have some systems > which assign a distinguish segment ID for each host bridge. In such > a case, it may be reasonable to remove the MMCFG entry when removing > a host bridge. No, MCFG is static one. > 4) The MCFG cache should be small under normal cases. > > If you feel it's unnecessary to keep the cache, I will remove > it and send out a updated version soon. for pci host bridge support, we would touch too much thing, I would like to limit first round change and keep it simple, and later could optimize it if possible. Thanks Yinghai -- 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
