On Tue, 14 May 2019 04:18:20 -0700
Dongjiu Geng wrote:
> This implements APEI GHES Table generation via fw_cfg blobs.
> Now it only support GPIO-Signal and ARMv8 SEA two types of GHESv2 error
> source. Afterwards, we can extend the supported types if needed. For the
> CPER section type,
On Tue, 14 May 2019 04:18:23 -0700
Dongjiu Geng wrote:
> Add SIGBUS signal handler. In this handler, it checks the SIGBUS type,
> translates the host VA delivered by host to guest PA, then fill this PA
> to guest APEI GHES memory, then notify guest according to the SIGBUS type.
>
> If guest
of a CCIX layer switch.
Signed-off-by: Jonathan Cameron
---
hw/misc/Kconfig | 5 ++
hw/misc/Makefile.objs | 1 +
hw/misc/ccix-ep.c | 112 ++
3 files changed, 118 insertions(+)
diff --git a/hw/misc/Kconfig b/hw/misc/Kconfig
index 385e1b0cec
call them.
2) Create a library for the code that is shared.
3) Don't worry too much about it as it's likely they will diverge
overtime as we extend the CCIX driver.
Signed-off-by: Jonathan Cameron
---
hw/pci-bridge/Kconfig | 5 +
hw/pci-bridge/Makefile.objs | 1 +
hw/pci-bridge
ted
portion of the CCIX specification and will give CCIX propery copyright
attribution by including the following copyright notice with
the cited part of the CCIX specification:
"© 2019 CCIX CONSORTIUM, INC. ALL RIGHTS RESERVED."
Jonathan Cameron (7):
Temp: Add the PCI_EXT_ID_DVSEC defi
functions
so are not covered by this patch set).
Signed-off-by: Jonathan Cameron
---
hw/pci/Kconfig |3 +
hw/pci/Makefile.objs |1 +
hw/pci/ccix_lib.c| 1299 ++
include/hw/misc/ccix.h | 28 +
include/hw/pci/pci_ids.h |2 +
5
This hasn't yet been added to the linux kernel tree, so for purposes
of this RFC just add it locally.
Signed-off-by: Jonathan Cameron
---
include/standard-headers/linux/pci_regs.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/standard-headers/linux/pci_regs.h
b
Signed-off-by: Jonathan Cameron
---
default-configs/arm-softmmu.mak | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/default-configs/arm-softmmu.mak b/default-configs/arm-softmmu.mak
index 3158e1a10a..d5d4c8ecf1 100644
--- a/default-configs/arm-softmmu.mak
+++ b/default
Note that this is simply emulation of the configuration space.
Has the same issue with cut and paste code as the upstream port
driver. Solution likely to be the same.
Signed-off-by: Jonathan Cameron
---
hw/pci-bridge/Makefile.objs | 2 +-
hw/pci-bridge/ccix_downstream.c | 222
These device IDs have been allocated for emulated only devices,
giving us more flexibility than would be possible by emulating
real devices.
They will be used for the CCIX PCIe configuration space emulation
modules that follow.
Signed-off-by: Jonathan Cameron
---
include/hw/pci/pci_ids.h | 5
On Fri, 14 Jun 2019 23:56:24 +0800
Tao Xu wrote:
> From: Liu Jingqi
>
> HMAT is defined in ACPI 6.2: 5.2.27 Heterogeneous Memory Attribute Table
> (HMAT).
> The specification references below link:
> http://www.uefi.org/sites/default/files/resources/ACPI_6_2.pdf
>
> It describes the memory
On Thu, 27 Jun 2019 08:20:10 -0700
Palmer Dabbelt wrote:
> From: Alistair Francis
>
> Add OpenSBI version 0.3 as a git submodule and as a prebult binary.
>
> Signed-off-by: Alistair Francis
> Reviewed-by: Bin Meng
> Tested-by: Bin Meng
> Signed-off-by: Palmer Dabbelt
I sent a late bug
orrespond to rated latency and bandwidth for the platform.
> The software could use this information as hint for optimization.
>
> Signed-off-by: Liu Jingqi
> Signed-off-by: Tao Xu
I think you've missed one of the 6.3 changes. Otherwise a few nitpicks
but looks good to me.
Review
ain Attributes by memory
> subsystem and its associativity with processor proximity domain as well as
> hint for memory usage.
>
> Signed-off-by: Liu Jingqi
> Signed-off-by: Tao Xu
Looks good to me. Thanks for changing to 6.3.
Reviewed-by: Jonathan Cameron
> ---
e this information to effectively place
> the data in memory to maximize the performance of the system
> memory that use the memory side cache.
>
> Signed-off-by: Liu Jingqi
> Signed-off-by: Tao Xu
There is what I'll call a paste 'splurge' inline.
Otherwise looks goo
On Fri, 28 Jun 2019 09:12:45 -0700
Alistair Francis wrote:
> On Fri, Jun 28, 2019 at 2:47 AM Jonathan Cameron
> wrote:
> >
> > On Thu, 27 Jun 2019 08:20:10 -0700
> > Palmer Dabbelt wrote:
> >
> > > From: Alistair Francis
> > >
On Mon, 24 Jun 2019 15:11:57 -0700
Alistair Francis wrote:
> Add OpenSBI version 0.3 as a git submodule and as a prebult binary.
>
> Signed-off-by: Alistair Francis
Hi Alistair,
Looks like a cut and paste buglet in the Makefile for the roms.
Jonathan
>
> diff --git a/roms/Makefile
On Fri, 16 Aug 2019 13:59:02 +0100
Peter Maydell wrote:
> On Tue, 25 Jun 2019 at 12:28, Jonathan Cameron
> wrote:
> >
> > CCIX topologies are 'layered' on top of PCIe tree topologies.
> > This is done primarily by allowing a single CCIX device to appear as
>
CCIX Consortium, Inc. (CCIX) to
> you and other parties that are paticipating (the "participants") in
> qemu with the understanding that the participants will use CCIX's
> name and trademark only when this patch is used in association with
> qemu.
>
> CCIX is also dist
On Wed, 8 Jan 2020 19:32:18 +0800
Dongjiu Geng wrote:
> This patch builds Hardware Error Source Table(HEST) via fw_cfg blobs.
> Now it only supports ARMv8 SEA, a type of Generic Hardware Error
> Source version 2(GHESv2) error source. Afterwards, we can extend
> the supported types if needed. For
On Tue, 31 Mar 2020 11:59:13 -0700
Richard Henderson wrote:
> On 3/31/20 8:33 AM, Jonathan Cameron wrote:
> > Just wondering if there are any known issues with this?
>
> Nope. It works for me.
> Can you give us any more details.
>
Unfortunately not a lot more to ad
On Fri, 7 Feb 2020 11:52:46 +
Peter Maydell wrote:
> On Thu, 6 Feb 2020 at 10:54, Richard Henderson
> wrote:
> >
> > Version 7 has one more tweak to the vhe tlb flushing
> > that Peter asked for. All patches have reviews.
> >
> >
>
>
>
> Applied to target-arm.next, thanks.
Hi Peter /
On Tue, 31 Mar 2020 16:33:24 +0100
Jonathan Cameron wrote:
> On Fri, 7 Feb 2020 11:52:46 +
> Peter Maydell wrote:
>
> > On Thu, 6 Feb 2020 at 10:54, Richard Henderson
> > wrote:
> > >
> > > Version 7 has one more tweak to the vhe tlb flushing
&
On Wed, 1 Apr 2020 11:45:22 +0100
Jonathan Cameron wrote:
> On Tue, 31 Mar 2020 11:59:13 -0700
> Richard Henderson wrote:
>
> > On 3/31/20 8:33 AM, Jonathan Cameron wrote:
> > > Just wondering if there are any known issues with this?
> >
> > Nope.
On Tue, 24 Nov 2020 20:17:35 +0100
David Hildenbrand wrote:
> On 24.11.20 19:11, Jonathan Cameron wrote:
> > On Mon, 9 Nov 2020 20:47:09 +0100
> > David Hildenbrand wrote:
> >
> > +CC Eric based on similar query in other branch of the thread.
> >
> &g
On Wed, 25 Nov 2020 16:54:53 +0100
David Hildenbrand wrote:
>
> 64k guest on 4k host with 512MiB block size seems fine.
>
> If there are any places anyone thinks need particular poking I'd
> appreciate a hint :)
> >>>
> >>> If things seem to work for now, that's
On Mon, 9 Nov 2020 20:47:09 +0100
David Hildenbrand wrote:
+CC Eric based on similar query in other branch of the thread.
> On 05.11.20 18:43, Jonathan Cameron wrote:
> > Basically a cut and paste job from the x86 support with the exception of
> > needing a larger block size as t
On Wed, 2 Dec 2020 05:02:57 -0500
"Michael S. Tsirkin" wrote:
> On Wed, Nov 25, 2020 at 02:56:59PM +0000, Jonathan Cameron wrote:
> > Cool. I'll run a few more comprehensive tests then send out the
> > trivial patch to enable the kernel option + v2 of the
On Wed, 16 Dec 2020 10:53:34 +0100
Thomas Huth wrote:
> On 16/12/2020 06.05, Prashant V Agarwal wrote:
> > Hi,
> > Is there a way to know the support plans for CXL protocol in QEMU?
> > I see that there is side branch development going on:
> >
> >
On Tue, 10 Nov 2020 21:47:03 -0800
Ben Widawsky wrote:
> 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
On Tue, 10 Nov 2020 21:47:05 -0800
Ben Widawsky wrote:
> This implements the CXL device status registers from 8.2.8.3.1 in the
> CXL 2.0 specification. It is capability ID 0001h.
>
> Signed-off-by: Ben Widawsky
It does some other stuff it shouldn't as well. Please tidy that up before
v2. A
On Tue, 10 Nov 2020 21:47:06 -0800
Ben Widawsky wrote:
> This is the beginning of implementing mailbox support for CXL 2.0
> devices.
>
> Signed-off-by: Ben Widawsky
Mostly patch set cleanup suggestions rather than anything meaningful
in here.
Thanks,
Jonathan
> ---
>
On Tue, 10 Nov 2020 21:47:02 -0800
Ben Widawsky wrote:
> 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
On Tue, 10 Nov 2020 21:47:04 -0800
Ben Widawsky wrote:
> 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
On Tue, 10 Nov 2020 21:47:07 -0800
Ben Widawsky wrote:
> Memory devices implement extra capabilities on top of CXL devices. This
> adds support for that.
>
> Signed-off-by: Ben Widawsky
> ---
> hw/cxl/cxl-device-utils.c | 48 -
>
On Tue, 10 Nov 2020 21:47:11 -0800
Ben Widawsky wrote:
> This cleanup will make it easier to add support for CXL to the mix.
>
> Signed-off-by: Ben Widawsky
Nice looking change. Minor comment inline.
> ---
> hw/i386/acpi-build.c | 31 +--
> 1 file changed, 17
On Tue, 10 Nov 2020 21:47:10 -0800
Ben Widawsky wrote:
> 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
On Tue, 10 Nov 2020 21:47:14 -0800
Ben Widawsky wrote:
> For all host bridges, reserve MMIO space with _CRS. The MMIO for the
> host bridge lives in a magically hard coded space in the system's
> physical address space. The standard mechanism to tell the OS about
> regions which can't be used
On Tue, 10 Nov 2020 21:47:21 -0800
Ben Widawsky wrote:
> 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.
>
> As of CXL 2.0 spec, only 1 sub structure is defined, the CXL Host Bridge
>
/device: Add a memory device (8.2.8.5)
> hw/cxl/device: Implement MMIO HDM decoding (8.2.5.12)
> acpi/cxl: Add _OSC implementation (9.14.2)
> acpi/cxl: Create the CEDT (9.14.1)
> Temp: acpi/cxl: Add ACPI0017 (CEDT awareness)
> WIP: i386/cxl: Initialize a host bridge
> qtest/cxl: A
On Mon, 16 Nov 2020 10:06:26 -0800
Ben Widawsky wrote:
> On 20-11-16 17:21:07, Jonathan Cameron wrote:
> > On Tue, 10 Nov 2020 21:46:59 -0800
> > Ben Widawsky wrote:
> >
> > > Introduce emulation of Compute Express Link 2.0, which was
On Mon, 16 Nov 2020 13:11:16 -0800
Ben Widawsky wrote:
> On 20-11-16 13:07:56, Jonathan Cameron wrote:
> > On Tue, 10 Nov 2020 21:47:03 -0800
> > Ben Widawsky wrote:
> >
> > > A CXL device is a type of CXL component. Conceptually, a CXL device
> > >
On Mon, 16 Nov 2020 14:01:40 -0800
Ben Widawsky wrote:
> On 20-11-16 16:44:09, Jonathan Cameron wrote:
> > On Tue, 10 Nov 2020 21:47:10 -0800
> > Ben Widawsky wrote:
> >
> > > This works like adding a typical pxb device, except the name is
> > > 'pxb
On Mon, 16 Nov 2020 11:19:36 -0800
Ben Widawsky wrote:
> On 20-11-16 12:03:52, Jonathan Cameron wrote:
> > On Tue, 10 Nov 2020 21:47:02 -0800
> > Ben Widawsky wrote:
> >
> > > A CXL 2.0 component is any entity in the CXL topology. All components
> >
On Mon, 16 Nov 2020 13:18:41 -0800
Ben Widawsky wrote:
> On 20-11-16 13:16:08, Jonathan Cameron wrote:
> > On Tue, 10 Nov 2020 21:47:05 -0800
> > Ben Widawsky wrote:
> >
> > > This implements the CXL device status registers from 8.2.8.3.1 in the
> > >
On Mon, 16 Nov 2020 13:45:05 -0800
Ben Widawsky wrote:
> On 20-11-16 16:37:22, Jonathan Cameron wrote:
> > On Tue, 10 Nov 2020 21:47:07 -0800
> > Ben Widawsky wrote:
> >
> > > Memory devices implement extra capabilities on top of CXL de
On Mon, 9 Nov 2020 11:04:52 +0800
Ying Fang wrote:
> A helper struct AcpiCacheOffset is introduced to describe the offset
> of three level caches. The cache hierarchy is built according to
> ACPI spec v6.3 5.2.29.2. Let's enable CPU cache topology now.
>
> Signed-off-by: Ying Fang
> ---
>
On Mon, 9 Nov 2020 11:04:49 +0800
Ying Fang wrote:
> Add the CPUCacheInfo structure to hold cpu cache information for ARM cpus.
> A classic three level cache topology is used here. The default cache
> capacity is given and userspace can overwrite these values.
>
> Signed-off-by: Ying Fang
I
(build will fail due no defined block size).
If there is a more elegant way to do this, please point me in the right
direction.
[1] https://lore.kernel.org/linux-mm/20191212171137.13872-1-da...@redhat.com/
Signed-off-by: Jonathan Cameron
---
default-configs/devices/aarch64-softmmu.mak | 1 +
hw/arm
(build will fail due no defined block size).
If there is a more elegant way to do this, please point me in the right
direction.
[1] https://lore.kernel.org/linux-mm/20191212171137.13872-1-da...@redhat.com/
Signed-off-by: Jonathan Cameron
---
default-configs/devices/aarch64-softmmu.mak | 1 +
hw/arm
On Tue, 5 Jan 2021 08:52:58 -0800
Ben Widawsky wrote:
> This is the beginning of implementing mailbox support for CXL 2.0
> devices.
>
> v2: Use register alignment helper (Ben)
> Minor cleanups (Jonathan)
> Rename error codes to match spec (Jonathan)
> Update cap count from 1 to 2
On Tue, 5 Jan 2021 08:52:56 -0800
Ben Widawsky wrote:
> 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
On Wed, 6 Jan 2021 08:49:48 -0800
Ben Widawsky wrote:
> On 21-01-06 13:28:05, Jonathan Cameron wrote:
> > On Tue, 5 Jan 2021 08:52:56 -0800
> > Ben Widawsky wrote:
> >
> > > This implements all device MMIO up to the first capability .That
> > > inc
On Wed, 6 Jan 2021 13:21:23 +
Jonathan Cameron wrote:
> On Tue, 5 Jan 2021 08:52:58 -0800
> Ben Widawsky wrote:
>
> > This is the beginning of implementing mailbox support for CXL 2.0
> > devices.
> >
> > v2: Use register alignment helper (Ben)
xl: Reserve host bridge MMIO
> hw/pxb/cxl: Add "windows" for host bridges
> hw/cxl/rp: Add a root port
> hw/cxl/device: Add a memory device (8.2.8.5)
> hw/cxl/device: Implement MMIO HDM decoding (8.2.5.12)
> acpi/cxl: Add _OSC implementation (9.14.2)
> te
avaialble.
Jonathan Cameron (4):
include/standard-headers/linux/pci_regs: temp hack to add necessary
DOE definitions.
hw/pci/pcie_doe: Introduce utility functions for PCIe DOE
hw/cxl/cxl-cdat: Initial CDAT implementation for use by CXL devices
hw/mem/cxl_type3: Enabled DOE mailbox for access
Signed-off-by: Jonathan Cameron
---
include/standard-headers/linux/pci_regs.h | 33 ++-
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/include/standard-headers/linux/pci_regs.h
b/include/standard-headers/linux/pci_regs.h
index e709ae8235..7e852d3dd0 100644
command line parameters.
Signed-off-by: Jonathan Cameron
---
hw/mem/cxl_type3.c | 49 ++--
include/hw/cxl/cxl.h | 1 +
2 files changed, 48 insertions(+), 2 deletions(-)
diff --git a/hw/mem/cxl_type3.c b/hw/mem/cxl_type3.c
index dee5a8884b..3449f02090 100644
firmware or
an OS.
Signed-off-by: Jonathan Cameron
---
hw/cxl/cxl-cdat.c | 252 ++
hw/cxl/meson.build| 1 +
include/hw/cxl/cxl_cdat.h | 101 +++
3 files changed, 354 insertions(+)
diff --git a/hw/cxl/cxl-cdat.c b/hw/cxl/cxl-cdat.c
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
---
hw/pci-host/gpex-acpi.c | 22 +++---
1 file changed, 19 insertions
.
Not-signed-off-by: Jonathan Cameron
---
hw/cxl/cxl-device-utils.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/cxl/cxl-device-utils.c b/hw/cxl/cxl-device-utils.c
index d0d0a47122..52dd03384a 100644
--- a/hw/cxl/cxl-device-utils.c
+++ b/hw/cxl/cxl-device-utils.c
@@ -181,11
/qemu
To actually get the memory appropriately exposed to the OS a few additional
changes are needed as discussed in thread
https://lore.kernel.org/qemu-devel/20210128174009.7...@huawei.com/
I will rebase this on future versions of Ben's series as needed.
Jonathan Cameron (3):
hw/pci-host
This implements the ECN to the PCI 5.0 specification available at
https://members.pcisig.com/wg/PCI-SIG/document/14143
Does not currently support interrupts.
Note that currently no attempt is made to clean up allocated memory.
Signed-off-by: Jonathan Cameron
---
hw/pci/meson.build | 2
Code based on i386/pc enablement.
There is a small amount of directly cut and paste code so it may
make sense to unify that at some stage.
Signed-off-by: Jonathan Cameron
---
hw/arm/Kconfig | 1 +
hw/arm/virt-acpi-build.c | 27 +++
hw/arm/virt.c
On Wed, 3 Feb 2021 08:10:32 -0800
Ben Widawsky wrote:
> On 21-02-01 23:26:55, Jonathan Cameron wrote:
> > This is currently needed to avoid an issue in the Linux RFC
> > in which a read is issued that is not a multiple of DW.
> > On arm64 that results in byte reads b
On Tue, 2 Feb 2021 09:54:11 -0800
Ben Widawsky wrote:
> This was a bit more complicated than I was anticipating :-)
>
> On 21-02-01 23:16:27, Jonathan Cameron wrote:
> > This implements the ECN to the PCI 5.0 specification available at
> > https://members.pcisig.com/wg/P
On Mon, 1 Feb 2021 23:16:25 +0800
Jonathan Cameron wrote:
> Whilst I know others are working on an implementation of at least some of
> this, a desire to work on the kernel user of this required an
> implementation so I threw this together in the meantime and am sending
> it out
On Wed, 27 Jan 2021 13:26:45 -0800
Ben Widawsky wrote:
> On 21-01-27 22:03:12, Igor Mammedov wrote:
> > On Tue, 5 Jan 2021 08:53:15 -0800
> > Ben Widawsky wrote:
> >
> > > A CXL memory device (AKA Type 3) is a CXL component that contains some
> > > combination of volatile and persistent
On Wed, 27 Jan 2021 21:20:21 -0800
Dan Williams wrote:
> On Wed, Jan 27, 2021 at 7:52 PM Ben Widawsky wrote:
> >
> > Hi list, Igor.
> >
> > I wanted to get some ideas on how to better handle this. Per the recent
> > discussion [1], it's become clear that there needs to be more thought put
> >
On Thu, 28 Jan 2021 08:58:01 -0800
Ben Widawsky wrote:
> On 21-01-28 08:51:51, Ben Widawsky wrote:
> > On 21-01-28 07:14:44, Ben Widawsky wrote:
> > > On 21-01-28 07:03:18, Ben Widawsky wrote:
> > > > On 21-01-28 10:25:38, Jonathan Cameron wrote:
> >
On Mon, 1 Feb 2021 16:59:24 -0800
Ben Widawsky wrote:
> 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
comment inline. Otherwise LGTM.
> ---
> hw/cxl/cxl-mailbox-utils.c
On Mon, 1 Feb 2021 16:59:19 -0800
Ben Widawsky wrote:
> 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
On Mon, 1 Feb 2021 16:59:21 -0800
Ben Widawsky wrote:
> 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
On Mon, 1 Feb 2021 16:59:27 -0800
Ben Widawsky wrote:
> 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
Minor suggestion inline but nothing important if you don't want to change it.
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
One trivial but up to you on whether you think it's worth changing.
> ---
> hw/i386/acpi-build.c | 31 +--
>
On Mon, 1 Feb 2021 16:59:22 -0800
Ben Widawsky wrote:
> 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
On Mon, 1 Feb 2021 16:59:33 -0800
Ben Widawsky wrote:
> Currently, QEMU makes _UID equivalent to the bus number (_BBN). While
> there is nothing wrong with doing it this way, CXL spec has a heavy
> reliance on _UID to identify host bridges and there is no link to the
> bus number. Having a
self a headache again
Reviewed-by: Jonathan Cameron
> ---
> include/hw/cxl/cxl.h| 1 +
> include/hw/cxl/cxl_device.h | 155
> 2 files changed, 156 insertions(+)
> create mode 100644 include/hw/cxl/cxl_device.h
>
> diff --git a/
On Tue, 2 Feb 2021 10:49:23 -0800
Ben Widawsky wrote:
> On 21-02-01 23:16:28, Jonathan Cameron wrote:
> > CDAT is an ACPI like format defined by the CXL consortium. It is
> > available from
> >
> > https://www.uefi.org/node/4093
> >
> > Here support for
On Mon, 1 Feb 2021 16:59:34 -0800
Ben Widawsky wrote:
> CXL host bridges themselves may have MMIO. Since host bridges don't have
> a BAR they are treated as special for MMIO.
>
> Signed-off-by: Ben Widawsky
>
> --
>
> It's arbitrarily chosen here to pick 0xD000 as the base for the host
>
On Tue, 2 Feb 2021 11:45:05 -0800
Ben Widawsky wrote:
> On 21-02-02 19:21:35, Jonathan Cameron wrote:
> > On Mon, 1 Feb 2021 16:59:34 -0800
> > Ben Widawsky wrote:
> >
> > > CXL host bridges themselves may have MMIO. Since host bridges don't have
> >
On Thu, 10 Jun 2021 09:16:20 -0400
Chris Browy wrote:
> From: hchkuo
>
> The Data Object Exchange implementation of CXL Compliance Mode is
> referring to "Compute Express Link (CXL) Specification, Rev. 2.0, Oct.
> 2020".
>
> The data structure of CXL compliance request and response is added
;
> Signed-off-by: hchkuo
> Signed-off-by: Chris Browy
A few comments inline, but I'm happy with this either way.
Reviewed-by: Jonathan Cameron
> ---
> hw/cxl/cxl-cdat.c | 139 ++
> hw/cxl/meson.build | 1 +
> hw/m
On Thu, 10 Jun 2021 09:16:44 -0400
Chris Browy wrote:
> From: hchkuo
>
> Pre-built CDAT table for testing, contains one CDAT header and six
> CDAT entries: DSMAS, DSLBIS, DSMSCIS, DSIS, DSEMTS, and SSLBIS
> respectively.
>
> Signed-off-by: hchkuo
> Signed-off-by: Chris Browy
I can't apply
ned-off-by: Chris Browy
Reviewed-by: Jonathan Cameron
> ---
> include/hw/pci/pci_ids.h | 3 +++
> include/hw/pci/pcie_regs.h | 4
> 2 files changed, 7 insertions(+)
>
> diff --git a/include/hw/pci/pci_ids.h b/include/hw/pci/pci_ids.h
> index 95f92d98e9..2656009cfe 100644
an be
> removed then.
>
> Signed-off-by: hchkuo
> Signed-off-by: Chris Browy
Hopefully we'll get some traction on the kernel support next cycle as doesn't
look like we'll get the reviews to move it forward this time.
This is indeed part of what we are proposing there so FWIW
Re
ig(), false will be returned if pci_config_read()
> offset is not within DOE capability range. In pcie_doe_write_config(),
> the function will be early returned if not within the related DOE range.
>
> Signed-off-by: hchkuo
> Signed-off-by: Chris Browy
A few comments inline
On Thu, 13 May 2021 14:36:27 +0200
Philippe Mathieu-Daudé wrote:
> On 5/13/21 2:23 PM, Peter Maydell wrote:
> > On Thu, 13 May 2021 at 12:49, Jonathan Cameron
> > wrote:
> >> My initial suggestion was to fix this by adding the relatively
> >> simple code neede
Hi All,
Cc list is a bit of guess, so please add anyone else who might be interested
in this topic.
This came up in discussion of the CXL emulation series a while back
and I've finally gotten around to looking more closely at it
(having carried a local hack in the meantime).
On Fri, 14 May 2021 11:35:57 +0930
"Andrew Jeffery" wrote:
> On Thu, 13 May 2021, at 22:30, Jonathan Cameron wrote:
> > On Thu, 13 May 2021 14:36:27 +0200
> > Philippe Mathieu-Daudé wrote:
> >
> > > On 5/13/21 2:23 PM, Peter Maydell wrote:
> &
On Fri, 25 Jun 2021 20:02:03 -0400
Chris Browy wrote:
> This patch series provides an implementation of the the Data Object Exchange
> (DOE) for Component Measurement and Authentication (CMA) of the Security
> Protocol and Data Model (SPDM).
>
> This patch is based on
> [1] [PATCH v1 openspdm
On Mon, 26 Apr 2021 13:16:43 -0400
Chris Browy wrote:
> From: hchkuo
>
> Macros for the vender ID of PCI-SIG and the size of PCIe Data Object
> Exchange.
The PCI SIG vendor ID is a little tricky to track down as it's only
called out indirectly in PCI specs.
In a similar fashion to what Bjorn
the From on this
series - otherwise the DCO chain is a little unclear.
Subject to a few things I've commented on inline...
Reviewed-by: Jonathan Cameron
> ---
> MAINTAINERS | 7 +
> hw/pci/meson.build| 1 +
> hw/pci/pcie_doe.c | 374 +++
looking a bit odd it doesn't matter so I'll leave it up to you
on whether you want to fix it.
Reviewed-by: Jonathan Cameron
> ---
> hw/mem/cxl_type3.c | 147
> include/hw/cxl/cxl_compliance.h | 293
> include/hw/cx
On Mon, 26 Apr 2021 13:36:02 -0400
Chris Browy wrote:
> From: hchkuo
>
> The Data Object Exchange implementation of CXL Coherent Device Attribute
> Table (CDAT). This implementation is referring to "Coherent Device
> Attribute Table Specification, Rev. 1.02, Oct. 2020" and "Compute
> Express
...
>
> >
> >>
>
> Just like you we feel what's most important is to have DOE supported so
> that
> UEFI and Linux kernel and drivers can progress. We're also contributing
> to
> writing compliance tests for the CXL Compliance Software Development WG.
>
nintended attachment. Please
ignore.
Thanks,
Jonathan
>
> Best Regards,
> Chris
>
>
> On 2/3/21, 12:19 PM, "Jonathan Cameron" wrote:
>
> On Tue, 2 Feb 2021 15:43:28 -0500
> Chris Browy wrote:
>
> Hi Chris,
>
> Whilst
On Tue, 2 Feb 2021 13:03:57 -0800
Ben Widawsky wrote:
> On 21-02-02 20:43:38, Jonathan Cameron wrote:
> > On Tue, 2 Feb 2021 11:45:05 -0800
> > Ben Widawsky wrote:
> >
> > > On 21-02-02 19:21:35, Jonathan Cameron wrote:
> > > > On Mon, 1 Feb 2021
On Tue, 2 Feb 2021 14:58:30 +
Jonathan Cameron wrote:
> On Mon, 1 Feb 2021 16:59:22 -0800
> Ben Widawsky wrote:
>
> > This is the beginning of implementing mailbox support for CXL 2.0
> > devices. The implementation recognizes when the doorbell is rung,
> >
e
> > is
> > definitely the HDM programming which has received limited (but not 0)
> > testing in
> > the Linux driver.
> >
> > Jonathan Cameron has gotten this patch series working on ARM [2], and added
> > some
> > much sought after functiona
1 - 100 of 1727 matches
Mail list logo
