Hi Marcel, Thanks a lot for your feedback.
> I don't think we should try to place the MMCFGs before 4G even if there > is enough room. Is better to place them always after 4G. > > "above_4g_mem" PCI hole it is reserved for PCI devices hotplug. We cannot use if for > MMCFGs. What I think we can do is to "move" the 64 bit PCI hole after the MMCFGs. > So the layout of over 4G space will be: > > [RAM hotplug][MMCFGs][PCI hotplug]... OK, I will reorganize the memory layout. Should the number of MMCFG be limited, as there might be insufficient memory above 4G? > Do you need the number of existing expander hosts? We have a pxbdev_list, just query it. Great, I think I missed that list. > The above will need to change. We move the pci hole, not resize it. > I am not sure this is the right place to handle it, maybe we add a new property > right beside pci_hole ones (extra-mmcfg?) and default it to 0. That sounds good, so that we just need to check this range when setting mcfg table instead of traversing the host bridge list. > You cannot use the MCH_HOST_BRIDGE_PCIEXBAR_DEFAULT as it is in use > by the "main" root complex MMCFG. Actually I don't think we can come up > with a valid default. I see, I'll replcae it with unmapped then. > Be aware this is used by both pxb and pxb-pcie devices, I think you should split the type >for each one and let the pxb's one as before. OK, I had thought it would make codes simpler, as TYPE_PCIE_HOST_BRIDGE is also the child of TYPE_PCI_HOST_BRIDGE, but I did forget about the pxb devices. I'll split it in v2. Thanks Zihan
