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
ben.widaw...@intel.com will stop working on 2022-06-20, change it to my
personal email address.
Update .mailmap to handle previously authored commits.
Acked-by: Jonathan Cameron
Signed-off-by: Ben Widawsky
---
v2:
Fix typo in commit message
change author to b...@bwidawsk.net from
On 22-06-07 17:50:35, Jonathan Cameron wrote:
> On Tue, 7 Jun 2022 09:26:28 -0700
> Ben Widawsky wrote:
>
> > ben@widaw...@intel.com will stop working on 2022-06-20, change it to my
> > personal email address.
> >
> > Update .mailmap to handle previously authore
ben@widaw...@intel.com will stop working on 2022-06-20, change it to my
personal email address.
Update .mailmap to handle previously authored commits.
Signed-off-by: Ben Widawsky
---
.mailmap| 1 +
MAINTAINERS | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/.mailmap b
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
; +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-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
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 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
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-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
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-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
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 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:
>
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-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
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
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"
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]
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
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?
> &
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
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
>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 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 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-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-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
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
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
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
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
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-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
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-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-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
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-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
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-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
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
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
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
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
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
(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"
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/
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
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
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
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
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
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
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 | 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
.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)
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
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
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 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 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
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-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
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: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 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 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
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-12 09:27:39, Alex Bennée wrote:
>
> Ben Widawsky writes:
>
> > On 21-01-08 22:30:59, Alex Bennée wrote:
> >>
> >> Ben Widawsky writes:
> >>
> >> > On 21-01-08 12:19:35, Alex Bennée wrote:
> >> >> GNU Global is a
On 21-01-08 22:30:59, Alex Bennée wrote:
>
> Ben Widawsky writes:
>
> > On 21-01-08 12:19:35, Alex Bennée wrote:
> >> GNU Global is another tags engine which is more like cscope in being
> >> able to support finding both references and definitions. You will be
On 21-01-08 18:44:04, Jonathan Cameron wrote:
> On Tue, 5 Jan 2021 08:52:51 -0800
> Ben Widawsky wrote:
>
> > Fixes since v1 [1]:
> > * Defer introducing some commands/registers not yet used (Ben)
> > * Add stubbed device_reg_init_common() (Ben)
> > * Imp
On 21-01-08 12:19:35, Alex Bennée wrote:
> GNU Global is another tags engine which is more like cscope in being
> able to support finding both references and definitions. You will be
> un-surprised to know it also integrates well with Emacs.
>
> The main benefit of integrating it into find-src-pat
On 21-01-06 11:08:28, Ben Widawsky wrote:
> On 21-01-06 10:05:57, Ben Widawsky wrote:
> > On 21-01-06 17:40:14, Jonathan Cameron wrote:
> > > On Wed, 6 Jan 2021 13:21:23 +
> > > Jonathan Cameron wrote:
> > >
> > > > On Tue, 5 Jan
On 21-01-06 10:05:57, Ben Widawsky wrote:
> On 21-01-06 17:40:14, Jonathan Cameron wrote:
> > On Wed, 6 Jan 2021 13:21:23 +
> > Jonathan Cameron wrote:
> >
> > > On Tue, 5 Jan 2021 08:52:58 -0800
> > > Ben Widawsky wrote:
> > >
[snip]
&
On 21-01-06 17:40:14, Jonathan Cameron wrote:
> 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
> >
On 21-01-06 17:06:41, Jonathan Cameron wrote:
> 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:
> > >
> > >
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
> > includes the CXL Device Capabilities Array Register, as well as all of
> > the CXL Device
On 21-01-06 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)
> > Minor c
the MMIO for the host bridge is.
v2: Update CHBS to spec released definition
Signed-off-by: Ben Widawsky
---
hw/acpi/cxl.c | 69 +
hw/i386/acpi-build.c| 6 ++-
hw/pci-bridge/pci_expander_bridge.c | 21 +
include/hw/acpi
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
1 - 100 of 184 matches
Mail list logo
