Re: [RFC PATCH v5] hw/arm/sbsa-ref: Support CXL Host Bridge & CFMW

[Leif Lindholm <leif.lindholm@oss.qualcomm.com>]

On Thu, 12 Jun 2025 at 16:17, Jonathan Cameron
<Jonathan.Cameron@huawei.com> wrote:
> On Fri, 30 May 2025 18:54:30 +0800
> wangyuquan <wangyuquan1236@phytium.com.cn> wrote:
> > Dynamic cxl topology problem
> > ============================
> > Actually the ideal expectation is sbsa-ref could also have a dynamic cxl topology by user
> > parameters. According to my knowledge, it should pass a dtb to firmware to match the requird
>
> Spell check: required
>
> > address space. I'm currently trying to solve this problem. I am looking for suggestions on if
> > there are better ways to do it.
>
> I wonder how many cases we actually need to cover?  If we were to support 2 host bridges
> with a few root ports each (maybe 4 or 8?) and a set of static fixed memory windows
>
> 1. Target only 1st host bridge.
> 2. Target only 2nd host bridge
> 3. Target interleave granularity X across host bridges
> 4. Target interleave granularity Y across host bridges
>
> Maybe longer term we'd want some of the more complex options such as different properties
> for the fixed memory windows or different QoS groups (QTG) but I'm not sure
> we want to go for fully configurable.  The virt patches cover testing a
> general software stack - in my mind SBSA-ref is about testing a single representative
> configuration.

No. (continued below)

> The dance through DT and trusted world is just too messy for
> a development platform / configurable test platform.

Well, the "messiness" is the point. Although the DT is incidental and
nothing that would be visible
beyond the first layer of firmware.

A lot of the general testing effort being done (across the
firmware/software layers) is set up to succed,
rather than to verify sane and functional interfaces.
The purpose of the sbsa-ref platform is to enable useful verification
of the full firmware/software stack.
_But_ it's also about providing a sane default platform.

If we can have a sane default platform that also permits specifying
more complex topologies on
command line, that would be great.
But there's not necessarily value in providing more flexibility than
could realistically be found in real
SBSA-compliant platforms.

I need to take the time to read through this series properly.

/
    Leif