On Tue, 30 Nov 2021 09:21:58 -0800
Ben Widawsky wrote:
> On 21-11-30 13:09:56, Jonathan Cameron wrote:
> > On Mon, 29 Nov 2021 18:28:43 +
> > Alex Bennée wrote:
> >
> > > Ben Widawsky writes:
> > >
> > > > On 21-11-26 12:08:08, Alex Bennée wrote:
> > > >>
> > > >> Ben Widawsky
Hi All,
For CXL emulation we require a couple of types of memory range that
are then provided to the OS via the CEDT ACPI table.
1) CXL Host Bridge Structures point to CXL Host Bridge Component Registers.
Small regions for each CXL Host bridge that are mapped into the memory space.
64k each. In
On Fri, 19 Nov 2021 18:53:43 +
Jonathan Cameron wrote:
> On Thu, 18 Nov 2021 17:52:07 -0800
> Ben Widawsky wrote:
>
> > On 21-11-18 15:20:34, Saransh Gupta1 wrote:
> > > Hi Ben and Jonathan,
> > >
> > > Thanks for your replies. I'm looking forward to the patches.
> > >
> > > For QEMU,
On Mon, 29 Nov 2021 18:28:43 +
Alex Bennée wrote:
> Ben Widawsky writes:
>
> > On 21-11-26 12:08:08, Alex Bennée wrote:
> >>
> >> Ben Widawsky writes:
> >>
> >> > On 21-11-19 02:29:51, Shreyas Shah wrote:
> >> >> Hi Ben
> >> >>
> >> >> Are you planning to add the CXL2.0 switch
On Thu, 09 Dec 2021 14:19:59 +
Alex Bennée wrote:
> Jonathan Cameron writes:
>
> > Hi All,
> >
> > For CXL emulation we require a couple of types of memory range that
> > are then provided to the OS via the CEDT ACPI table.
> >
> > 1) CXL Host Bridge Structures point to CXL Host Bridge
On Fri, 3 Dec 2021 11:35:20 +0800
Gavin Shan wrote:
> This series supports virtio-mem-pci device, by simply following the
> implementation on x86. The exception is the block size is 512MB on
> ARM64 instead of 128MB on x86, compatible with the memory section
> size in linux guest.
>
> The work
On Mon, 1 Feb 2021 16:59:31 -0800
Ben Widawsky wrote:
> This cleanup will make it easier to add support for CXL to the mix.
>
> Signed-off-by: Ben Widawsky
Hi Ben / all (particularly PCI experts!)
So... I was looking at the large impact this has on needing to update
ACPI tables for the tests
On Fri, 11 Feb 2022 12:07:21 +
Jonathan Cameron wrote:
> From: Ben Widawsky
>
> A CXL memory device (AKA Type 3) is a CXL component that contains some
> combination of volatile and persistent memory. It also implements the
> previously defined mailbox interface as well as the memory device
On Sun, 6 Mar 2022 16:33:40 -0500
"Michael S. Tsirkin" wrote:
> On Sun, Mar 06, 2022 at 05:40:51PM +, Jonathan Cameron wrote:
> > Ideally I'd love it if we could start picking up the earlier
> > sections of this series as I think those have been reasonably
> > well reviewed and should not be
On Fri, 4 Mar 2022 15:56:38 +
Jonathan Cameron wrote:
> On Wed, 02 Mar 2022 07:55:45 +0100
> Markus Armbruster wrote:
>
> > Jonathan Cameron via writes:
> >
> > > From: Jonathan Cameron
> > >
> > > The concept of these is introduced i
On Wed, 02 Mar 2022 07:55:45 +0100
Markus Armbruster wrote:
> Jonathan Cameron via writes:
>
> > From: Jonathan Cameron
> >
> > The concept of these is introduced in [1] in terms of the
> > description the CEDT ACPI table. The principal is more general.
> &
On Sun, 6 Mar 2022 16:31:05 -0500
"Michael S. Tsirkin" wrote:
> On Sun, Mar 06, 2022 at 05:41:15PM +, Jonathan Cameron wrote:
> > From: Ben Widawsky
> >
> > CXL 2.0 specification adds 2 new dwords to the existing _OSC definition
> > from PCIe. The new dwords are accessed with a new uuid.
On Wed, 16 Mar 2022 17:16:55 +
Mark Cave-Ayland wrote:
> On 16/03/2022 16:50, Jonathan Cameron via wrote:
>
> > On Thu, 10 Mar 2022 16:02:22 +0800
> > Peter Xu wrote:
> >
> >> On Wed, Mar 09, 2022 at 11:28:27AM +, Jonathan Cameron wrote:
> &g
On Thu, 10 Mar 2022 16:02:22 +0800
Peter Xu wrote:
> On Wed, Mar 09, 2022 at 11:28:27AM +, Jonathan Cameron wrote:
> > Hi Peter,
>
> Hi, Jonathan,
>
> >
> > >
> > > https://lore.kernel.org/qemu-devel/20220306174137.5707-35-jonathan.came...@huawei.com/
> > >
> > > Having mr->ops set
On Wed, 16 Mar 2022 17:58:46 +
Jonathan Cameron wrote:
> On Wed, 16 Mar 2022 17:16:55 +
> Mark Cave-Ayland wrote:
>
> > On 16/03/2022 16:50, Jonathan Cameron via wrote:
> >
> > > On Thu, 10 Mar 2022 16:02:22 +0800
> > > Peter Xu wrote:
>
On Wed, 9 Mar 2022 16:15:24 +0800
Peter Xu wrote:
> On Mon, Mar 07, 2022 at 09:39:18AM +0000, Jonathan Cameron via wrote:
> > If any of the memory maintainers can take a look at patch 34 that would
> > be great as to my mind that and the related interleave decoding in general
>
On Fri, 18 Mar 2022 08:14:58 +
Mark Cave-Ayland wrote:
> On 17/03/2022 16:47, Jonathan Cameron via wrote:
>
> >> Ah great! As you've already noticed my particular case was performing
> >> partial
> >> decoding on a memory region, but there are no iss
From: Ben Widawsky
A CXL 2.0 component is any entity in the CXL topology. All components
have a analogous function in PCIe. Except for the CXL host bridge, all
have a PCIe config space that is accessible via the common PCIe
mechanisms. CXL components are enumerated via DVSEC fields in the
From: Jonathan Cameron
The CXL emulation will be jointly maintained by Ben Widawsky
and Jonathan Cameron. Broken out as a separate patch
to improve visibility.
Signed-off-by: Jonathan Cameron
Reviewed-by: Alex Bennée
---
MAINTAINERS | 7 +++
1 file changed, 7 insertions(+)
diff --git
Changes since v7:
* Fixed and added comments for _OSC definition (Michael Tsirkin)
* Dropped the RFC patch that added memops to a hostmem backend
and replaced with a per CXL type 3 device address space and use
of address_space_read() / address_space_write(). (Mark Cave-Ayland)
* Added switch
From: Ben Widawsky
A CXL component is a hardware entity that implements CXL component
registers from the CXL 2.0 spec (8.2.3). Currently these represent 3
general types.
1. Host Bridge
2. Ports (root, upstream, downstream)
3. Devices (memory, other)
A CXL component can be conceptually thought
From: Ben Widawsky
This implements all device MMIO up to the first capability. That
includes the CXL Device Capabilities Array Register, as well as all of
the CXL Device Capability Header Registers. The latter are filled in as
they are implemented in the following patches.
Endianness and
From: Ben Widawsky
This is the beginning of implementing mailbox support for CXL 2.0
devices. The implementation recognizes when the doorbell is rung,
handles the command/payload, clears the doorbell while returning error
codes and data.
Generally the mailbox mechanism is designed to permit
From: Ben Widawsky
Memory devices implement extra capabilities on top of CXL devices. This
adds support for that.
A large part of memory devices is the mailbox/command interface. All of
the mailbox handling is done in the mailbox-utils library. Longer term,
new CXL devices that are being
From: Ben Widawsky
The easiest way to differentiate a CXL bus, and a PCIE bus is using a
flag. A CXL bus, in hardware, is backward compatible with PCIE, and
therefore the code tries pretty hard to keep them in sync as much as
possible.
The other way to implement this would be to try to cast the
From: Ben Widawsky
A device's volatile and persistent memory are known Host Defined Memory
(HDM) regions. The mechanism by which the device is programmed to claim
the addresses associated with those regions is through dedicated logic
known as the HDM decoder. In order to allow the OS to properly
From: Ben Widawsky
GET_FW_INFO and GET_PARTITION_INFO, for this emulation, is equivalent to
info already returned in the IDENTIFY command. To have a more robust
implementation, add those.
Signed-off-by: Ben Widawsky
Signed-off-by: Jonathan Cameron
---
hw/cxl/cxl-mailbox-utils.c | 69
From: Ben Widawsky
This should introduce no change. Subsequent work will make use of this
new class member.
Signed-off-by: Ben Widawsky
Signed-off-by: Jonathan Cameron
---
hw/cxl/cxl-mailbox-utils.c | 3 +++
hw/mem/cxl_type3.c | 9 +
include/hw/cxl/cxl_device.h | 10
Add exceptions for the DSDT and the new CEDT tables
specific to a new CXL test in the following patch.
Signed-off-by: Jonathan Cameron
---
tests/data/acpi/q35/CEDT.cxl| 0
tests/data/acpi/q35/DSDT.cxl| 0
tests/qtest/bios-tables-test-allowed-diff.h | 2 ++
3
The DSDT includes several CXL specific elements and the CEDT
table is only present if we enable CXL.
The test exercises all current functionality with several
CFMWS, CHBS structures in CEDT and ACPI0016/ACPI00017 and _OSC
entries in DSDT.
Signed-off-by: Jonathan Cameron
---
From: Ben Widawsky
CXL host bridges themselves may have MMIO. Since host bridges don't have
a BAR they are treated as special for MMIO. This patch includes
i386/pc support.
Also hook up the device reset now that we have have the MMIO
space in which the results are visible.
Note that we
Code based on i386/pc enablement.
The memory layout places space for 16 host bridge register regions after
the GIC_REDIST2 in the extended memmap.
The CFMWs are placed above the extended memmap.
Only create the CEDT table if cxl=on set for the machine.
Signed-off-by: Jonathan Cameron
From: Jonathan Cameron
Both registers and the CFMWS entries in CDAT use simple encodings
for the number of interleave ways and the interleave granularity.
Introduce simple conversion functions to/from the unencoded
number / size. So far the iw decode has not been needed so is
it not
Emulation of a simple CXL Switch downstream port.
The Device ID has been allocated for this use.
Signed-off-by: Jonathan Cameron
---
hw/pci-bridge/cxl_downstream.c | 229 +
hw/pci-bridge/meson.build | 2 +-
2 files changed, 230 insertions(+), 1 deletion(-)
Switches were already introduced, but now we support them update
the documentation to provide an example in diagram and
qemu command line parameter forms.
Signed-off-by: Jonathan Cameron
---
docs/system/devices/cxl.rst | 88 -
1 file changed, 86
From: Ben Widawsky
The CEDT CXL Fixed Window Memory Window Structures (CFMWs)
define regions of the host phyiscal address map which
(via an impdef means) are configured such that they have
a particular interleave setup across one or more CXL Host Bridges.
Reported-by: Alison Schofield
From: Ben Widawsky
Errata F4 to CXL 2.0 clarified the meaning of the timer as the
sum of the value set with the timestamp set command and the number
of nano seconds since it was last set.
Signed-off-by: Ben Widawsky
Signed-off-by: Jonathan Cameron
Reviewed-by: Alex Bennée
---
From: Ben Widawsky
This opens up the possibility for more types of expanders (other than
PCI and PCIe). We'll need this to create a CXL expander.
Signed-off-by: Ben Widawsky
Signed-off-by: Jonathan Cameron
Reviewed-by: Alex Bennée
---
hw/pci-bridge/pci_expander_bridge.c | 11 +++
1
Initial test with just pxb-cxl. Other tests will be added
alongside functionality.
Signed-off-by: Jonathan Cameron
Reviewed-by: Alex Bennée
Tested-by: Alex Bennée
---
tests/qtest/cxl-test.c | 23 +++
tests/qtest/meson.build | 4
2 files changed, 27 insertions(+)
From: Jonathan Cameron
Accessor to get hold of the cxl state for a CXL host bridge
without exposing the internals of the implementation.
Signed-off-by: Jonathan Cameron
Reviewed-by: Alex Bennée
---
hw/pci-bridge/pci_expander_bridge.c | 7 +++
include/hw/cxl/cxl_component.h | 2 ++
2
From: Jonathan Cameron
These memops perform interleave decoding, walking down the
CXL topology from CFMWS described host interleave
decoder via CXL host bridge HDM decoders, through the CXL
root ports and finally call CXL type 3 specific read and write
functions.
Note that, whilst functional
From: Ben Widawsky
Add a trivial handler for now to cover the root bridge
where we could do some error checking in future.
Signed-off-by: Ben Widawsky
Signed-off-by: Jonathan Cameron
---
hw/cxl/cxl-component-utils.c | 31 +++
1 file changed, 31 insertions(+)
diff
Add a single complex case for aarch64 virt machine.
Signed-off-by: Jonathan Cameron
---
tests/qtest/cxl-test.c | 48 +
tests/qtest/meson.build | 1 +
2 files changed, 40 insertions(+), 9 deletions(-)
diff --git a/tests/qtest/cxl-test.c
At this stage we can boot configurations with host bridges,
root ports and type 3 memory devices, so add appropriate
tests.
Signed-off-by: Jonathan Cameron
Reviewed-by: Alex Bennée
---
tests/qtest/cxl-test.c | 126 +
1 file changed, 126 insertions(+)
Provide an introduction to the main components of a CXL system,
with detailed explanation of memory interleaving, example command
lines and kernel configuration.
This was a challenging document to write due to the need to extract
only that subset of CXL information which is relevant to either
An initial simple upstream port emulation to allow the creation
of CXL switches. The Device ID has been allocated for this use.
Signed-off-by: Jonathan Cameron
---
hw/pci-bridge/cxl_upstream.c | 205 +++
hw/pci-bridge/meson.build| 2 +-
include/hw/cxl/cxl.h
From: Ben Widawsky
A CXL device is a type of CXL component. Conceptually, a CXL device
would be a leaf node in a CXL topology. From an emulation perspective,
CXL devices are the most complex and so the actual implementation is
reserved for discrete commits.
This new device type is specifically
From: Ben Widawsky
A CXL memory device (AKA Type 3) is a CXL component that contains some
combination of volatile and persistent memory. It also implements the
previously defined mailbox interface as well as the memory device
firmware interface.
Although the memory device is configured like a
From: Jonathan Cameron
Once a read or write reaches a CXL type 3 device, the HDM decoders
on the device are used to establish the Device Physical Address
which should be accessed. These functions peform the required maths
and then use a device specific address space to access the
hostmem->mr to
From: Jonathan Cameron
Add the CFMWs memory regions to the memorymap and adjust the
PCI window to avoid hitting the same memory.
Signed-off-by: Jonathan Cameron
---
hw/i386/pc.c | 31 ++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/hw/i386/pc.c
From: Ben Widawsky
Add CXL Fixed Memory Windows to the CXL tests.
Signed-off-by: Ben Widawsky
Co-developed-by: Jonathan Cameron
Signed-off-by: Jonathan Cameron
---
tests/qtest/cxl-test.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/tests/qtest/cxl-test.c
From: Jonathan Cameron
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
Extend the walk of the CXL bus during interleave decoding to take
into account one layer of switches.
Whilst theoretically CXL 2.0 allows multiple switch levels, in the
vast majority of usecases only one level is expected and currently
that is all the proposed Linux support provides.
This adds code to instantiate the slightly extended ACPI root port
description in DSDT as per the CXL 2.0 specification.
Basically a cut and paste job from the i386/pc code.
Signed-off-by: Jonathan Cameron
Signed-off-by: Ben Widawsky
Reviewed-by: Alex Bennée
---
hw/arm/Kconfig | 1
From: Ben Widawsky
A CXL device is a type of CXL component. Conceptually, a CXL device
would be a leaf node in a CXL topology. From an emulation perspective,
CXL devices are the most complex and so the actual implementation is
reserved for discrete commits.
This new device type is specifically
From: Jonathan Cameron
The CXL emulation will be jointly maintained by Ben Widawsky
and Jonathan Cameron. Broken out as a separate patch
to improve visibility.
Signed-off-by: Jonathan Cameron
Reviewed-by: Alex Bennée
---
MAINTAINERS | 7 +++
1 file changed, 7 insertions(+)
diff --git
From: Ben Widawsky
This implements all device MMIO up to the first capability. That
includes the CXL Device Capabilities Array Register, as well as all of
the CXL Device Capability Header Registers. The latter are filled in as
they are implemented in the following patches.
Endianness and
From: Ben Widawsky
Memory devices implement extra capabilities on top of CXL devices. This
adds support for that.
A large part of memory devices is the mailbox/command interface. All of
the mailbox handling is done in the mailbox-utils library. Longer term,
new CXL devices that are being
From: Jonathan Cameron
There are going to be some potential overheads to CXL enablement,
for example the host bridge region reserved in memory maps.
Add a machine level control so that CXL is disabled by default.
Signed-off-by: Jonathan Cameron
Reviewed-by: Alex Bennée
---
hw/core/machine.c
From: Ben Widawsky
Using the previously implemented stubbed helpers, it is now possible to
easily add the missing, required commands to the implementation.
Signed-off-by: Ben Widawsky
Signed-off-by: Jonathan Cameron
Reviewed-by: Alex Bennée
---
hw/cxl/cxl-mailbox-utils.c | 27
Initial test with just pxb-cxl. Other tests will be added
alongside functionality.
Signed-off-by: Jonathan Cameron
Reviewed-by: Alex Bennée
Tested-by: Alex Bennée
---
tests/qtest/cxl-test.c | 23 +++
tests/qtest/meson.build | 4
2 files changed, 27 insertions(+)
From: Ben Widawsky
This opens up the possibility for more types of expanders (other than
PCI and PCIe). We'll need this to create a CXL expander.
Signed-off-by: Ben Widawsky
Signed-off-by: Jonathan Cameron
Reviewed-by: Alex Bennée
---
hw/pci-bridge/pci_expander_bridge.c | 11 +++
1
From: Ben Widawsky
CXL host bridges themselves may have MMIO. Since host bridges don't have
a BAR they are treated as special for MMIO. This patch includes
i386/pc support.
Also hook up the device reset now that we have have the MMIO
space in which the results are visible.
Note that we
From: Ben Widawsky
This should introduce no change. Subsequent work will make use of this
new class member.
Signed-off-by: Ben Widawsky
Signed-off-by: Jonathan Cameron
---
v7:
* Moved struct cxl_type3_dev to final location in earlier patch (17)
hw/cxl/cxl-mailbox-utils.c | 3 +++
From: Ben Widawsky
The CEDT CXL Fixed Window Memory Window Structures (CFMWs)
define regions of the host phyiscal address map which
(via an impdef means) are configured such that they have
a particular interleave setup across one or more CXL Host Bridges.
Reported-by: Alison Schofield
This adds code to instantiate the slightly extended ACPI root port
description in DSDT as per the CXL 2.0 specification.
Basically a cut and paste job from the i386/pc code.
Signed-off-by: Jonathan Cameron
Signed-off-by: Ben Widawsky
Reviewed-by: Alex Bennée
---
v7:
* Host is_cxl assignment
Tables that differ from normal Q35 tables when running the CXL test.
Signed-off-by: Jonathan Cameron
---
tests/data/acpi/q35/CEDT.cxl| Bin 0 -> 184 bytes
tests/data/acpi/q35/DSDT.cxl| Bin 0 -> 9627 bytes
tests/qtest/bios-tables-test-allowed-diff.h | 2 --
3
From: Jonathan Cameron
Once a read or write reaches a CXL type 3 device, the HDM decoders
on the device are used to establish the Device Physical Address
which should be accessed. These functions peform the required maths
and then directly access the hostmem->mr to fullfil the actual
operation.
From: Jonathan Cameron
Accessor to get hold of the cxl state for a CXL host bridge
without exposing the internals of the implementation.
Signed-off-by: Jonathan Cameron
Reviewed-by: Alex Bennée
---
hw/pci-bridge/pci_expander_bridge.c | 7 +++
include/hw/cxl/cxl_component.h | 2 ++
2
From: Jonathan Cameron
Add the CFMWs memory regions to the memorymap and adjust the
PCI window to avoid hitting the same memory.
Signed-off-by: Jonathan Cameron
---
hw/i386/pc.c | 31 ++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/hw/i386/pc.c
From: Jonathan Cameron
Simple function to search a PCIBus to find a port by
it's port number.
CXL interleave decoding uses the port number as a target
so it is necessary to locate the port when doing interleave
decoding.
Signed-off-by: Jonathan Cameron
Reviewed-by: Alex Bennée
---
Code based on i386/pc enablement.
The memory layout places space for 16 host bridge register regions after
the GIC_REDIST2 in the extended memmap.
The CFMWs are placed above the extended memmap.
Only create the CEDT table if cxl=on set for the machine.
Signed-off-by: Jonathan Cameron
The DSDT includes several CXL specific elements and the CEDT
table is only present if we enable CXL.
The test exercises all current functionality with several
CFMWS, CHBS structures in CEDT and ACPI0016/ACPI00017 and _OSC
entries in DSDT.
Signed-off-by: Jonathan Cameron
---
From: Ben Widawsky
Add a trivial handler for now to cover the root bridge
where we could do some error checking in future.
Signed-off-by: Ben Widawsky
Signed-off-by: Jonathan Cameron
---
hw/cxl/cxl-component-utils.c | 31 +++
1 file changed, 31 insertions(+)
diff
Emulation of a simple CXL Switch downstream port.
The Device ID has been allocated for this use.
Signed-off-by: Jonathan Cameron
---
hw/pci-bridge/cxl_downstream.c | 229 +
hw/pci-bridge/meson.build | 2 +-
2 files changed, 230 insertions(+), 1 deletion(-)
Extend the walk of the CXL bus during interleave decoding to take
into account one layer of switches.
Whilst theoretically CXL 2.0 allows multiple switch levels, in the
vast majority of usecases only one level is expected and currently
that is all the proposed Linux support provides.
Ideally I'd love it if we could start picking up the earlier
sections of this series as I think those have been reasonably
well reviewed and should not be particularly controversial.
(perhaps up to patch 15 inline with what Michael Tsirkin suggested
on v5).
There is one core memory handling
From: Ben Widawsky
A CXL component is a hardware entity that implements CXL component
registers from the CXL 2.0 spec (8.2.3). Currently these represent 3
general types.
1. Host Bridge
2. Ports (root, upstream, downstream)
3. Devices (memory, other)
A CXL component can be conceptually thought
From: Ben Widawsky
A CXL 2.0 component is any entity in the CXL topology. All components
have a analogous function in PCIe. Except for the CXL host bridge, all
have a PCIe config space that is accessible via the common PCIe
mechanisms. CXL components are enumerated via DVSEC fields in the
From: Ben Widawsky
The easiest way to differentiate a CXL bus, and a PCIE bus is using a
flag. A CXL bus, in hardware, is backward compatible with PCIE, and
therefore the code tries pretty hard to keep them in sync as much as
possible.
The other way to implement this would be to try to cast the
From: Ben Widawsky
This is the beginning of implementing mailbox support for CXL 2.0
devices. The implementation recognizes when the doorbell is rung,
handles the command/payload, clears the doorbell while returning error
codes and data.
Generally the mailbox mechanism is designed to permit
From: Ben Widawsky
CXL specification provides for the ability to obtain logs from the
device. Logs are either spec defined, like the "Command Effects Log"
(CEL), or vendor specific. UUIDs are defined for all log types.
The CEL is a mechanism to provide information to the host about which
From: Ben Widawsky
Errata F4 to CXL 2.0 clarified the meaning of the timer as the
sum of the value set with the timestamp set command and the number
of nano seconds since it was last set.
Signed-off-by: Ben Widawsky
Signed-off-by: Jonathan Cameron
Reviewed-by: Alex Bennée
---
v7:
* Code
From: Ben Widawsky
This works like adding a typical pxb device, except the name is
'pxb-cxl' instead of 'pxb-pcie'. An example command line would be as
follows:
-device pxb-cxl,id=cxl.0,bus="pcie.0",bus_nr=1
A CXL PXB is backward compatible with PCIe. What this means in practice
is that an
At this stage we can boot configurations with host bridges,
root ports and type 3 memory devices, so add appropriate
tests.
Signed-off-by: Jonathan Cameron
Reviewed-by: Alex Bennée
---
v7: Patch moved from 18 to 22 as we need LSA support in place to avoid
introducing backwards compatibility
From: Ben Widawsky
This adds just enough of a root port implementation to be able to
enumerate root ports (creating the required DVSEC entries). What's not
here yet is the MMIO nor the ability to write some of the DVSEC entries.
This can be added with the qemu commandline by adding a rootport
From: Ben Widawsky
A CXL memory device (AKA Type 3) is a CXL component that contains some
combination of volatile and persistent memory. It also implements the
previously defined mailbox interface as well as the memory device
firmware interface.
Although the memory device is configured like a
From: Ben Widawsky
A device's volatile and persistent memory are known Host Defined Memory
(HDM) regions. The mechanism by which the device is programmed to claim
the addresses associated with those regions is through dedicated logic
known as the HDM decoder. In order to allow the OS to properly
From: Jonathan Cameron
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
From: Ben Widawsky
GET_FW_INFO and GET_PARTITION_INFO, for this emulation, is equivalent to
info already returned in the IDENTIFY command. To have a more robust
implementation, add those.
Signed-off-by: Ben Widawsky
Signed-off-by: Jonathan Cameron
---
v7:
* Use QEMU_PACKED etc from compiler.h
From: Ben Widawsky
Implement get and set handlers for the Label Storage Area
used to hold data describing persistent memory configuration
so that it can be ensured it is seen in the same configuration
after reboot.
Signed-off-by: Ben Widawsky
Signed-off-by: Jonathan Cameron
---
v7:
* Move a
From: Ben Widawsky
The CXL Early Discovery Table is defined in the CXL 2.0 specification as
a way for the OS to get CXL specific information from the system
firmware.
CXL 2.0 specification adds an _HID, ACPI0016, for CXL capable host
bridges, with a _CID of PNP0A08 (PCIe host bridge). CXL aware
From: Ben Widawsky
CXL 2.0 specification adds 2 new dwords to the existing _OSC definition
from PCIe. The new dwords are accessed with a new uuid. This
implementation supports what is in the specification.
Signed-off-by: Ben Widawsky
Signed-off-by: Jonathan Cameron
Reviewed-by: Alex Bennée
From: Jonathan Cameron
Both registers and the CFMWS entries in CDAT use simple encodings
for the number of interleave ways and the interleave granularity.
Introduce simple conversion functions to/from the unencoded
number / size. So far the iw decode has not been needed so is
it not
From: Jonathan Cameron
These memops perform interleave decoding, walking down the
CXL topology from CFMWS described host interleave
decoder via CXL host bridge HDM decoders, through the CXL
root ports and finally call CXL type 3 specific read and write
functions.
Note that, whilst functional
Add exceptions for the DSDT and the new CEDT tables
specific to a new CXL test in the following patch.
Signed-off-by: Jonathan Cameron
---
tests/data/acpi/q35/CEDT.cxl| 0
tests/data/acpi/q35/DSDT.cxl| 0
tests/qtest/bios-tables-test-allowed-diff.h | 2 ++
3
From: Jonathan Cameron
Inorder to implement memory interleaving we need a means to proxy
the calls. Adding mem_ops allows such proxying.
Note should have no impact on use cases not using _dispatch_read/write.
For now, only file backed hostmem is considered to seek feedback on
the approach
From: Ben Widawsky
Add CXL Fixed Memory Windows to the CXL tests.
Signed-off-by: Ben Widawsky
Co-developed-by: Jonathan Cameron
Signed-off-by: Jonathan Cameron
---
tests/qtest/cxl-test.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/tests/qtest/cxl-test.c
Provide an introduction to the main components of a CXL system,
with detailed explanation of memory interleaving, example command
lines and kernel configuration.
This was a challenging document to write due to the need to extract
only that subset of CXL information which is relevant to either
Add a single complex case for aarch64 virt machine.
Signed-off-by: Jonathan Cameron
---
tests/qtest/cxl-test.c | 48 +
tests/qtest/meson.build | 1 +
2 files changed, 40 insertions(+), 9 deletions(-)
diff --git a/tests/qtest/cxl-test.c
1 - 100 of 1621 matches
Mail list logo
