在 2025/7/15 16:57, Peter Maydell 写道:
On Tue, 15 Jul 2025 at 08:33, zhangzhijie <zhangzhi...@bosc.ac.cn> wrote:
0. DW pcie support 64bit resource
1. DW version type using Linux kernel
Signed-off-by: zhangzhijie <zhangzhi...@bosc.ac.cn>
---
hw/pci-host/designware.c | 12 +++++++++---
include/hw/pci-host/designware.h | 2 +-
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/hw/pci-host/designware.c b/hw/pci-host/designware.c
index f6e49ce9b8..99d791c0a7 100644
--- a/hw/pci-host/designware.c
+++ b/hw/pci-host/designware.c
@@ -41,6 +41,8 @@
#define DESIGNWARE_PCIE_MSI_INTR0_ENABLE 0x828
#define DESIGNWARE_PCIE_MSI_INTR0_MASK 0x82C
#define DESIGNWARE_PCIE_MSI_INTR0_STATUS 0x830
+#define PCIE_VERSION_NUMBER 0x8F8
+#define PCIE_VERSION_TYPE 0x8FC
#define DESIGNWARE_PCIE_ATU_VIEWPORT 0x900
#define DESIGNWARE_PCIE_ATU_REGION_INBOUND BIT(31)
#define DESIGNWARE_PCIE_ATU_CR1 0x904
@@ -144,6 +146,10 @@ designware_pcie_root_config_read(PCIDevice *d, uint32_t
address, int len)
uint32_t val;
switch (address) {
+ case PCIE_VERSION_NUMBER:
+ case PCIE_VERSION_TYPE:
+ val = 0x3534302a;
What is this magic number ?
Fount this magic number at Linux Kernel Driver:
drivers/pci/controller/dwc/pcie-designware.h
Using thismagic number will allow Linux driver using larger than
u32_max(4GB) resources . But I am not take tests for imx.6/imx.7
+ break;
case DESIGNWARE_PCIE_PORT_LINK_CONTROL:
/*
* Linux guest uses this register only to configure number of
@@ -427,7 +433,7 @@ static void designware_pcie_root_realize(PCIDevice *dev,
Error **errp)
viewport->inbound = true;
viewport->base = 0x0000000000000000ULL;
viewport->target = 0x0000000000000000ULL;
- viewport->limit = UINT32_MAX;
+ viewport->limit = UINT64_MAX;
viewport->cr[0] = DESIGNWARE_PCIE_ATU_TYPE_MEM;
source = &host->pci.address_space_root;
@@ -451,7 +457,7 @@ static void designware_pcie_root_realize(PCIDevice *dev,
Error **errp)
viewport->inbound = false;
viewport->base = 0x0000000000000000ULL;
viewport->target = 0x0000000000000000ULL;
- viewport->limit = UINT32_MAX;
+ viewport->limit = UINT64_MAX;
viewport->cr[0] = DESIGNWARE_PCIE_ATU_TYPE_MEM;
destination = &host->pci.memory;
@@ -558,7 +564,7 @@ static const VMStateDescription
vmstate_designware_pcie_viewport = {
.fields = (const VMStateField[]) {
VMSTATE_UINT64(base, DesignwarePCIEViewport),
VMSTATE_UINT64(target, DesignwarePCIEViewport),
- VMSTATE_UINT32(limit, DesignwarePCIEViewport),
+ VMSTATE_UINT64(limit, DesignwarePCIEViewport),
VMSTATE_UINT32_ARRAY(cr, DesignwarePCIEViewport, 2),
VMSTATE_END_OF_LIST()
}
This breaks migration compatibility. Depending on which boards
use this you might either need to just bump the version numbers,
or else do something more elaborate to ensure migration compat.
could I found that if the Uint64 type is used, it can be compatible with
scenarios where uint32 was originally used?
diff --git a/include/hw/pci-host/designware.h b/include/hw/pci-host/designware.h
index a35a3bd06c..6e06f54801 100644
--- a/include/hw/pci-host/designware.h
+++ b/include/hw/pci-host/designware.h
@@ -46,7 +46,7 @@ typedef struct DesignwarePCIEViewport {
uint64_t base;
uint64_t target;
- uint32_t limit;
+ uint64_t limit;
uint32_t cr[2];
Last time that something related to this pci controller
and the size of this limit came up, this appeared to be
something that differed between different versions of the
hardware. See discussions on the thread in
https://lore.kernel.org/qemu-devel/cafeaca_x4cyq0wf7-x-4oq4ouysujcbl3xlrz3d0cmwymfs...@mail.gmail.com/
Maybe we need to model both, with a device property to
select which one?
Could understand to "set magic-number and using magic number to select
VMStateDescription_u32 or VMStateDescription_u64 " ?
thanks
-- PMM
Best Regards.
ZhiJie
