Re: CXL numa error on arm64 qemu virt machine
On Wed, May 08, 2024 at 01:02:52PM +0100, Jonathan Cameron wrote: > > > [0.00] ACPI: SRAT: Node 0 PXM 0 [mem 0x4000-0xbfff] > > [0.00] ACPI: SRAT: Node 1 PXM 1 [mem 0xc000-0x13fff] > > [0.00] ACPI: Unknown target node for memory at 0x100, > > assuming node 0 > > [0.00] NUMA: Warning: invalid memblk node 16 [mem > > 0x0400-0x07ff] > > [0.00] NUMA: Faking a node at [mem > > 0x0400-0x00013fff] > > [0.00] NUMA: NODE_DATA [mem 0x13f7f89c0-0x13f7fafff] > > > > Previous discussion: > > https://lore.kernel.org/linux-cxl/20231011150620.2...@huawei.com/ > > > > root@debian-bullseye-arm64:~# cxl create-region -d decoder0.0 -t ram > > [ 68.653873] cxl region0: Bypassing cpu_cache_invalidate_memregion() for > > testing! > > [ 68.660568] Unknown target node for memory at 0x100, assuming > > node 0 > > You need a load of kernel changes for NUMA nodes to work correctly with > CXL memory on arm64 platforms. I have some working code but need to tidy > up a few corners that came up in an internal review earlier this week. > > I have some travel coming up so may take a week or so to get those out. > > Curiously that invalid memblk has nothing to do with the CXL fixed memory > window > Could you check if that is happening for you without the CXL patches? > Thanks. I have checked it, the problem is caused by my bios firmware file. I change the bios file and the numa topology can works. BTW, if it is convenient, could you help to post the link of the patches of CXL memory NUMA nodes on arm64 platforms? > > Whilst it doesn't work yet (because of missing kernel support) > you'll need something that looks more like the generic ports test added in > https://gitlab.com/jic23/qemu/-/commit/6589c527920ba22fe0923b60b58d33a8e9fd371e > > Most importantly > -numa node,nodeid=2 -object acpi-generic-port,id=gp0,pci-bus-cxl.1,node=2 > + the bits setting distances etc. Note CXL memory does not provide SLIT like > data at the moment, so the test above won't help you identify if it is > correctly > set up. That's a gap in general in the kernel support. Whilst we'd love > it if everyone moved to hmat derived information we may need to provide > some fallback. > > Jonathan > Many thanks Yuquan
CXL numa error on arm64 qemu virt machine
Hello, Jonathan Recently I run some cxl tests on qemu virt(branch:cxl-2024-04-22-draft) but met some problems. Problems: 1) the virt machine could not set the right numa topology from user input; My Qemu numa set: -object memory-backend-ram,size=2G,id=mem0 \ -numa node,nodeid=0,cpus=0-1,memdev=mem0 \ -object memory-backend-ram,size=2G,id=mem1 \ -numa node,nodeid=1,cpus=2-3,memdev=mem1 \ However, the system shows: root@ubuntu-jammy-arm64:~# numactl -H available: 1 nodes (0) node 0 cpus: 0 1 2 3 node 0 size: 4166 MB node 0 free: 3920 MB node distances: node 0 0: 10 Boot Kernel print: [0.00] ACPI: SRAT: Node 0 PXM 0 [mem 0x4000-0xbfff] [0.00] ACPI: SRAT: Node 1 PXM 1 [mem 0xc000-0x13fff] [0.00] ACPI: Unknown target node for memory at 0x100, assuming node 0 [0.00] NUMA: Warning: invalid memblk node 16 [mem 0x0400-0x07ff] [0.00] NUMA: Faking a node at [mem 0x0400-0x00013fff] [0.00] NUMA: NODE_DATA [mem 0x13f7f89c0-0x13f7fafff] 2) it seems like the problem of allocating numa node in arm for cxl memory still exists; Previous discussion: https://lore.kernel.org/linux-cxl/20231011150620.2...@huawei.com/ root@debian-bullseye-arm64:~# cxl create-region -d decoder0.0 -t ram [ 68.653873] cxl region0: Bypassing cpu_cache_invalidate_memregion() for testing! [ 68.660568] Unknown target node for memory at 0x100, assuming node 0 If not, maybe I could try to do something to help fix this problem. My full qemu command line: qemu-system-aarch64 \ -M virt,gic-version=3,cxl=on \ -m 4G \ -smp 4 \ -object memory-backend-ram,size=2G,id=mem0 \ -numa node,nodeid=0,cpus=0-1,memdev=mem0 \ -object memory-backend-ram,size=2G,id=mem1 \ -numa node,nodeid=1,cpus=2-3,memdev=mem1 \ -cpu cortex-a57 \ -bios QEMU_EFI.fd.bak \ -device virtio-blk-pci,drive=hd,bus=pcie.0 \ -drive if=none,id=hd,file=../disk/debos_arm64.ext \ -nographic \ -object memory-backend-file,id=mem2,mem-path=/tmp/mem2,size=256M,share=true \ -device pxb-cxl,bus_nr=12,bus=pcie.0,id=cxl.1 \ -device cxl-rp,port=0,bus=cxl.1,id=root_port13,chassis=0,slot=2 \ -device cxl-type3,bus=root_port13,volatile-memdev=mem2,id=cxl-mem1 \ -M cxl-fmw.0.targets.0=cxl.1,cxl-fmw.0.size=4G \ -qmp tcp:127.0.0.1:,server,nowait \ Qemu version: the lastest commit of branch cxl-2024-04-22-draft in "https://gitlab.com/jic23/qemu; Kernel version: 6.6.0 Many thanks Yuquan
[PATCH 0/1] qemu-options.hx: Fix typo for interleave-granularity of CFMW
This patch fixes the unit typo of interleave-granularity of CXL Fixed Memory Window in qemu-option.hx. Yuquan Wang (1): qemu-options.hx: Fix typo for interleave-granularity of CFMW qemu-options.hx | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) -- 2.34.1
[PATCH 1/1] qemu-options.hx: Fix typo for interleave-granularity of CFMW
This patch fixes the unit typo of interleave-granularity of
CXL Fixed Memory Window in qemu-option.hx.
Signed-off-by: Yuquan Wang wangyuquan1...@phytium.com.cn
---
qemu-options.hx | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/qemu-options.hx b/qemu-options.hx
index 7fd1713fa8..e1b272d51a 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -151,14 +151,14 @@ SRST
platform and configuration dependent.
``interleave-granularity=granularity`` sets the granularity of
-interleave. Default 256KiB. Only 256KiB, 512KiB, 1024KiB, 2048KiB
-4096KiB, 8192KiB and 16384KiB granularities supported.
+interleave. Default 256(bytes). Only 256, 512, 1k, 2k
+4k, 8k and 16k granularities supported.
Example:
::
--machine
cxl-fmw.0.targets.0=cxl.0,cxl-fmw.0.targets.1=cxl.1,cxl-fmw.0.size=128G,cxl-fmw.0.interleave-granularity=512k
+-machine
cxl-fmw.0.targets.0=cxl.0,cxl-fmw.0.targets.1=cxl.1,cxl-fmw.0.size=128G,cxl-fmw.0.interleave-granularity=512
ERST
DEF("M", HAS_ARG, QEMU_OPTION_M,
--
2.34.1
RE: Questions about CXL device (type 3 memory) hotplug
On Mon, May 22, 2023 at 05:11:39PM -0700, Dan Williams wrote: > Yasunori Gotou (Fujitsu) wrote: [...] Hi, all There was some confusions about CXL device hotplug when I recently tried to use Qemu to emulate CXL device hotplug and verify the relevant functions of kernel. > > Q1) Can PCIe hotplug driver detect and call CXL driver? [...] > > Yes. > > The cxl_pci driver (drivers/cxl/pci.c) is just a typical PCI driver as > far as the PCI hotplug driver is concerned. So add/remove events of a > CXL card get turned into probe()/remove() events on the driver. > 1. Can we divide steps of CXL device hotplug into two parts(PCI hotplug & Memory Hotplug)? PCI Hotplug: the same as the native PCIe hotplug, including initializing cxl.io, assigning PCIe BARs, allocating interrupts, etc. And the cxl_pci driver is responsible for this part. Memory Hotplug: focusing on enabling CXL memory including discovering and Configuring HDM, extracting NUMA info from device, notifying memory management, etc. > > > > Q2) Can QEMU/KVM emulate CXL device hotplug? > > > >I heard that QEMU/KVM has PCIe device hotplug emulation, but I'm not sure > >it can hotplug CXL device. > > It can, but as far as the driver is concerned you can achieve the same > by: > > echo $devname > /sys/bus/pci/drivers/cxl_pci/unbind > > ...that exercises the same software flows as physical unplug. > 2. What is the difference between "echo $devname > /sys/bus/pci/drivers/cxl_pci/unbind" and "(qemu) device_del cxl-mem0" ? According to the test, I found that "(qemu) device_del cxl-mem0" would directly unplug the device and cause the interrupts on the cxl root port. It seems like this operation would not only trigger cxl_pci driver but also pcieport driver. The kernel dmesg is like below: (qemu) device_del cxl-mem0 # dmesg [ 699.057907] pcieport :0c:00.0: pciehp: pending interrupts 0x0001 from Slot Status [ 699.058929] pcieport :0c:00.0: pciehp: Slot(0): Button press: will power off in 5 sec [ 699.059986] pcieport :0c:00.0: pciehp: pending interrupts 0x0010 from Slot Status [ 699.060099] pcieport :0c:00.0: pciehp: pciehp_set_indicators: SLOTCTRL 90 write cmd 2c0 Then I also tried "echo $devname > /sys/bus/pci/drivers/cxl_pci/unbind" to check the behaviour of kernel. The kernel dmesg is like below: # echo :0d:00.0 > /sys/bus/pci/drivers/cxl_pci/unbind # dmesg [70387.978931] cxl_pci :0d:00.0: vgaarb: pci_notify [70388.021476] cxl_mem mem0: disconnect mem0 from port1 [70388.033099] pci :0d:00.0: vgaarb: pci_notify It seems like this operation would just unbind the cxl_pci driver from the cxl device. Is my understanding about these two method correct? 3) Can I just use "ndctl/test/cxl-topology.sh" to test the cxl hotplug functions of kernel? IIUC, cxl-topology.sh would utilize cxl_test (tools/testing/cxl) which is for regression testing the kernel-user ABI. PS: My qemu command line: qemu-system-x86_64 \ -M q35,nvdimm=on,cxl=on \ -m 4G \ -smp 4 \ -object memory-backend-ram,size=2G,id=mem0 \ -numa node,nodeid=0,cpus=0-1,memdev=mem0 \ -object memory-backend-ram,size=2G,id=mem1 \ -numa node,nodeid=1,cpus=2-3,memdev=mem1 \ -object memory-backend-ram,size=256M,id=cxl-mem0 \ -device pxb-cxl,bus_nr=12,bus=pcie.0,id=cxl.1 \ -device cxl-rp,port=0,bus=cxl.1,id=root_port0,chassis=0,slot=0 \ -device cxl-type3,bus=root_port0,volatile-memdev=cxl-mem0,id=cxl-mem0 \ -M cxl-fmw.0.targets.0=cxl.1,cxl-fmw.0.size=4G,cxl-fmw.0.interleave-granularity=4k \ -hda ../disk/ubuntu_x86_test_new.qcow2 \ -nographic \ Qemu version: 8.2.50, the lastest commit of branch cxl-2024-03-05 in "https://gitlab.com/jic23/qemu; Kernel version: 6.8.0-rc6 Many thanks Yuquan
[PATCH v2 1/1] cxl/mem: Fix for the index of Clear Event Record Handle
The dev_dbg info for Clear Event Records mailbox command would report
the handle of the next record to clear not the current one.
This was because the index 'i' had incremented before printing the
current handle value.
Signed-off-by: Yuquan Wang
---
drivers/cxl/core/mbox.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/cxl/core/mbox.c b/drivers/cxl/core/mbox.c
index 9adda4795eb7..b810a6aa3010 100644
--- a/drivers/cxl/core/mbox.c
+++ b/drivers/cxl/core/mbox.c
@@ -915,7 +915,7 @@ static int cxl_clear_event_record(struct cxl_memdev_state
*mds,
payload->handles[i++] = gen->hdr.handle;
dev_dbg(mds->cxlds.dev, "Event log '%d': Clearing %u\n", log,
- le16_to_cpu(payload->handles[i]));
+ le16_to_cpu(payload->handles[i-1]));
if (i == max_handles) {
payload->nr_recs = i;
--
2.34.1
[PATCH v2 0/1] cxl/mem: Fix for the index of Clear Event Record Handle
This is a simple fix for the index of 'Clear Event Record' Handle. The
print content of dev_dbg from Clear Event Records mailbox command would
report the handle of the next record to clear not the current one.
The problem was found when I was doing the debug of CXL Event Error on
Qemu. I injected an individual event through QMP
'cxl-inject-general-media-event':
{ "execute": "cxl-inject-general-media-event",
"arguments": {
"path": "/machine/peripheral/cxl-mem0",
"log": "informational",
"flags": 1,
"dpa": 1000,
"descriptor": 3,
"type": 3,
"transaction-type": 192,
"channel": 3,
"device": 5,
"component-id": "iras mem"
}}
Then the kernel printed:
[ 1639.106181] cxl_pci :0d:00.0: Event log '0': Clearing 0
However, the line 36 in 'hw/cxl/cxl-events.c': log->next_handle = 1;
It will set the actual handle value of injected event to '1'.
With this fix, the kernel will print:
[ 122.456750] cxl_pci :0d:00.0: Event log '0': Clearing 1
which is in line with the simulated value in Qemu.
Yuquan Wang (1):
cxl/mem: Fix for the index of Clear Event Record Handle
drivers/cxl/core/mbox.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--
2.34.1
[PATCH 1/1] cxl/mem: Fix for the index of Clear Event Record Handle
The dev_dbg info for Clear Event Records mailbox command would report
the handle of the next record to clear not the current one.
This was because the index 'i' had incremented before printing the
current handle value.
This fix also adjusts the index variable name from 'i' to 'clear_cnt'
which can be easier for developers to distinguish and understand.
Signed-off-by: Yuquan Wang
---
drivers/cxl/core/mbox.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/cxl/core/mbox.c b/drivers/cxl/core/mbox.c
index 9adda4795eb7..3ca2845ae6aa 100644
--- a/drivers/cxl/core/mbox.c
+++ b/drivers/cxl/core/mbox.c
@@ -881,7 +881,7 @@ static int cxl_clear_event_record(struct cxl_memdev_state
*mds,
struct cxl_mbox_cmd mbox_cmd;
u16 cnt;
int rc = 0;
- int i;
+ int clear_cnt;
/* Payload size may limit the max handles */
if (pl_size > mds->payload_size) {
@@ -908,28 +908,29 @@ static int cxl_clear_event_record(struct cxl_memdev_state
*mds,
* Clear Event Records uses u8 for the handle cnt while Get Event
* Record can return up to 0x records.
*/
- i = 0;
+ clear_cnt = 0;
for (cnt = 0; cnt < total; cnt++) {
struct cxl_event_record_raw *raw = _pl->records[cnt];
struct cxl_event_generic *gen = >event.generic;
- payload->handles[i++] = gen->hdr.handle;
+ payload->handles[clear_cnt] = gen->hdr.handle;
dev_dbg(mds->cxlds.dev, "Event log '%d': Clearing %u\n", log,
- le16_to_cpu(payload->handles[i]));
+ le16_to_cpu(payload->handles[clear_cnt]));
- if (i == max_handles) {
- payload->nr_recs = i;
+ clear_cnt++;
+ if (clear_cnt == max_handles) {
+ payload->nr_recs = clear_cnt;
rc = cxl_internal_send_cmd(mds, _cmd);
if (rc)
goto free_pl;
- i = 0;
+ clear_cnt = 0;
}
}
/* Clear what is left if any */
- if (i) {
- payload->nr_recs = i;
- mbox_cmd.size_in = struct_size(payload, handles, i);
+ if (clear_cnt) {
+ payload->nr_recs = clear_cnt;
+ mbox_cmd.size_in = struct_size(payload, handles, clear_cnt);
rc = cxl_internal_send_cmd(mds, _cmd);
if (rc)
goto free_pl;
--
2.34.1
[PATCH 0/1] cxl/mem: Fix for the index of Clear Event Record Handle
This is a simple fix for the index of 'Clear Event Record' Handle. The
print content of dev_dbg from Clear Event Records mailbox command would
report the handle of the next record to clear not the current one.
The problem was found when I was doing the debug of CXL Event Error on
Qemu. I injected an individual event through QMP
'cxl-inject-general-media-event':
{ "execute": "cxl-inject-general-media-event",
"arguments": {
"path": "/machine/peripheral/cxl-mem0",
"log": "informational",
"flags": 1,
"dpa": 1000,
"descriptor": 3,
"type": 3,
"transaction-type": 192,
"channel": 3,
"device": 5,
"component-id": "iras mem"
}}
Then the kernel printed:
[ 1639.106181] cxl_pci :0d:00.0: Event log '0': Clearing 0
However, the line 36 in 'hw/cxl/cxl-events.c': log->next_handle = 1;
It will set the actual handle value of injected event to '1'.
With this fix, the kernel will print:
[ 122.456750] cxl_pci :0d:00.0: Event log '0': Clearing 1
which is in line with the simulated value in Qemu.
Yuquan Wang (1):
cxl/mem: Fix for the index of Clear Event Record Handle
drivers/cxl/core/mbox.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
--
2.34.1
Re: [PATCH v9 0/7] QEMU CXL Provide mock CXL events and irq support
Hello, Jonathan
When during the test of qmps of CXL events like
"cxl-inject-general-media-event",
I am confuesd about the argument "flags". According to "qapi/cxl.json" in qemu,
this argument represents "Event Record Flags" in Common Event Record Format.
However, it seems like the specific 'Event Record Severity' in this field can be
different from the value of 'Event Status' in "Event Status Register".
For instance (take an injection example in the coverlatter):
{ "execute": "cxl-inject-general-media-event",
"arguments": {
"path": "/machine/peripheral/cxl-mem0",
"log": "informational",
"flags": 1,
"dpa": 1000,
"descriptor": 3,
"type": 3,
"transaction-type": 192,
"channel": 3,
"device": 5,
"component-id": "iras mem"
}}
In my understanding, the 'Event Status' is informational and the
'Event Record Severity' is Warning event, which means these two arguments are
independent of each other. Is my understanding correct?
Many thanks
Yuquan
Enabling internal errors for VH CXL devices: [was: Re: Questions about CXL RAS injection test in qemu]
On 2024-03-07 20:10, jonathan.cameron wrote: > Hack is fine the relevant device with lspci -tv and then use > setpci -s 0d:00.0 0x208.l=0 > to clear all the mask bits for uncorrectable errors. Thanks! The suggestions from you and Terry did work! BTW, is my understanding below about CXL RAS correct? >> 2) The error injected by "pcie_aer_inject_error" is "protocol & link errors" >> of cxl.io? >>The error injected by "cxl-inject-uncorrectable-errors" or >> "cxl-inject-correctable-error" is "protocol & link errors" of cxl.cachemem Many thanks Yuuqan
Questions about CXL RAS injection test in qemu
Hello, Jonathan
Recently I met some problems on CXL RAS tests.
I tried to use "cxl-inject-uncorrectable-errors" and
"cxl-inject-correctable-error"
qmp to inject CXL errors, however, there was no any kernel printing information
in
my qemu machine. And the qmp connection was unstable that made the machine
always "terminating on signal 2".
In addition, I successfully used the hmp "pcie_aer_inject_error" in the same
conditions.
The kernel showed relevant print information.
Question:
1) Is my CXL RAS test operations standard?
2) The error injected by "pcie_aer_inject_error" is "protocol & link errors" of
cxl.io?
The error injected by "cxl-inject-uncorrectable-errors" or
"cxl-inject-correctable-error" is "protocol & link errors" of cxl.cachemem?
Hope I can get some helps here, any help will be greatly appreciated.
My qemu command line:
qemu-system-x86_64 \
-M q35,nvdimm=on,cxl=on \
-m 4G \
-smp 4 \
-object memory-backend-ram,size=2G,id=mem0 \
-numa node,nodeid=0,cpus=0-1,memdev=mem0 \
-object memory-backend-ram,size=2G,id=mem1 \
-numa node,nodeid=1,cpus=2-3,memdev=mem1 \
-object memory-backend-ram,size=256M,id=cxl-mem0 \
-device pxb-cxl,bus_nr=12,bus=pcie.0,id=cxl.1 \
-device cxl-rp,port=0,bus=cxl.1,id=root_port0,chassis=0,slot=0 \
-device cxl-type3,bus=root_port0,volatile-memdev=cxl-mem0,id=cxl-mem0 \
-M
cxl-fmw.0.targets.0=cxl.1,cxl-fmw.0.size=4G,cxl-fmw.0.interleave-granularity=4k
\
-hda ../disk/ubuntu_x86_test_new.qcow2 \
-nographic \
-qmp tcp:127.0.0.1:,server,nowait \
Qemu version: 8.2.50, the lastest commit of branch cxl-2024-03-05 in
"https://gitlab.com/jic23/qemu;
Kernel version: 6.8.0-rc6
My steps in the Qemu qmp:
1) telnet 127.0.0.1
result:
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
{"QMP": {"version": {"qemu": {"micro": 50, "minor": 2, "major": 8}, "package":
"v6.2.0-19482-gccfb4fe221"}, "capabilities": ["oob"]}}
2) { "execute": "qmp_capabilities" }
result:
{"return": {}}
3) If inject correctable error:
{ "execute": "cxl-inject-correctable-error",
"arguments": {
"path": "/machine/peripheral/cxl-mem0",
"type": "physical"
} }
result:
{"return": {}}
3) If inject uncorrectable error:
{ "execute": "cxl-inject-uncorrectable-errors",
"arguments": {
"path": "/machine/peripheral/cxl-mem0",
"errors": [
{
"type": "cache-address-parity",
"header": [ 3, 4]
},
{
"type": "cache-data-parity",
"header":
[0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31]
},
{
"type": "internal",
"header": [ 1, 2, 4]
}
]
}}
result:
{"return": {}}
{"timestamp": {"seconds": 1709721640, "microseconds": 275345}, "event":
"SHUTDOWN", "data": {"guest": false, "reason": "host-signal"}}
Many thanks
Yuquan
Re: CXL Namespaces of ACPI disappearing in Qemu demo
Hi, Jonathan On 2023-09-05 22:34, jonathan.cameron wrote: > > As I understand it the distinction is more about the format / contents of > that memory > than how you access them. Yes, RCH DP RCRB includes registers from PCIe Type 1 Config Header and PCIe capabilities and extended capabilities while CHBCR includes component registers with the same layout and discovery mechanism in other CXL components. > As an aside, they are described by a static ACPI table, > so they can't be in the MMIO space used for BARs etc. > In CXL 3.0 Spec, the Figure 9-14 (CXL Link/Protocol Register Mapping in a CXL VH) shows that CHBCR is mapped by "Host Proprietary Static Bar". According to your guidance, it is not a standard PCIe BAR using PCIe MMIO Space, so I understand it is a special BAR for MMIO of a platform device? Many thanks Yuquan
Re: CXL Namespaces of ACPI disappearing in Qemu demo
Hi, Jonathan On 2023-09-04 20:43, jonathan.cameron wrote: > > 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). > > Oh,thanks! According to above, therefore, the core factor is the implementation of RCRB. > > 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. > Here implies that all CXL root bridge will use RCRB registers. From Table 8-17 and Figure 9-14 in CXL3.0 specification, I understood that only RCH DP & RCD UP will use RCRBs, and CXL host bridges VH mode will use other way to realize the CHBCR. I had tried to find more explanation in CXL spec, but I haven't found. Hence this is why I am confused. Many thanks Yuquan
[PATCH 1/1] hw/arm/sbsa-ref: set 'slots' property of xhci
This extends the slots of xhci to 64, since the default xhci_sysbus just supports one slot. Signed-off-by: Wang Yuquan Signed-off-by: Chen Baozi --- hw/arm/sbsa-ref.c | 1 + 1 file changed, 1 insertion(+) diff --git a/hw/arm/sbsa-ref.c b/hw/arm/sbsa-ref.c index 64e1cbce17..bc89eb4806 100644 --- a/hw/arm/sbsa-ref.c +++ b/hw/arm/sbsa-ref.c @@ -611,6 +611,7 @@ static void create_xhci(const SBSAMachineState *sms) hwaddr base = sbsa_ref_memmap[SBSA_XHCI].base; int irq = sbsa_ref_irqmap[SBSA_XHCI]; DeviceState *dev = qdev_new(TYPE_XHCI_SYSBUS); +qdev_prop_set_uint32(dev, "slots", XHCI_MAXSLOTS); sysbus_realize_and_unref(SYS_BUS_DEVICE(dev), _fatal); sysbus_mmio_map(SYS_BUS_DEVICE(dev), 0, base); -- 2.34.1
[PATCH 0/1] hw/arm/sbsa-ref: set 'slots' property of xhci
As the default xhci_sysbus just supports only one usb slot, it can not meet the working requirement of this bord. Therefore, we extend the slots of xhci to 64. Yuquan Wang (1): hw/arm/sbsa-ref: set 'slots' property of xhci hw/arm/sbsa-ref.c | 1 + 1 file changed, 1 insertion(+) -- 2.34.1
[PATCH v5 1/1] hw/arm/sbsa-ref: use XHCI to replace EHCI
The current sbsa-ref cannot use EHCI controller which is only
able to do 32-bit DMA, since sbsa-ref doesn't have RAM below 4GB.
Hence, this uses XHCI to provide a usb controller with 64-bit
DMA capablity instead of EHCI.
Bumping platform version to 0.3 with this change.
Signed-off-by: Yuquan Wang
---
docs/system/arm/sbsa.rst | 2 +-
hw/arm/Kconfig | 2 +-
hw/arm/sbsa-ref.c| 23 +--
3 files changed, 15 insertions(+), 12 deletions(-)
diff --git a/docs/system/arm/sbsa.rst b/docs/system/arm/sbsa.rst
index f571fe645e..f0c809eb60 100644
--- a/docs/system/arm/sbsa.rst
+++ b/docs/system/arm/sbsa.rst
@@ -19,7 +19,7 @@ The ``sbsa-ref`` board supports:
- A configurable number of AArch64 CPUs
- GIC version 3
- System bus AHCI controller
- - System bus EHCI controller
+ - System bus XHCI controller
- CDROM and hard disc on AHCI bus
- E1000E ethernet card on PCIe bus
- Bochs display adapter on PCIe bus
diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
index 7de17d1e8c..7e68348440 100644
--- a/hw/arm/Kconfig
+++ b/hw/arm/Kconfig
@@ -266,7 +266,7 @@ config SBSA_REF
select PL011 # UART
select PL031 # RTC
select PL061 # GPIO
-select USB_EHCI_SYSBUS
+select USB_XHCI_SYSBUS
select WDT_SBSA
select BOCHS_DISPLAY
diff --git a/hw/arm/sbsa-ref.c b/hw/arm/sbsa-ref.c
index de21200ff9..dbd9f89837 100644
--- a/hw/arm/sbsa-ref.c
+++ b/hw/arm/sbsa-ref.c
@@ -40,6 +40,7 @@
#include "hw/pci-host/gpex.h"
#include "hw/qdev-properties.h"
#include "hw/usb.h"
+#include "hw/usb/xhci.h"
#include "hw/char/pl011.h"
#include "hw/watchdog/sbsa_gwdt.h"
#include "net/net.h"
@@ -82,7 +83,7 @@ enum {
SBSA_SECURE_UART_MM,
SBSA_SECURE_MEM,
SBSA_AHCI,
-SBSA_EHCI,
+SBSA_XHCI,
};
struct SBSAMachineState {
@@ -119,7 +120,7 @@ static const MemMapEntry sbsa_ref_memmap[] = {
[SBSA_SMMU] = { 0x6005, 0x0002 },
/* Space here reserved for more SMMUs */
[SBSA_AHCI] = { 0x6010, 0x0001 },
-[SBSA_EHCI] = { 0x6011, 0x0001 },
+[SBSA_XHCI] = { 0x6011, 0x0001 },
/* Space here reserved for other devices */
[SBSA_PCIE_PIO] = { 0x7fff, 0x0001 },
/* 32-bit address PCIE MMIO space */
@@ -139,7 +140,7 @@ static const int sbsa_ref_irqmap[] = {
[SBSA_SECURE_UART] = 8,
[SBSA_SECURE_UART_MM] = 9,
[SBSA_AHCI] = 10,
-[SBSA_EHCI] = 11,
+[SBSA_XHCI] = 11,
[SBSA_SMMU] = 12, /* ... to 15 */
[SBSA_GWDT_WS0] = 16,
};
@@ -219,7 +220,7 @@ static void create_fdt(SBSAMachineState *sms)
*fw compatibility.
*/
qemu_fdt_setprop_cell(fdt, "/", "machine-version-major", 0);
-qemu_fdt_setprop_cell(fdt, "/", "machine-version-minor", 1);
+qemu_fdt_setprop_cell(fdt, "/", "machine-version-minor", 3);
if (ms->numa_state->have_numa_distance) {
int size = nb_numa_nodes * nb_numa_nodes * 3 * sizeof(uint32_t);
@@ -575,13 +576,15 @@ static void create_ahci(const SBSAMachineState *sms)
}
}
-static void create_ehci(const SBSAMachineState *sms)
+static void create_xhci(const SBSAMachineState *sms)
{
-hwaddr base = sbsa_ref_memmap[SBSA_EHCI].base;
-int irq = sbsa_ref_irqmap[SBSA_EHCI];
+hwaddr base = sbsa_ref_memmap[SBSA_XHCI].base;
+int irq = sbsa_ref_irqmap[SBSA_XHCI];
+DeviceState *dev = qdev_new(TYPE_XHCI_SYSBUS);
-sysbus_create_simple("platform-ehci-usb", base,
- qdev_get_gpio_in(sms->gic, irq));
+sysbus_realize_and_unref(SYS_BUS_DEVICE(dev), _fatal);
+sysbus_mmio_map(SYS_BUS_DEVICE(dev), 0, base);
+sysbus_connect_irq(SYS_BUS_DEVICE(dev), 0, qdev_get_gpio_in(sms->gic,
irq));
}
static void create_smmu(const SBSAMachineState *sms, PCIBus *bus)
@@ -803,7 +806,7 @@ static void sbsa_ref_init(MachineState *machine)
create_ahci(sms);
-create_ehci(sms);
+create_xhci(sms);
create_pcie(sms);
--
2.34.1
[PATCH v5 0/1] hw/arm/sbsa-ref: use XHCI to replace EHCI
Please review the change. - sbsa-ref: Replace EHCI with XHCI on sysbus. This work bumps the platform version directly to 0.3 because the addition of ITS will take sbsa-ref to 0.2 version. Yuquan Wang (1): hw/arm/sbsa-ref: use XHCI to replace EHCI docs/system/arm/sbsa.rst | 2 +- hw/arm/Kconfig | 2 +- hw/arm/sbsa-ref.c| 23 +-- 3 files changed, 15 insertions(+), 12 deletions(-) -- 2.34.1
Re: [PATCH v4 1/1] hw/arm/sbsa-ref: use XHCI to replace EHCI
On 2023-06-21 01:24, Leif wrote: > Leif, do you think we should bump the minor version here? I think that makes sense, yes. / Leif Thanks for everyone's guidance. There is a new confusion: Which minor version should I bump to (2 or 3) ? As I found that Marcin’s latest patch (add ITS support in SBSA GIC https://lists.nongnu.org/archive/html/qemu-arm/2023-06/msg00709.html ) increased the minor version to 2. Many thanks Yuquan
A confusion about CXL in arm virt machine
Hi, Gregory There is one confusion about CXL in QEMU I hope to consult. If you have some time to look at this email, I would have better understanding of CXL emulation in QEMU. On docs/system/devices/cxl.rst , Gregory wrote: A very simple setup with just one directly attached CXL Type 3 Volatile Memory device:: qemu-system-aarch64 -M virt,gic-version=3,cxl=on -m 4g,maxmem=8G,slots=8 -cpu max \ .. As the current master branch of QEMU has not yet complemented the CXL option/expansion in arm virt machine, how this example command lines worked? Or here used another branch rather than master? Many thanks Yuquan
[PATCH v4 0/1] use XHCI to replace EHCI
Please review the change. - sbsa-ref: Replace EHCI with XHCI on sysbus. This version updates relevant Kconfig and sbsa.rst file. Yuquan Wang (1): hw/arm/sbsa-ref: use XHCI to replace EHCI docs/system/arm/sbsa.rst | 2 +- hw/arm/Kconfig | 2 +- hw/arm/sbsa-ref.c| 21 - 3 files changed, 14 insertions(+), 11 deletions(-) -- 2.34.1
[PATCH v4 1/1] hw/arm/sbsa-ref: use XHCI to replace EHCI
The current sbsa-ref cannot use EHCI controller which is only
able to do 32-bit DMA, since sbsa-ref doesn't have RAM below 4GB.
Hence, this uses system bus XHCI to provide a usb controller with
64-bit DMA capablity instead of EHCI.
Signed-off-by: Yuquan Wang
---
docs/system/arm/sbsa.rst | 2 +-
hw/arm/Kconfig | 2 +-
hw/arm/sbsa-ref.c| 21 -
3 files changed, 14 insertions(+), 11 deletions(-)
diff --git a/docs/system/arm/sbsa.rst b/docs/system/arm/sbsa.rst
index 016776aed8..1751ba0d21 100644
--- a/docs/system/arm/sbsa.rst
+++ b/docs/system/arm/sbsa.rst
@@ -24,7 +24,7 @@ The sbsa-ref board supports:
- A configurable number of AArch64 CPUs
- GIC version 3
- System bus AHCI controller
- - System bus EHCI controller
+ - System bus XHCI controller
- CDROM and hard disc on AHCI bus
- E1000E ethernet card on PCIe bus
- Bochs display adapter on PCIe bus
diff --git a/hw/arm/Kconfig b/hw/arm/Kconfig
index acc4371a4a..ab884ad319 100644
--- a/hw/arm/Kconfig
+++ b/hw/arm/Kconfig
@@ -266,7 +266,7 @@ config SBSA_REF
select PL011 # UART
select PL031 # RTC
select PL061 # GPIO
-select USB_EHCI_SYSBUS
+select USB_XHCI_SYSBUS
select WDT_SBSA
config SABRELITE
diff --git a/hw/arm/sbsa-ref.c b/hw/arm/sbsa-ref.c
index de21200ff9..4fb65704d4 100644
--- a/hw/arm/sbsa-ref.c
+++ b/hw/arm/sbsa-ref.c
@@ -40,6 +40,7 @@
#include "hw/pci-host/gpex.h"
#include "hw/qdev-properties.h"
#include "hw/usb.h"
+#include "hw/usb/xhci.h"
#include "hw/char/pl011.h"
#include "hw/watchdog/sbsa_gwdt.h"
#include "net/net.h"
@@ -82,7 +83,7 @@ enum {
SBSA_SECURE_UART_MM,
SBSA_SECURE_MEM,
SBSA_AHCI,
-SBSA_EHCI,
+SBSA_XHCI,
};
struct SBSAMachineState {
@@ -119,7 +120,7 @@ static const MemMapEntry sbsa_ref_memmap[] = {
[SBSA_SMMU] = { 0x6005, 0x0002 },
/* Space here reserved for more SMMUs */
[SBSA_AHCI] = { 0x6010, 0x0001 },
-[SBSA_EHCI] = { 0x6011, 0x0001 },
+[SBSA_XHCI] = { 0x6011, 0x0001 },
/* Space here reserved for other devices */
[SBSA_PCIE_PIO] = { 0x7fff, 0x0001 },
/* 32-bit address PCIE MMIO space */
@@ -139,7 +140,7 @@ static const int sbsa_ref_irqmap[] = {
[SBSA_SECURE_UART] = 8,
[SBSA_SECURE_UART_MM] = 9,
[SBSA_AHCI] = 10,
-[SBSA_EHCI] = 11,
+[SBSA_XHCI] = 11,
[SBSA_SMMU] = 12, /* ... to 15 */
[SBSA_GWDT_WS0] = 16,
};
@@ -575,13 +576,15 @@ static void create_ahci(const SBSAMachineState *sms)
}
}
-static void create_ehci(const SBSAMachineState *sms)
+static void create_xhci(const SBSAMachineState *sms)
{
-hwaddr base = sbsa_ref_memmap[SBSA_EHCI].base;
-int irq = sbsa_ref_irqmap[SBSA_EHCI];
+hwaddr base = sbsa_ref_memmap[SBSA_XHCI].base;
+int irq = sbsa_ref_irqmap[SBSA_XHCI];
+DeviceState *dev = qdev_new(TYPE_XHCI_SYSBUS);
-sysbus_create_simple("platform-ehci-usb", base,
- qdev_get_gpio_in(sms->gic, irq));
+sysbus_realize_and_unref(SYS_BUS_DEVICE(dev), _fatal);
+sysbus_mmio_map(SYS_BUS_DEVICE(dev), 0, base);
+sysbus_connect_irq(SYS_BUS_DEVICE(dev), 0, qdev_get_gpio_in(sms->gic,
irq));
}
static void create_smmu(const SBSAMachineState *sms, PCIBus *bus)
@@ -803,7 +806,7 @@ static void sbsa_ref_init(MachineState *machine)
create_ahci(sms);
-create_ehci(sms);
+create_xhci(sms);
create_pcie(sms);
--
2.34.1
Re: [PATCH v3 1/1] hw/arm/sbsa-ref: use XHCI to replace EHCI
Hi, Marcin On Mon, 5 Jun 2023 11:59:16 +0200, Marcin Juszkiewicz wrote: > > W dniu 5.06.2023 o 11:55, Yuquan Wang pisze: > > The current sbsa-ref cannot use EHCI controller which is only > > able to do 32-bit DMA, since sbsa-ref doesn't have RAM below 4GB. > > Hence, this uses XHCI to provide a usb controller with 64-bit > > DMA capablity instead of EHCI. > > > > Signed-off-by: Yuquan Wang > > Can you share firmware side so it can be tested? > > The more I deal with EDK2 the more I understand why people go U-Boot. I figured out the stuck problem of the relevant firmware patch in edk2 mail list. Below is the patchset link: https://edk2.groups.io/g/devel/message/105713 Thanks Yuquan 信息安全声明：本邮件包含信息归发件人所在组织所有,发件人所在组织对该邮件拥有所有权利。请接收者注意保密,未经发件人书面许可,不得向任何第三方组织和个人透露本邮件所含信息。 Information Security Notice: The information contained in this mail is solely property of the sender's organization.This mail communication is confidential.Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
[PATCH v3 0/1] use XHCI to replace EHCI
Please review the change. - sbsa-ref: Replace EHCI with XHCI on sysbus. Yuquan Wang (1): hw/arm/sbsa-ref: use XHCI to replace EHCI hw/arm/sbsa-ref.c | 21 - 1 file changed, 12 insertions(+), 9 deletions(-) -- 2.34.1
[PATCH v3 1/1] hw/arm/sbsa-ref: use XHCI to replace EHCI
The current sbsa-ref cannot use EHCI controller which is only
able to do 32-bit DMA, since sbsa-ref doesn't have RAM below 4GB.
Hence, this uses XHCI to provide a usb controller with 64-bit
DMA capablity instead of EHCI.
Signed-off-by: Yuquan Wang
---
hw/arm/sbsa-ref.c | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/hw/arm/sbsa-ref.c b/hw/arm/sbsa-ref.c
index de21200ff9..4fb65704d4 100644
--- a/hw/arm/sbsa-ref.c
+++ b/hw/arm/sbsa-ref.c
@@ -40,6 +40,7 @@
#include "hw/pci-host/gpex.h"
#include "hw/qdev-properties.h"
#include "hw/usb.h"
+#include "hw/usb/xhci.h"
#include "hw/char/pl011.h"
#include "hw/watchdog/sbsa_gwdt.h"
#include "net/net.h"
@@ -82,7 +83,7 @@ enum {
SBSA_SECURE_UART_MM,
SBSA_SECURE_MEM,
SBSA_AHCI,
-SBSA_EHCI,
+SBSA_XHCI,
};
struct SBSAMachineState {
@@ -119,7 +120,7 @@ static const MemMapEntry sbsa_ref_memmap[] = {
[SBSA_SMMU] = { 0x6005, 0x0002 },
/* Space here reserved for more SMMUs */
[SBSA_AHCI] = { 0x6010, 0x0001 },
-[SBSA_EHCI] = { 0x6011, 0x0001 },
+[SBSA_XHCI] = { 0x6011, 0x0001 },
/* Space here reserved for other devices */
[SBSA_PCIE_PIO] = { 0x7fff, 0x0001 },
/* 32-bit address PCIE MMIO space */
@@ -139,7 +140,7 @@ static const int sbsa_ref_irqmap[] = {
[SBSA_SECURE_UART] = 8,
[SBSA_SECURE_UART_MM] = 9,
[SBSA_AHCI] = 10,
-[SBSA_EHCI] = 11,
+[SBSA_XHCI] = 11,
[SBSA_SMMU] = 12, /* ... to 15 */
[SBSA_GWDT_WS0] = 16,
};
@@ -575,13 +576,15 @@ static void create_ahci(const SBSAMachineState *sms)
}
}
-static void create_ehci(const SBSAMachineState *sms)
+static void create_xhci(const SBSAMachineState *sms)
{
-hwaddr base = sbsa_ref_memmap[SBSA_EHCI].base;
-int irq = sbsa_ref_irqmap[SBSA_EHCI];
+hwaddr base = sbsa_ref_memmap[SBSA_XHCI].base;
+int irq = sbsa_ref_irqmap[SBSA_XHCI];
+DeviceState *dev = qdev_new(TYPE_XHCI_SYSBUS);
-sysbus_create_simple("platform-ehci-usb", base,
- qdev_get_gpio_in(sms->gic, irq));
+sysbus_realize_and_unref(SYS_BUS_DEVICE(dev), _fatal);
+sysbus_mmio_map(SYS_BUS_DEVICE(dev), 0, base);
+sysbus_connect_irq(SYS_BUS_DEVICE(dev), 0, qdev_get_gpio_in(sms->gic,
irq));
}
static void create_smmu(const SBSAMachineState *sms, PCIBus *bus)
@@ -803,7 +806,7 @@ static void sbsa_ref_init(MachineState *machine)
create_ahci(sms);
-create_ehci(sms);
+create_xhci(sms);
create_pcie(sms);
--
2.34.1
Re: [PATCH 1/1] hw/arm/sbsa-ref: use XHCI to replace EHCI
Hi, Leif On Thu, 1 Jun 2023 18:59:56 +0100, Leif Lindholm wrote: > > +Ard > > On Thu, Jun 01, 2023 at 16:01:43 +0100, Peter Maydell wrote: > > > >> Also has EHCI never worked, or has it worked in some modes and so this > > > >> change should be versioned? > > > > > > > > AIUI, EHCI has never worked and can never have worked, because > > > > this board's RAM is all above 4G and the QEMU EHCI controller > > > > implementation only allows DMA descriptors with 32-bit addresses. > > > > > > > > Looking back at the archives, it seems we discussed XHCI vs > > > > EHCI when the sbsa-ref board went in, and the conclusion was > > > > that XHCI would be better. But there wasn't a sysbus XHCI device > > > > at that point, so we ended up committing the sbsa-ref board > > > > with EHCI and a plan to switch to XHCI when the sysbus-xhci > > > > device was done, which we then forgot about: > > > > https://mail.gnu.org/archive/html/qemu-arm/2018-11/msg00638.html > > > > > > Ah, thanks! That explains why we did the thing that made no sense :) > > > > > > To skip the migration hazard, my prefernece is we just leave the EHCI > > > device in for now, and add a separate XHCI on PCIe. We can drop the > > > EHCI device at some point in the future. > > > > Why PCIe for the XHCI and not sysbus? At the time the board > > was originally added the argument was in favour of using > > a sysbus USB controller (you can see Ard making that point > > in the linked archive thread). > > The original argument was that having the device on the sysbus > 1) enabled codepaths we wanted to exercise and Sorry, for my poor engineering experience, I am confused about the meaning of "enabled codepaths" here. Is it like a code target that to realize the original purpose of this board ? Yuquan 信息安全声明：本邮件包含信息归发件人所在组织所有,发件人所在组织对该邮件拥有所有权利。请接收者注意保密,未经发件人书面许可,不得向任何第三方组织和个人透露本邮件所含信息。 Information Security Notice: The information contained in this mail is solely property of the sender's organization.This mail communication is confidential.Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
[PATCH v2 0/1] hw/arm/sbsa-ref: add XHCI controller on PCIe
Please review the change. - sbsa-ref: Add an XHCI on PCIe bus to provide an availiable usb controller. Yuquan Wang (1): hw/arm/sbsa-ref: add XHCI controller on PCIe hw/arm/sbsa-ref.c | 2 ++ 1 file changed, 2 insertions(+) -- 2.34.1
[PATCH v2 1/1] hw/arm/sbsa-ref: add XHCI controller on PCIe
The current sbsa-ref cannot use EHCI controller which is only able to do 32-bit DMA, since sbsa-ref doesn't have RAM below 4GB. Hence, this add an XHCI on PCIe to provide a usb controller with 64-bit DMA capablity. Signed-off-by: Yuquan Wang --- hw/arm/sbsa-ref.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/hw/arm/sbsa-ref.c b/hw/arm/sbsa-ref.c index de21200ff9..a33cd80d69 100644 --- a/hw/arm/sbsa-ref.c +++ b/hw/arm/sbsa-ref.c @@ -668,6 +668,8 @@ static void create_pcie(SBSAMachineState *sms) pci_create_simple(pci->bus, -1, "bochs-display"); +pci_create_simple(pci->bus, -1, "qemu-xhci"); + create_smmu(sms, pci->bus); } -- 2.34.1
[PATCH v1 1/1] hw/arm/sbsa-ref: use XHCI to replace EHCI
The current sbsa-ref cannot use EHCI controller which is only
able to do 32-bit DMA, since sbsa-ref doesn't have RAM below 4GB.
Hence, this uses XHCI to provide a usb controller with 64-bit
DMA capablity instead of EHCI.
Signed-off-by: Yuquan Wang
Change-Id: I1376f8bbc0e25dcd9d8a22b6e061cb56b3486394
---
hw/arm/sbsa-ref.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/hw/arm/sbsa-ref.c b/hw/arm/sbsa-ref.c
index de21200ff9..4c9a942a63 100644
--- a/hw/arm/sbsa-ref.c
+++ b/hw/arm/sbsa-ref.c
@@ -82,7 +82,7 @@ enum {
SBSA_SECURE_UART_MM,
SBSA_SECURE_MEM,
SBSA_AHCI,
-SBSA_EHCI,
+SBSA_XHCI,
};
struct SBSAMachineState {
@@ -119,7 +119,7 @@ static const MemMapEntry sbsa_ref_memmap[] = {
[SBSA_SMMU] = { 0x6005, 0x0002 },
/* Space here reserved for more SMMUs */
[SBSA_AHCI] = { 0x6010, 0x0001 },
-[SBSA_EHCI] = { 0x6011, 0x0001 },
+[SBSA_XHCI] = { 0x6011, 0x0001 },
/* Space here reserved for other devices */
[SBSA_PCIE_PIO] = { 0x7fff, 0x0001 },
/* 32-bit address PCIE MMIO space */
@@ -139,7 +139,7 @@ static const int sbsa_ref_irqmap[] = {
[SBSA_SECURE_UART] = 8,
[SBSA_SECURE_UART_MM] = 9,
[SBSA_AHCI] = 10,
-[SBSA_EHCI] = 11,
+[SBSA_XHCI] = 11,
[SBSA_SMMU] = 12, /* ... to 15 */
[SBSA_GWDT_WS0] = 16,
};
@@ -575,12 +575,12 @@ static void create_ahci(const SBSAMachineState *sms)
}
}
-static void create_ehci(const SBSAMachineState *sms)
+static void create_xhci(const SBSAMachineState *sms)
{
-hwaddr base = sbsa_ref_memmap[SBSA_EHCI].base;
-int irq = sbsa_ref_irqmap[SBSA_EHCI];
+hwaddr base = sbsa_ref_memmap[SBSA_XHCI].base;
+int irq = sbsa_ref_irqmap[SBSA_XHCI];
-sysbus_create_simple("platform-ehci-usb", base,
+sysbus_create_simple("sysbus-xhci", base,
qdev_get_gpio_in(sms->gic, irq));
}
@@ -803,7 +803,7 @@ static void sbsa_ref_init(MachineState *machine)
create_ahci(sms);
-create_ehci(sms);
+create_xhci(sms);
create_pcie(sms);
--
2.34.1
[PATCH v1 0/1] hw/arm/sbsa-ref: use XHCI to replace EHCI
Please review the change. - Replace EHCI with XHCI on sbsa-ref board. v1 patchset has fixed my commit rebase problem in the last version. Yuquan Wang (1): hw/arm/sbsa-ref: use XHCI to replace EHCI hw/arm/sbsa-ref.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) -- 2.34.1
