From: "Yuquan Wang" <wangyuquan1236@phytium.com.cn>
To: Jonathan.Cameron@Huawei.com, marcin.juszkiewicz@linaro.org,
ardb+tianocore@kernel.org, quic_llindhol@quicinc.com,
peter.maydell@linaro.org
Cc: chenbaozi@phytium.com.cn, devel@edk2.groups.io,
linux-cxl@vger.kernel.org, asa-dev@op-lists.linaro.org,
qemu-devel@nongnu.org, qemu-arm@nongnu.org,
Yuquan Wang <wangyuquan1236@phytium.com.cn>
Subject: [edk2-devel] [RFC PATCH v2 0/1] Sbsa-ref CXL Enablement
Date: Tue, 5 Nov 2024 18:43:45 +0800 [thread overview]
Message-ID: <20241105104346.417102-1-wangyuquan1236@phytium.com.cn> (raw)
v1 -> v2:
- provide CXL exclusive MMIO32 & MMIO64 space
- hard coded two cxl root ports
RFC because
- Many contents are ported from Jonathan' patch on qemu virt design
- Less experience and not particularly confident in sbsa-ref address space design
so this might be stupidly broken in a way I've not considered.
Currently the base CXL support for arm platforms is only on Jonathan's patches[1]
which have not yet merged into upstream. SBSA-REF can be more like a real machine,
thus the support of cxl could be meaningful.
This series leverages Jonathan's patches[1] to design [SBSA_CXL_HOST] and
[SBSA_CXL_FIXED_WINDOW] spaces for sbsa-ref layout.
For [SBSA_CXL_HOST], since this creates a default pxb-cxl (bus_nr=0xc0) bridge
with two cxl root ports on sbsa-ref, the new memory layout places 64K space for
one hard coded cxl host bridge register regions in the sbsa-ref memmap.
According to above design, for now only two cxl type3 devices could be added on
the cxl host.
With the 'create_pxb_cxl', users don't need to input '-device pxb-cxl' and
'-device cxl-rp' parameters.
In addition, this support indepentent mmio32(32M) & mmio64(1M) space which are
enough for cxl components, because in this way the previous pcie mmio32/64 space
would not be divided and affected.
However, with the pxb-cxl-host, any cxl root ports and cxl endpoint devices would
occupy the BDF number of the original pcie domain. Hence, the max available pcie
devices on sbsa-ref would decrease, which seems to bring a series of trouble.
I'm looking for some comments on the problems and suggestions on if there are better
ways to do it.
For [SBSA_CXL_FIXED_WINDOW], in order to provide CFMWs on sbsa-ref, this extends 1TB
space from the hole above RAM Memory [SBSA_MEM] for CXL Fixed Memory Window.
0xA0000000000 is chosen as the base address of this space because of 3 reasons:
1) It is more suitable to choose a static address instead of that
implementation in virt, since a dynamic address space layout of
sbsa-ref is not appropriate for its original purpose as a reference
platform.
2) The Hotplug Memory address range should in the range of maximum
addressable range of sbsa-ref platform(0x10000000000-0x80ffffffffff).
It is satisfied the requirements of memory hotplug in linux kernel.
3) The start pfn of CFMW should exceed the reserved_pfn_range for
onlined numa node.
Based on 'cxl_fmws_link_targets', this adds a new function
'sbsa_cxl_fmws_link_targets' for binding cfmws.target with the default
pxb-cxl-bus on sbsa-ref.
In addition, this also adds 'create_cxl_fixed_window_region' to support
creating a static cfmw region on sbsa-ref, so users don't need to input
'-M cxl-fmw' parameter.
Thus, to run sbsa-ref with a cxl device could use:
qemu-system-aarch64 \
-object memory-backend-file,id=mem2,mem-path=/tmp/mem2,size=256M,share=true \
-device cxl-type3,bus=cxl.0,volatile-memdev=mem2,id=cxl-mem1 \
By the way, since the matched firmware correspond to this patch would allocate
pcie bus 0xc0 ~ 0xff to pxb-cxl-host, we should add "bus=pcie.0" when we want
to plug some devices on the original pcie bus, for example:
-device qemu-xhci,bus=pcie.0 \
or
-device nvme,serial=deadbeef,bus=pcie.0,drive=hdd \
-drive file=../disk/hdd.qcow2,format=qcow2,id=hdd,if=none \
This series patches are here to hopefully some comments to guide me!
Link:
[1]: https://lore.kernel.org/linux-cxl/20220616141950.23374-1-Jonathan.Cameron@huawei.com/
[2]: https://edk2.groups.io/g/devel/topic/rfc_edk2_patch_v3_0_1/109403423#
[3]: https://edk2.groups.io/g/devel/topic/rfc_patch_edk2_platforms_v2/109403456
Yuquan Wang (1):
hw/arm/sbsa-ref: Support CXL Host Bridge & CFMW
docs/system/arm/sbsa.rst | 4 ++
hw/arm/sbsa-ref.c | 122 +++++++++++++++++++++++++++++++++++++-
hw/cxl/cxl-host-stubs.c | 2 +
hw/cxl/cxl-host.c | 2 +-
include/hw/cxl/cxl_host.h | 2 +
5 files changed, 130 insertions(+), 2 deletions(-)
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#120723): https://edk2.groups.io/g/devel/message/120723
Mute This Topic: https://groups.io/mt/109403513/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
next reply other threads:[~2024-11-05 10:44 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-05 10:43 Yuquan Wang [this message]
2024-11-05 10:43 ` [edk2-devel] [RFC PATCH v2 1/1] hw/arm/sbsa-ref: Support CXL Host Bridge & CFMW Yuquan Wang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20241105104346.417102-1-wangyuquan1236@phytium.com.cn \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox