On Tue, 25 Apr 2023 21:15:25 +0100 Peter Maydell <peter.mayd...@linaro.org> wrote:
> On Tue, 25 Apr 2023 at 18:37, Jonathan Cameron > <jonathan.came...@huawei.com> wrote: > > We could explore only solving the problem for pxb-cxl for now. > > However, we would still be talking infrastructure in kernel only > > to support emulated CXL devices and I can see that being > > controversial. A normal CXL host bridge is not something > > we can enumerate. > > Hmm, so what is real hardware doing that our emulation is not? For real hardware, the host bridges would not typically share the various windows. Various options, but most likely they would be in different PCI segments, with separate ECAM space, and separate space into which the BARs would be mapped. That separation would be needed as the Physical Address routing in the host would need to direct the reads and writes to the correct bit of hardware and that tends to be done with very simple address decoders on the appropriate interconnects - those internal routing tables are normally effectively fixed for a given system. We could add another full host bridge to arm-virt. That would require separate emulation as I don't think we can reuse the pxb-cxl stuff. The PXB approach is to ignore the normal restrictions on routing being fairly fixed, by building a fixed configuration before the OS sees it - allowing different host bridges to use different parts of a single region. Arguably very early boot firmware could do that with a physical system but it would involve some nasty impdef programming of address decoder logic. This would be similar to what firmware does to change the routing dependent on whether it finds a 2 socket confirmation or a 4 socket configuration in servers. Want entity would do this is implementation defined - may well be before any application processor boots. Jonathan > > -- PMM
