On Mon, 4 Sep 2023 18:27:10 +0800 Yuquan Wang <wangyuquan1...@phytium.com.cn> wrote:
> Hi, Jonathan > Hi Yuquan Given this question isn't just ARM specific included qemu-devel in the cc list as that gets much wider reading than qemu-arm. > Due to my poor experience and knowledge on cxl development history, I am > sorry to continue > to ask some very simple and fundamental questions : ( > > In hw/arm/virt : > [VIRT_CXL_HOST] = { 0x0, 64 * KiB * 16 }, /* 16 UID */ > > It seems like the specific space for MMIO of cxl host bridges. Why not just > use the existing "VIRT_PCIE_MMIO" > space for them? At the system design level, MMIO space of Root complex register space via RCRB does not map in a similar fashion to PCIE MMIO space (which is handled via address decoding in the PCIE fabric). It is much more similar to MMIO for platform devices - as such the implementation handles in like a platform device (well 16 of them which seemed enough for any sane usecase). Now the next bit I've only quickly explored so may have some errors! For instance on a GPEX the main MMIO region is an alias to the sysbus mmio region 1. https://elixir.bootlin.com/qemu/latest/source/hw/arm/virt.c#L1452 That region is then mapped to a generic pci_root_bus for use by bar mappings etc. https://elixir.bootlin.com/qemu/latest/source/hw/pci-host/gpex.c#L136 So in theory we could make some space for the CXL root bridge RCRB registers but it would make various generic paths more complex. In a real system those registers are likely to be far from the PCI MMIO space anyway so the way it's modeled is probably more realistic than pushing the RCRB into the existing allocation. I hope that clarifies our reasoning for handling this MMIO region separately. Jonathan > > I would be grateful if you have some free time to help check this issue : ) > > Many thanks > Yuquan