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 acce
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, currently
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
t; Thanks,
>
> Jonathan
>
> This patch is being distributed by the 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 onl
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, 16 Nov 2021 12:11:29 +0100
David Hildenbrand wrote:
> >>
> >> Examples include exposing HBM or PMEM to the VM. Just like on real HW,
> >> this memory is exposed via cpu-less, special nodes. In contrast to real
> >> HW, the memory is hotplugged later (I don't think HW supports hotplug
> >>
On Wed, 17 Nov 2021 08:57:19 -0800
Ben Widawsky wrote:
> Hi Saransh. Please add the list for these kind of questions. I've converted
> your
> HTML mail, but going forward, the list will eat it, so please use text only.
>
> On 21-11-16 00:14:33, Saransh Gupta1 wrote:
> >Hi Ben,
> >
> >T
On Wed, 17 Nov 2021 19:08:28 +0100
David Hildenbrand wrote:
> On 17.11.21 15:30, Jonathan Cameron wrote:
> > On Tue, 16 Nov 2021 12:11:29 +0100
> > David Hildenbrand wrote:
> >
> >>>>
> >>>> Examples include exposing HBM or PMEM to the VM.
On Thu, 18 Nov 2021 12:06:27 +0100
David Hildenbrand wrote:
> On 18.11.21 11:28, Jonathan Cameron wrote:
> > On Wed, 17 Nov 2021 19:08:28 +0100
> > David Hildenbrand wrote:
> >
> >> On 17.11.21 15:30, Jonathan Cameron wrote:
> >>> On Tue, 16 Nov 2
On Thu, 18 Nov 2021 11:23:06 +
Jonathan Cameron wrote:
> On Thu, 18 Nov 2021 12:06:27 +0100
> David Hildenbrand wrote:
>
> > On 18.11.21 11:28, Jonathan Cameron wrote:
> > > On Wed, 17 Nov 2021 19:08:28 +0100
> > > David Hildenbrand wrote:
> > &g
On Fri, 19 Nov 2021 12:33:27 +0100
David Hildenbrand wrote:
> On 19.11.21 11:58, Jonathan Cameron wrote:
> > On Thu, 18 Nov 2021 11:23:06 +
> > Jonathan Cameron wrote:
> >
> >> On Thu, 18 Nov 2021 12:06:27 +0100
> >> David Hildenbrand wrote:
&
Ira's DOE series and Ben's region
series
+ (for fun) my SPDM series. That tree's a franken monster so I'm not planning
to share it unless anyone has particular need of it. Hopefully the various
parts will move forwards this cycle anyway so I can stop having to spend
as mu
Introduction
If we think application specific memory (including inter-host shared memory) is
a thing, it will also be a thing people want to use with virtual machines,
potentially nested. So how do we present it at the Host to VM boundary?
This RFC is perhaps premature given we haven
On Fri, 16 Aug 2024 09:05:46 +0200
Hannes Reinecke wrote:
> On 8/15/24 18:22, Jonathan Cameron wrote:
> > Introduction
> >
> >
> > If we think application specific memory (including inter-host shared
> > memory) is
> > a thing, it will
On Sun, 18 Aug 2024 21:12:34 -0500
John Groves wrote:
> On 24/08/15 05:22PM, Jonathan Cameron wrote:
> > Introduction
> >
> >
> > If we think application specific memory (including inter-host shared
> > memory) is
> > a thing, it will
On Tue, 17 Sep 2024 19:37:21 +
Jonathan Cameron wrote:
> Plan is currently to meet at lpc registration desk 2pm tomorrow Wednesday and
> we will find a room.
>
And now the internet maybe knows my phone number (serves me right for using
my company mobile app that auto added a sig
On Mon, 11 Oct 2021 08:19:01 -0400
"Michael S. Tsirkin" wrote:
> On Mon, Oct 11, 2021 at 12:13:55PM +0200, BALATON Zoltan wrote:
> > On Mon, 11 Oct 2021, Philippe Mathieu-Daudé wrote:
> > > On 10/10/21 15:24, BALATON Zoltan wrote:
> > > > Hello,
> > > >
> > > > I'm trying to fix shutdown and
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 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 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 Wed, 31 Mar 2021 12:36:35 -0400
Chris Browy wrote:
> From: hchkuo
>
Description needed. No patch is going to get applied with out something
to say what it actually does. For this one, useful to have links to the
specs etc in the description plus a very quick intro to what it is for etc.
On Wed, 31 Mar 2021 12:36:58 -0400
Chris Browy wrote:
> From: hchkuo
Again, must have a description, plus a sign off from Chris if Chris is
the person sending the patch out.
>
> Signed-off-by: hchkuo
Please split this into 2 patches. Add the DOE + CDAT in first patch, and
compliance in the
On Wed, 31 Mar 2021 12:37:08 -0400
Chris Browy wrote:
> From: hchkuo
>
> Signed-off-by: hchkuo
Code must build after each patch, so this needs to go first in the series,
not last. git rebase -i HEAD~3 and reorder the patches should be an easy
way to do it.
+ add a note to say standard-header
On Tue, 9 Mar 2021 16:03:55 -0500
Chris Browy wrote:
Hi Chris, various specific comments inline but a few important ones
to watch for next version.
1) Always read the final patch you are sending out. Last minute rebases can
result in picking up a bunch of unrelated stuff like here.
That ba
On Tue, 9 Mar 2021 16:04:36 -0500
Chris Browy wrote:
Hi Chris,
As for patch 1, description needed here. Let's move this series towards
the form needed for a final submission.
2 features, 2 patches... If nothing else makes each one small enough to be
suitable for review with morning coffee :)
On Tue, 9 Mar 2021 15:33:49 -0500
Chris Browy wrote:
> Version 3 patch series for PCIe DOE for PCIe and CXL 2.0 implements
> all planned functionality.
>
> Based on QEMU version:
> https://gitlab.com/bwidawsk/qemu/-/tree/cxl-2.0v4
>
> Summary:
> 1: PCIe DOE support for Discovery
>- Support
On Tue, 9 Feb 2021 15:35:49 -0500
Chris Browy wrote:
Hi Chris,
One more thing hit whilst debugging linux side of this.
> +static void pcie_doe_irq_assert(DOECap *doe_cap)
> +{
> +PCIDevice *dev = doe_cap->doe->pdev;
> +
> +if (doe_cap->cap.intr && doe_cap->ctrl.intr) {
need something
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).
https://lore.kernel.
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
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 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
f to match 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 |
n 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
>
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 Li
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 memo
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
> > i
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:
> >
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
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
ional 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 1
;s next version when 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 DO
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
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
dawsk/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):
h
-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
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 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 are
f 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 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 the
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: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: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 distin
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 t
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 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 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, 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
The rejection was due to an unintended 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 Ch
On Fri, 5 Feb 2021 09:19:36 -0800
Ben Widawsky wrote:
> On 21-02-05 16:09:54, Jonathan Cameron wrote:
> > On Wed, 3 Feb 2021 23:53:53 -0500
> > Chris Browy wrote:
> >
> > > Hi Jonathan,
> > >
> > > Thanks for the review comments and we'
...
>
> >
> >>
>
> 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.
> >>
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 are
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,
> >
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
> ---
> hw/cxl/cxl-mailbox-utils.c | 23 ++-
>
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 t
ave remained fairly stable since since v2. The biggest change here
> > 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]
On Tue, 9 Feb 2021 15:35:49 -0500
Chris Browy wrote:
Run ./scripts/checkpatch.pl over the patches and fix all the warnings before
posting. It will save time by clearing out most of the minor formatting issues
and similar that inevitably sneak in during development.
The biggest issue I'm seeing
On Tue, 9 Feb 2021 15:36:03 -0500
Chris Browy wrote:
Split this into two patches for v3. CDAT in one, compliance mode in the other.
I'd also move the actual elements out into the cxl components so that we
can register only what makes sense for a given device. My guess
is that for now that wil
On Wed, 17 Feb 2021 16:55:14 -0800
Ben Widawsky wrote:
> On 21-02-11 17:46:39, Jonathan Cameron wrote:
> > On Tue, 2 Feb 2021 14:58:30 +
> > Jonathan Cameron wrote:
> >
> > > On Mon, 1 Feb 2021 16:59:22 -0800
> > > Ben Widawsky wrote:
&g
On Fri, 12 Feb 2021 16:58:21 -0500
Chris Browy wrote:
> > On Feb 12, 2021, at 11:24 AM, Jonathan Cameron
> > wrote:
> >
> > On Tue, 9 Feb 2021 15:35:49 -0500
> > Chris Browy wrote:
> >
> > Run ./scripts/checkpatch.pl over the patches and fix all
On Fri, 12 Feb 2021 17:26:50 -0500
Chris Browy wrote:
> > On Feb 12, 2021, at 12:23 PM, Jonathan Cameron
> > wrote:
> >
> > On Tue, 9 Feb 2021 15:36:03 -0500
> > Chris Browy wrote:
> >
> > Split this into two patches for v3. CDAT
On Thu, 18 Feb 2021 19:46:54 -0500
Chris Browy wrote:
> > On Feb 18, 2021, at 2:11 PM, Jonathan Cameron
> > wrote:
> >
> > On Fri, 12 Feb 2021 16:58:21 -0500
> > Chris Browy wrote:
> >
> >>> On Feb 12, 2021, at 11:24 AM, Jonathan Cameron
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 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 grea
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 qemu supp
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:
> >
> > https://gitlab.com/bwidawsk/qemu/-/tree/cxl-2.0v
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
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
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
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
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/
ification will be
used or referenced in qemu, the participants will not modify the cited
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. AL
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
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 385e1
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 b/roms/Ma
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 at
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 rep
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
> > >
> >
> 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 th
-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
nfig(), 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 i
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 to
.
>
> 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 +
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 t
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 (J
1 - 100 of 2457 matches
Mail list logo
