2022-04-29 16:40:27 +02:00
|
|
|
/*
|
|
|
|
|
* QEMU CXL Support
|
|
|
|
|
*
|
|
|
|
|
* Copyright (c) 2020 Intel
|
|
|
|
|
*
|
|
|
|
|
* This work is licensed under the terms of the GNU GPL, version 2. See the
|
|
|
|
|
* COPYING file in the top-level directory.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#ifndef CXL_H
|
|
|
|
|
#define CXL_H
|
|
|
|
|
|
hw/cxl/host: Add support for CXL Fixed Memory Windows.
The concept of these is introduced in [1] in terms of the
description the CEDT ACPI table. The principal is more general.
Unlike once traffic hits the CXL root bridges, the host system
memory address routing is implementation defined and effectively
static once observable by standard / generic system software.
Each CXL Fixed Memory Windows (CFMW) is a region of PA space
which has fixed system dependent routing configured so that
accesses can be routed to the CXL devices below a set of target
root bridges. The accesses may be interleaved across multiple
root bridges.
For QEMU we could have fully specified these regions in terms
of a base PA + size, but as the absolute address does not matter
it is simpler to let individual platforms place the memory regions.
ExampleS:
-cxl-fixed-memory-window targets.0=cxl.0,size=128G
-cxl-fixed-memory-window targets.0=cxl.1,size=128G
-cxl-fixed-memory-window targets.0=cxl0,targets.1=cxl.1,size=256G,interleave-granularity=2k
Specifies
* 2x 128G regions not interleaved across root bridges, one for each of
the root bridges with ids cxl.0 and cxl.1
* 256G region interleaved across root bridges with ids cxl.0 and cxl.1
with a 2k interleave granularity.
When system software enumerates the devices below a given root bridge
it can then decide which CFMW to use. If non interleave is desired
(or possible) it can use the appropriate CFMW for the root bridge in
question. If there are suitable devices to interleave across the
two root bridges then it may use the 3rd CFMS.
A number of other designs were considered but the following constraints
made it hard to adapt existing QEMU approaches to this particular problem.
1) The size must be known before a specific architecture / board brings
up it's PA memory map. We need to set up an appropriate region.
2) Using links to the host bridges provides a clean command line interface
but these links cannot be established until command line devices have
been added.
Hence the two step process used here of first establishing the size,
interleave-ways and granularity + caching the ids of the host bridges
and then, once available finding the actual host bridges so they can
be used later to support interleave decoding.
[1] CXL 2.0 ECN: CEDT CFMWS & QTG DSM (computeexpresslink.org / specifications)
Signed-off-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Acked-by: Markus Armbruster <armbru@redhat.com> # QAPI Schema
Message-Id: <20220429144110.25167-28-Jonathan.Cameron@huawei.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-04-29 16:40:52 +02:00
|
|
|
|
|
|
|
|
#include "qapi/qapi-types-machine.h"
|
2022-06-08 16:54:33 +02:00
|
|
|
#include "qapi/qapi-visit-machine.h"
|
2022-04-29 16:40:48 +02:00
|
|
|
#include "hw/pci/pci_host.h"
|
2022-04-29 16:40:27 +02:00
|
|
|
#include "cxl_pci.h"
|
|
|
|
|
#include "cxl_component.h"
|
2022-04-29 16:40:29 +02:00
|
|
|
#include "cxl_device.h"
|
2022-04-29 16:40:27 +02:00
|
|
|
|
2023-05-26 19:00:08 +02:00
|
|
|
#define CXL_CACHE_LINE_SIZE 64
|
2022-04-29 16:40:31 +02:00
|
|
|
#define CXL_COMPONENT_REG_BAR_IDX 0
|
|
|
|
|
#define CXL_DEVICE_REG_BAR_IDX 2
|
|
|
|
|
|
2022-04-29 16:40:48 +02:00
|
|
|
#define CXL_WINDOW_MAX 10
|
|
|
|
|
|
2023-04-20 16:27:50 +02:00
|
|
|
typedef struct PXBCXLDev PXBCXLDev;
|
2022-12-22 11:03:25 +01:00
|
|
|
|
hw/cxl/host: Add support for CXL Fixed Memory Windows.
The concept of these is introduced in [1] in terms of the
description the CEDT ACPI table. The principal is more general.
Unlike once traffic hits the CXL root bridges, the host system
memory address routing is implementation defined and effectively
static once observable by standard / generic system software.
Each CXL Fixed Memory Windows (CFMW) is a region of PA space
which has fixed system dependent routing configured so that
accesses can be routed to the CXL devices below a set of target
root bridges. The accesses may be interleaved across multiple
root bridges.
For QEMU we could have fully specified these regions in terms
of a base PA + size, but as the absolute address does not matter
it is simpler to let individual platforms place the memory regions.
ExampleS:
-cxl-fixed-memory-window targets.0=cxl.0,size=128G
-cxl-fixed-memory-window targets.0=cxl.1,size=128G
-cxl-fixed-memory-window targets.0=cxl0,targets.1=cxl.1,size=256G,interleave-granularity=2k
Specifies
* 2x 128G regions not interleaved across root bridges, one for each of
the root bridges with ids cxl.0 and cxl.1
* 256G region interleaved across root bridges with ids cxl.0 and cxl.1
with a 2k interleave granularity.
When system software enumerates the devices below a given root bridge
it can then decide which CFMW to use. If non interleave is desired
(or possible) it can use the appropriate CFMW for the root bridge in
question. If there are suitable devices to interleave across the
two root bridges then it may use the 3rd CFMS.
A number of other designs were considered but the following constraints
made it hard to adapt existing QEMU approaches to this particular problem.
1) The size must be known before a specific architecture / board brings
up it's PA memory map. We need to set up an appropriate region.
2) Using links to the host bridges provides a clean command line interface
but these links cannot be established until command line devices have
been added.
Hence the two step process used here of first establishing the size,
interleave-ways and granularity + caching the ids of the host bridges
and then, once available finding the actual host bridges so they can
be used later to support interleave decoding.
[1] CXL 2.0 ECN: CEDT CFMWS & QTG DSM (computeexpresslink.org / specifications)
Signed-off-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Acked-by: Markus Armbruster <armbru@redhat.com> # QAPI Schema
Message-Id: <20220429144110.25167-28-Jonathan.Cameron@huawei.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-04-29 16:40:52 +02:00
|
|
|
typedef struct CXLFixedWindow {
|
|
|
|
|
uint64_t size;
|
|
|
|
|
char **targets;
|
2023-09-19 12:19:25 +02:00
|
|
|
PXBCXLDev *target_hbs[16];
|
hw/cxl/host: Add support for CXL Fixed Memory Windows.
The concept of these is introduced in [1] in terms of the
description the CEDT ACPI table. The principal is more general.
Unlike once traffic hits the CXL root bridges, the host system
memory address routing is implementation defined and effectively
static once observable by standard / generic system software.
Each CXL Fixed Memory Windows (CFMW) is a region of PA space
which has fixed system dependent routing configured so that
accesses can be routed to the CXL devices below a set of target
root bridges. The accesses may be interleaved across multiple
root bridges.
For QEMU we could have fully specified these regions in terms
of a base PA + size, but as the absolute address does not matter
it is simpler to let individual platforms place the memory regions.
ExampleS:
-cxl-fixed-memory-window targets.0=cxl.0,size=128G
-cxl-fixed-memory-window targets.0=cxl.1,size=128G
-cxl-fixed-memory-window targets.0=cxl0,targets.1=cxl.1,size=256G,interleave-granularity=2k
Specifies
* 2x 128G regions not interleaved across root bridges, one for each of
the root bridges with ids cxl.0 and cxl.1
* 256G region interleaved across root bridges with ids cxl.0 and cxl.1
with a 2k interleave granularity.
When system software enumerates the devices below a given root bridge
it can then decide which CFMW to use. If non interleave is desired
(or possible) it can use the appropriate CFMW for the root bridge in
question. If there are suitable devices to interleave across the
two root bridges then it may use the 3rd CFMS.
A number of other designs were considered but the following constraints
made it hard to adapt existing QEMU approaches to this particular problem.
1) The size must be known before a specific architecture / board brings
up it's PA memory map. We need to set up an appropriate region.
2) Using links to the host bridges provides a clean command line interface
but these links cannot be established until command line devices have
been added.
Hence the two step process used here of first establishing the size,
interleave-ways and granularity + caching the ids of the host bridges
and then, once available finding the actual host bridges so they can
be used later to support interleave decoding.
[1] CXL 2.0 ECN: CEDT CFMWS & QTG DSM (computeexpresslink.org / specifications)
Signed-off-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Acked-by: Markus Armbruster <armbru@redhat.com> # QAPI Schema
Message-Id: <20220429144110.25167-28-Jonathan.Cameron@huawei.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-04-29 16:40:52 +02:00
|
|
|
uint8_t num_targets;
|
|
|
|
|
uint8_t enc_int_ways;
|
|
|
|
|
uint8_t enc_int_gran;
|
|
|
|
|
/* Todo: XOR based interleaving */
|
|
|
|
|
MemoryRegion mr;
|
|
|
|
|
hwaddr base;
|
|
|
|
|
} CXLFixedWindow;
|
|
|
|
|
|
2022-04-29 16:40:38 +02:00
|
|
|
typedef struct CXLState {
|
|
|
|
|
bool is_enabled;
|
2022-04-29 16:40:48 +02:00
|
|
|
MemoryRegion host_mr;
|
|
|
|
|
unsigned int next_mr_idx;
|
hw/cxl/host: Add support for CXL Fixed Memory Windows.
The concept of these is introduced in [1] in terms of the
description the CEDT ACPI table. The principal is more general.
Unlike once traffic hits the CXL root bridges, the host system
memory address routing is implementation defined and effectively
static once observable by standard / generic system software.
Each CXL Fixed Memory Windows (CFMW) is a region of PA space
which has fixed system dependent routing configured so that
accesses can be routed to the CXL devices below a set of target
root bridges. The accesses may be interleaved across multiple
root bridges.
For QEMU we could have fully specified these regions in terms
of a base PA + size, but as the absolute address does not matter
it is simpler to let individual platforms place the memory regions.
ExampleS:
-cxl-fixed-memory-window targets.0=cxl.0,size=128G
-cxl-fixed-memory-window targets.0=cxl.1,size=128G
-cxl-fixed-memory-window targets.0=cxl0,targets.1=cxl.1,size=256G,interleave-granularity=2k
Specifies
* 2x 128G regions not interleaved across root bridges, one for each of
the root bridges with ids cxl.0 and cxl.1
* 256G region interleaved across root bridges with ids cxl.0 and cxl.1
with a 2k interleave granularity.
When system software enumerates the devices below a given root bridge
it can then decide which CFMW to use. If non interleave is desired
(or possible) it can use the appropriate CFMW for the root bridge in
question. If there are suitable devices to interleave across the
two root bridges then it may use the 3rd CFMS.
A number of other designs were considered but the following constraints
made it hard to adapt existing QEMU approaches to this particular problem.
1) The size must be known before a specific architecture / board brings
up it's PA memory map. We need to set up an appropriate region.
2) Using links to the host bridges provides a clean command line interface
but these links cannot be established until command line devices have
been added.
Hence the two step process used here of first establishing the size,
interleave-ways and granularity + caching the ids of the host bridges
and then, once available finding the actual host bridges so they can
be used later to support interleave decoding.
[1] CXL 2.0 ECN: CEDT CFMWS & QTG DSM (computeexpresslink.org / specifications)
Signed-off-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Acked-by: Markus Armbruster <armbru@redhat.com> # QAPI Schema
Message-Id: <20220429144110.25167-28-Jonathan.Cameron@huawei.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2022-04-29 16:40:52 +02:00
|
|
|
GList *fixed_windows;
|
2022-06-08 16:54:33 +02:00
|
|
|
CXLFixedMemoryWindowOptionsList *cfmw_list;
|
2022-04-29 16:40:38 +02:00
|
|
|
} CXLState;
|
|
|
|
|
|
2022-04-29 16:40:48 +02:00
|
|
|
struct CXLHost {
|
|
|
|
|
PCIHostState parent_obj;
|
|
|
|
|
|
|
|
|
|
CXLComponentState cxl_cstate;
|
2023-02-27 16:31:28 +01:00
|
|
|
bool passthrough;
|
2022-04-29 16:40:48 +02:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
#define TYPE_PXB_CXL_HOST "pxb-cxl-host"
|
|
|
|
|
OBJECT_DECLARE_SIMPLE_TYPE(CXLHost, PXB_CXL_HOST)
|
|
|
|
|
|
2022-06-16 16:51:24 +02:00
|
|
|
#define TYPE_CXL_USP "cxl-upstream"
|
|
|
|
|
|
|
|
|
|
typedef struct CXLUpstreamPort CXLUpstreamPort;
|
|
|
|
|
DECLARE_INSTANCE_CHECKER(CXLUpstreamPort, CXL_USP, TYPE_CXL_USP)
|
|
|
|
|
CXLComponentState *cxl_usp_to_cstate(CXLUpstreamPort *usp);
|
2022-04-29 16:40:27 +02:00
|
|
|
#endif
|