On 21-11-18 22:52:56, Shreyas Shah wrote:
> Hello Folks,
>
> Any plan to add CXL2.0 switch ports in QEMU?
What's your definition of plan?
>
> Regards,
> Shreyas
[snip]
starting point for it?
If he rebased and claims it works I have no reason to doubt it :-). I have a
small fix on my v4 branch if you want to use the latest port patches.
>
> Thanks,
> Saransh
>
>
>
> From: "Jonathan Cameron"
> To: "Ben Widawsky"
patches merged for the Linux
driver, I do intend to go back and try to implement a basic switch so that we
can test those flows.
I admit, I'm curious why you're interested in switches.
> Regards,
> Shreyas
>
> -Original Message-
> From: Ben Widawsky
> Sent: Thur
On 21-11-19 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 th
Really awesome work Jonathan. Dan and I are wrapping up some of the kernel bits,
so all I'll do for now is try to run this, but I hope to be able to review the
parts I'm familiar with at least.
On 22-01-24 17:16:23, Jonathan Cameron wrote:
> Previous version was RFC v3: CXL 2.0 Support.
> No longe
On 22-01-25 11:18:08, Ben Widawsky wrote:
> Really awesome work Jonathan. Dan and I are wrapping up some of the kernel
> bits,
> so all I'll do for now is try to run this, but I hope to be able to review the
> parts I'm familiar with at least.
>
> On 22-01-24 17:1
On 22-02-02 14:10:14, 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 de
On 22-02-11 16:45:19, Jonathan Cameron wrote:
> On Fri, 11 Feb 2022 07:50:00 -0800
> Ben Widawsky wrote:
>
> > On 22-02-02 14:10:14, Jonathan Cameron wrote:
> > > From: Ben Widawsky
> > >
> > > A CXL memory device (AKA Type 3) is a CXL component that c
Ie Capabilities and
> Extended Capabilities requires this to be used to uniquely
> identify CXL memory devices.
>
> Signed-off-by: Jonathan Cameron
Reviewed-by: Ben Widawsky
> ---
>
> This is the missing element to be able to use the Linux kernel
> support for PMEM region
; +write_msk[R_CXL_HDM_DECODER0_TARGET_LIST_HI + i * 0x20] = 0x;
Should it be (type == CXL2_DEVICE || type == CXL2_TYPE3_DEVICE) ?
Otherwise,
Reviewed-by: Ben Widawsky
> }
> }
>
> @@ -239,7 +246,7 @@ void cxl_component_register_init_common(uint32_t
> *reg_state, uint3
On 22-06-07 17:37:02, Jonathan Cameron wrote:
> On Tue, 7 Jun 2022 09:19:28 -0700
> Ben Widawsky wrote:
>
> > On 22-06-07 17:07:47, Jonathan Cameron wrote:
> > > Without being able to write these registers, no interleaving is possible.
> > > More refined checks o
On 22-05-20 18:01:28, Jonathan Cameron wrote:
> As the only I2C emulation in QEMU that supports being both
> a master and a slave, suitable for MCTP over i2c is aspeed-i2c
> add this controller to the arm virt model and hook up our new
> i2c_mctp_cxl_fmapi device.
>
> The current Linux driver for
On 22-05-31 09:26:27, Paolo Bonzini wrote:
> On 5/30/22 15:45, Jonathan Cameron via wrote:
> > +object_property_add(obj, "cxl-fmw", "CXLFixedMemoryWindow",
> > +machine_get_cfmw, machine_set_cfmw,
> > +NULL, state);
> > +object_property_set_de
irst patch at least changes the command-line
> so to avoid have to add backwards compatibility code, it would be great
> to merge that before 7.1 is released.
>
LGTM overall. I'm not thrilled with introducing another [sub]scronym "fmw", but
otherwise, no complaints.
Series i
On 22-05-31 13:39:53, Jonathan Cameron wrote:
> Without being able to write these registers, no interleaving is possible.
> More refined checks of HDM register state on commit to follow.
>
> Signed-off-by: Jonathan Cameron
> ---
> hw/cxl/cxl-component-utils.c | 2 ++
> 1 file changed, 2 insertio
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 inside QEMU or already added in
> >> one of the version?
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 writes:
>
Phil, Igor, Markus
TL;DR: What to do about multiple capacities in a single device, and what to do
about interleave?
I've hacked together a basic CXL 2.0 implementation which exposes a CXL "Type 3"
memory device (CXL 2.0 Chapter 2.3). For what we were trying to do this was
sufficient. There are tw
On 21-03-17 14:40:58, Ben Widawsky wrote:
> Phil, Igor, Markus
>
> TL;DR: What to do about multiple capacities in a single device, and what to do
> about interleave?
>
> I've hacked together a basic CXL 2.0 implementation which exposes a CXL "Type
> 3"
> m
On 21-03-19 18:07:05, Igor Mammedov wrote:
> On Wed, 17 Mar 2021 14:40:58 -0700
> Ben Widawsky wrote:
>
> > Phil, Igor, Markus
> >
> > TL;DR: What to do about multiple capacities in a single device, and what to
> > do
> > about interleave?
> &
>regs.hdm_decoder + CXL_HDM_DECODER0_SIZE_HIGH_OFFSET);
writel(256 << 20, cxlm->regs.hdm_decoder +
CXL_HDM_DECODER0_SIZE_LOW_OFFSET);
writel(BIT(9), cxlm->regs.hdm_decoder + CXL_HDM_DECODER0_CTRL_OFFSET);
tmp = ioremap_uc(0x4c0000, 4096);
writel(0x2
On 20-10-12 16:02:34, Alex Bennée wrote:
>
> Kevin Wolf writes:
>
> > Am 12.10.2020 um 13:53 hat Philippe Mathieu-Daudé geschrieben:
> >> On 10/12/20 1:25 PM, Kevin Wolf wrote:
> >> > Am 12.10.2020 um 12:47 hat Alex Bennée geschrieben:
> >> > >
> >> > > Markus Armbruster writes:
> >> > >
> >>
t ../softmmu/main.c:51
>
> Reported-by: Alex Bennée
> Signed-off-by: Kevin Wolf
Tested-by: Ben Widawsky
[snip]
this, it is immediate and obvious what has gone wrong.
Signed-off-by: Ben Widawsky
---
hw/pci/pci.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index 3c8f10b461..55b0302c57 100644
--- a/hw/pci/pci.c
+++ b/hw/pci/pci.c
@@ -1141,6 +1141,7 @@ void
this, it is immediate and obvious what has gone wrong.
Signed-off-by: Ben Widawsky
---
hw/pci/pci.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index 3c8f10b461..55b0302c57 100644
--- a/hw/pci/pci.c
+++ b/hw/pci/pci.c
@@ -1141,6 +1141,7 @@ void
On 20-10-14 13:52:29, Michael S. Tsirkin wrote:
> On Wed, Oct 14, 2020 at 10:18:53AM -0700, Ben Widawsky wrote:
> > This patch informs future developers working on root complexes, root
> > ports, or bridges that also wish to implement a BAR for those. PCI type
> > 1 header
this mistake is made. With this, it is immediate
and obvious what has gone wrong.
Signed-off-by: Ben Widawsky
---
hw/pci/pci.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index 2c7d6dd352..14fce10132 100644
--- a/hw/pci/pci.c
+++ b/hw/pci/pci.c
@@ -1141,11
Asserts are used for developer bugs. As registering a bar of the wrong
size is not something that should be possible for a user to achieve,
this is a developer bug.
While here, use the more obvious helper function.
Signed-off-by: Ben Widawsky
---
hw/pci/pci.c | 6 +-
1 file changed, 1
I'm working on CXL 2.0 type 3 memory devices [1]. In short, these are PCIe
devices
that have persistent memory on them. As such, it would be nice to inherit from
both a PCI_DEVICE class as well as an NVDIMM device class.
Truth be told, using TYPE_MEMORY_DEVICE as the interface does provide most o
On 21-01-27 10:06:48, Daniel P. Berrangé wrote:
> On Tue, Jan 26, 2021 at 01:33:52PM -0800, Ben Widawsky wrote:
> > I'm working on CXL 2.0 type 3 memory devices [1]. In short, these are PCIe
> > devices
> > that have persistent memory on them. As such, it would be
On 21-01-27 21:18:24, Igor Mammedov wrote:
> On Tue, 26 Jan 2021 13:33:52 -0800
> Ben Widawsky wrote:
>
> > I'm working on CXL 2.0 type 3 memory devices [1]. In short, these are PCIe
> > devices
> > that have persistent memory on them. As such, it would be nice
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 memory. It also implements the
> > previously d
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 memory. It also implements the
> > previously d
On 21-01-27 22:21:04, Igor Mammedov wrote:
> On Wed, 27 Jan 2021 13:11:16 -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
On 21-01-27 22:33:37, Igor Mammedov wrote:
> On Wed, 27 Jan 2021 12:25:44 -0800
> Ben Widawsky wrote:
>
> > On 21-01-27 21:18:24, Igor Mammedov wrote:
> > > On Tue, 26 Jan 2021 13:33:52 -0800
> > > Ben Widawsky wrote:
> > >
> > > > I&#x
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 into
how to manage the address space for CXL memory devices. If you see the
discussion on interleave [2] there's a decent diagram for the
On 21-01-28 10:25:38, Jonathan Cameron wrote:
> 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
On 21-01-28 07:03:18, Ben Widawsky wrote:
> On 21-01-28 10:25:38, Jonathan Cameron wrote:
> > 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
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 Wed, 27 Jan 2021 13:26:45 -0800
> > > Ben Widawsky wrote:
> > >
> > > > On 21-01-27 22:03:12, Igor Mam
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 Wed, 27 Jan 2021 13:26:45 -0800
> > > > Ben Widawsky wrot
little endian.
None of the mechanisms required to enumerate a CXL capable hostbridge
are introduced at this point.
Note that the CXL.mem and CXL.cache registers used are always 4B wide.
It's possible in the future that this constraint will not hold.
Signed-off-by: Ben Widawsky
---
MAINTA
.kernel.org/qemu-devel/20210201151629.29656-1-jonathan.came...@huawei.com/
[4]:
https://lore.kernel.org/linux-cxl/20210130002438.1872527-1-ben.widaw...@intel.com/
---
Ben Widawsky (31):
hw/pci/cxl: Add a CXL component type (interface)
hw/cxl/component: Introduce CXL components (8.1.x, 8.2.5)
implement this interface. Implementing this interface allows the
core pci code to treat these devices as special where appropriate.
Signed-off-by: Ben Widawsky
---
hw/pci/pci.c | 10 ++
include/hw/pci/pci.h | 8
2 files changed, 18 insertions(+)
diff --git a/hw/pci/pci.c b/hw
ering, but having an explicit uid makes more sense when trying to
replicate real hardware configurations.
The QEMU commandline to utilize this would be:
-device pxb-cxl,id=cxl.0,bus="pcie.0",bus_nr=1,uid=x
Signed-off-by: Ben Widawsky
--
I'm guessing this patch will be somewhat cont
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 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/hw/cxl
the host OS and the firmware running on the device. For our
purposes, we emulate both the firmware, implemented primarily in
cxl-mailbox-utils.c, and the hardware.
No commands are implemented yet.
Signed-off-by: Ben Widawsky
---
hw/cxl/cxl-device-utils.c | 125 ++-
hw/cxl/cxl
eventual
implementation of a Type3 CXL.mem device, 8.2.8.5 in the CXL 2.0
specification.
Signed-off-by: Ben Widawsky
---
include/hw/cxl/cxl.h| 1 +
include/hw/cxl/cxl_device.h | 155
2 files changed, 156 insertions(+)
create mode 100644 include/hw
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
bridge MMIO. I'm not sure what the right way to find
commands
differently, and therefore would need a mechanism to opt in/out of the
specific generic handlers. As such, this is considered sufficient for
now, but may need more depth in the future.
Signed-off-by: Ben Widawsky
---
hw/cxl/cxl-device-utils.c | 38
softmmu memory core.
Signed-off-by: Ben Widawsky
---
hw/cxl/cxl-device-utils.c | 105
hw/cxl/meson.build | 1 +
include/hw/cxl/cxl_device.h | 27 +-
3 files changed, 132 insertions(+), 1 deletion(-)
create mode 100644 hw/cxl/cxl-device
to simply implement
it in the device, and figure out how to consolidate it later.
Signed-off-by: Ben Widawsky
---
hw/mem/cxl_type3.c | 92 ++
1 file changed, 84 insertions(+), 8 deletions(-)
diff --git a/hw/mem/cxl_type3.c b/hw/mem/cxl_type3.c
index
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
---
hw/pci-bridge/pci_expander_bridge.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/hw/pci-b
ported. It is useful both to determine which spec'd
optional commands are supported, as well as provide a list of vendor
specified commands that might be used. The CEL is already created as
part of mailbox initialization, but here it is now exported to hosts
that use these log commands.
Sig
issued by the Set Timestamp command.
Signed-off-by: Ben Widawsky
---
hw/cxl/cxl-mailbox-utils.c | 53 +
include/hw/cxl/cxl_device.h | 6 +
2 files changed, 59 insertions(+)
diff --git a/hw/cxl/cxl-mailbox-utils.c b/hw/cxl/cxl-mailbox-utils.c
index
lore.kernel.org/linux-cxl/20210115034911.nkgpzc756d6qm...@intel.com/T/#t
Signed-off-by: Ben Widawsky
---
hw/acpi/cxl.c | 69 +
hw/i386/acpi-build.c| 25 ++-
hw/pci-bridge/pci_expander_bridge.c | 21 +
include/hw/acpi
le host bridges.
v2: Remove vendor and device ID (Ben)
Signed-off-by: Ben Widawsky
---
hw/pci-bridge/pci_expander_bridge.c | 67 -
hw/pci/pci.c| 7 +++
include/hw/pci/pci.h| 6 +++
3 files changed, 78 insertions(+), 2 delet
This cleanup will make it easier to add support for CXL to the mix.
Signed-off-by: Ben Widawsky
---
hw/i386/acpi-build.c | 31 +--
1 file changed, 17 insertions(+), 14 deletions(-)
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index f56d699c7f..cf6eb54c22
type. This is less code and useful for debugging via simply
looking at the flags.
Signed-off-by: Ben Widawsky
---
hw/pci-bridge/pci_expander_bridge.c | 9 -
include/hw/pci/pci_bus.h| 7 +++
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/hw/pci-bridge
Signed-off-by: Ben Widawsky
---
tests/data/acpi/pc/CEDT | Bin 0 -> 36 bytes
tests/data/acpi/q35/CEDT| Bin 0 -> 36 bytes
tests/qtest/bios-tables-test-allowed-diff.h | 2 --
3 files changed, 2 deletions(-)
diff --git a/tests/data/acpi/pc/CEDT b
Signed-off-by: Ben Widawsky
---
tests/qtest/bios-tables-test-allowed-diff.h | 21 +
1 file changed, 21 insertions(+)
diff --git a/tests/qtest/bios-tables-test-allowed-diff.h
b/tests/qtest/bios-tables-test-allowed-diff.h
index dfb8523c8b..5c695cdf37 100644
--- a/tests/qtest
Signed-off-by: Ben Widawsky
---
tests/data/acpi/pc/CEDT | 0
tests/data/acpi/q35/CEDT| 0
tests/qtest/bios-tables-test-allowed-diff.h | 2 ++
3 files changed, 2 insertions(+)
create mode 100644 tests/data/acpi/pc/CEDT
create mode 100644 tests/data/acpi
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 for host bridges is _CRS.
Signed-off-by: Ben Widawsk
This should introduce no change. Subsequent work will make use of this
new class member.
Signed-off-by: Ben Widawsky
---
hw/cxl/cxl-mailbox-utils.c | 4
hw/mem/cxl_type3.c | 24 +---
include/hw/cxl/cxl.h| 1 -
include/hw/cxl/cxl_device.h | 24
ss
Signed-off-by: Ben Widawsky
---
tests/data/acpi/pc/DSDT | Bin 5065 -> 5065 bytes
tests/data/acpi/pc/DSDT.acpihmat| Bin 6390 -> 6390 bytes
tests/data/acpi/pc/DSDT.bridge | Bin 6924 -> 6924 bytes
tests/data/acpi/pc/DSDT.cphp
host bridge. For example:
-device cxl-rp,id=rp0,bus="cxl.0",addr=0.0,chassis=4
Like the host bridge patch, the ACPI tables aren't generated at this
point and so system software cannot use it.
Signed-off-by: Ben Widawsky
---
hw/pci-bridge/Kconfig | 5 +
hw/pci-br
Signed-off-by: Ben Widawsky
---
hw/cxl/cxl-mailbox-utils.c | 50 +
hw/mem/cxl_type3.c | 56 -
include/hw/cxl/cxl_device.h | 9 ++
3 files changed, 114 insertions(+), 1 deletion(-)
diff --git a/hw/cxl/cxl-mailbox
ink: https://lists.nongnu.org/archive/html/qemu-devel/2020-08/msg03680.html
Signed-off-by: Ben Widawsky
---
hw/pci-bridge/pci_expander_bridge.c | 65 +++--
include/hw/cxl/cxl.h| 1 +
2 files changed, 62 insertions(+), 4 deletions(-)
diff --git a/hw/
(PXB) creation, but that will need to
change for interleaving.
The following example will create a 256M device in a 512M window:
-object "memory-backend-file,id=cxl-mem1,share,mem-path=cxl-type3,size=512M"
-device "cxl-type3,bus=rp0,memdev=cxl-mem1,id=cxl-pmem0,size=256M"
Signed-off-by: Ben Widawsky
---
tests/qtest/cxl-test.c | 93 +
tests/qtest/meson.build | 4 ++
2 files changed, 97 insertions(+)
create mode 100644 tests/qtest/cxl-test.c
diff --git a/tests/qtest/cxl-test.c b/tests/qtest/cxl-test.c
new file mode 100644
explanation.
Signed-off-by: Ben Widawsky
---
hw/acpi/Kconfig | 5 ++
hw/acpi/cxl.c | 104 ++
hw/acpi/meson.build | 1 +
hw/i386/acpi-build.c | 12 -
include/hw/acpi/cxl.h | 23 ++
5 files changed, 144 insertions(+), 1 deletion
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
---
hw/cxl/cxl-mailbox-utils.c | 65 ++
1 file changed, 65
This patch allows initializing the primary host bridge as a CXL capable
hostbridge.
Signed-off-by: Ben Widawsky
--
This patch is WIP.
---
hw/arm/virt.c| 1 +
hw/core/machine.c| 26 ++
hw/i386/acpi-build.c | 8 +++-
hw/i386/microvm.c| 1 +
hw/i386
On 21-02-02 08:26:14, Eric Blake wrote:
> On 2/1/21 6:59 PM, Ben Widawsky wrote:
> > 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
On 21-02-01 23:16:26, Jonathan Cameron wrote:
> 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-heade
Thanks for looking! Mixing comments to Jonathan and Michael..
On 21-02-02 10:24:43, Michael S. Tsirkin wrote:
> On Tue, Feb 02, 2021 at 03:00:56PM +, Jonathan Cameron wrote:
> > On Mon, 1 Feb 2021 16:59:33 -0800
> > Ben Widawsky wrote:
> >
> > > Currently, QEM
On 21-02-02 10:51:55, Michael S. Tsirkin wrote:
> On Tue, Feb 02, 2021 at 07:42:57AM -0800, Ben Widawsky wrote:
> > Thanks for looking! Mixing comments to Jonathan and Michael..
> >
> > On 21-02-02 10:24:43, Michael S. Tsirkin wrote:
> > > On Tue, Feb 02, 2021
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/PCI-SIG/document/14143
>
> Does not currently support interrupts.
>
> Note that currently
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 managing all the entires is introduced, along with
> an implementation of a callback for a DOE mailbox which ma
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
> > a BAR they are treated as special for MMIO.
> >
> > Signed-off-by: B
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 16:59:34 -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 being issued and a bus
> error returned.
>
> It is not yet obvious at what level this should b
a long living gitlab project.
On 21-02-01 16:59:17, Ben Widawsky wrote:
> Major changes since v2 [1]:
> * Removed all register endian/alignment/size checking. Using core
> functionality
>instead. This untested on big endian hosts, but Should Work(tm).
> * Fix component cap
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'll put out a v2 patch series
> > based on a genuine git send-email flow in a day or so and plan to include
> > - functionally
On 21-02-08 10:55:51, Jonathan Cameron wrote:
> ...
>
> >
> > >
> > >>
> >
> > 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 co
Have you/Jonathan come to consensus about which implementation is going forward?
I'd rather not have to review two :D
On 21-02-09 15:35:49, Chris Browy wrote:
> ---
> MAINTAINERS | 7 +
> hw/pci/meson.build| 1 +
> hw/pci/pcie.c
A couple of high level comments below. Overall your approach was what I had
imagined originally. The approach Jonathan took is likely more versatile (but
harder to read, for sure).
I'm fine with either and I hope you two can come to an agreement on what the
best way forward is.
My ultimate goal w
ation.
Signed-off-by: Ben Widawsky
---
1. I'm not aware of this being a real issue on platforms today as I think
many platforms that use ACPI and actually have regions, constrain to
32b to be complaint with legacy.
2. Since host bridges aren't usually hot plugged, it can't be invo
truncated and likely lead to conflicts when the operating
systems reads the _CRS object.
Signed-off-by: Ben Widawsky
---
I don't think this effects any code currently in QEMU. You'd need to
have a host bridge which has a BAR, and that BAR wants to be > 32b. I've
hit this because I h
On 20-10-27 15:36:12, Igor Mammedov wrote:
> On Mon, 26 Oct 2020 12:39:24 -0700
> Ben Widawsky wrote:
>
> > According to PCIe spec 5.0 Type 1 header space Base Address Registers
> > are defined by 7.5.1.2.1 Base Address Registers (same as Type 0). The
> > _CRS regio
On 21-02-11 17:08:45, Jonathan Cameron wrote:
> 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
On 21-02-02 11:48:15, Jonathan Cameron wrote:
> 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
On 21-02-02 12:23:50, Jonathan Cameron wrote:
> 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
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:
> >
> > > This is the beginning of implementing mailbox support for CXL 2.0
> >
On 20-11-17 12:29:40, Jonathan Cameron wrote:
[snip]
> > >
> > > > +
> > > > +/* 8.2.5.10 - CXL Security Capability Structure */
> > > > +#define CXL_SEC_REGISTERS_OFFSET (CXL_RAS_REGISTERS_OFFSET +
> > > > CXL_RAS_REGISTERS_SIZE)
> > > > +#define CXL_SEC_REGISTERS_SIZE 0 /* We don't implem
On 20-11-13 08:47:59, Markus Armbruster wrote:
> Eric Blake writes:
>
> > On 11/10/20 11:47 PM, Ben Widawsky wrote:
> >> A CXL memory device (AKA Type 3) is a CXL component that contains some
> >> combination of volatile and persistent memory. It also implemen
On 20-11-17 14:09:14, Jonathan Cameron wrote:
[snip]
>
> Agreed, it was the intermediate state that I wasn't keen on of structures
> defined
> but then given 0 size. I'd rather just look at them all once. If that
> sometimes
> means introducing a file that isn't even referenced for a few pat
On 20-11-26 07:36:23, Markus Armbruster wrote:
> Ben Widawsky writes:
>
> > On 20-11-13 08:47:59, Markus Armbruster wrote:
> >> Eric Blake writes:
> >>
> >> > On 11/10/20 11:47 PM, Ben Widawsky wrote:
> >> >> A CXL memory
On 20-12-16 13:42:51, Jonathan Cameron wrote:
> 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 o
On 20-12-16 18:08:54, Thomas Huth wrote:
> On 16/12/2020 17.03, Ben Widawsky wrote:
> > On 20-12-16 13:42:51, Jonathan Cameron wrote:
> >> On Wed, 16 Dec 2020 10:53:34 +0100
> >> Thomas Huth wrote:
> >>
> >>> On 16/12/2020 06.05, Prashant V Agarwal
Thanks Dave.
Samarth,
Easiest is to just use our run_qemu and figure out the diffs (--cmdline will
print the qemu commandline):
https://github.com/pmem/run_qemu
If you're not able to figure it out after that, please let me know.
On 21-08-10 17:38:16, Samarth Saxena wrote:
> Thanks Dave,
>
> Th
1 - 100 of 184 matches
Mail list logo
