On Tue, 25 Oct 2022 20:47:36 -0400
Gregory Price wrote:
> This commit enables each CXL Type-3 device to contain one volatile
> memory region and one persistent region.
>
> Two new properties have been added to cxl-type3 device initialization:
> [volatile-memdev] and [persistent-memdev]
>
>
On Tue, 25 Oct 2022 20:47:35 -0400
Gregory Price wrote:
> Remove usage of magic numbers when accessing capacity fields and replace
> with CXL_CAPACITY_MULTIPLIER, matching the kernel definition.
>
> Signed-off-by: Gregory Price
> Reviewed-by: Davidlohr Bueso
Makes sense. I'll add it to my loca
On Mon, 14 Nov 2022 18:00:59 -0500
Gregory Price wrote:
> On Mon, Nov 14, 2022 at 05:53:41PM +, Jonathan Cameron wrote:
> > Hi Gregory,
> >
> > I've not been rushing on this purely because we are after the feature
> > freeze for this QEMU cycle so no great rush to line up new features
> > (a
First CC list is a guess as I haven't managed to root cause where things are
going wrong yet.
Originally hit this whilst rebasing some CXL patches on v7.2.0-rc1.
CXL makes extensive use of memory-backends and most my tests happen
to use memory-backend-file
Issue seen on arm64 and x86 though helpf
On Mon, 21 Nov 2022 11:47:48 -0500
Stefan Hajnoczi wrote:
> On Mon, 21 Nov 2022 at 11:22, Jonathan Cameron via
> wrote:
> >
> > First CC list is a guess as I haven't managed to root cause where things are
> > going wrong yet.
> >
> > Originally hit
On Sun, 4 Dec 2022 08:23:55 +0100
Thomas Huth wrote:
> On 04/11/2022 07.47, Thomas Huth wrote:
> > On 16/06/2022 18.57, Michael S. Tsirkin wrote:
> >> From: Jonathan Cameron
> >>
> >> Emulation of a simple CXL Switch downstream port.
> >> The Device ID has been allocated for this use.
> >>
> >
On Mon, 5 Dec 2022 10:54:03 +
Jonathan Cameron via wrote:
> On Sun, 4 Dec 2022 08:23:55 +0100
> Thomas Huth wrote:
>
> > On 04/11/2022 07.47, Thomas Huth wrote:
> > > On 16/06/2022 18.57, Michael S. Tsirkin wrote:
> > >> From: Jonathan Cameron
>
Peter Maydell reported both these issues, having looked into Coverity
identified issues. The memory leak was straight forward, but testing the
second patch identified a bug in the Linux kernel.
This bug has been fixed in the series
https://lore.kernel.org/linux-cxl/165973125417.1526540.14425647258
Two issues were present in this code:
1) Check on which register to look in was inverted.
2) Both branches use the _LO register.
Whilst here moved to extract32() rather than hand rolling
the field extraction as simpler and hopefully less error prone.
Fixes Coverity CID: 1488873
Reported-by: Pete
Use g_autofree to free the CXLFixedWindow structure if an
error occurs in configuration before we have added to
the list (via g_steal_pointer())
Fix Coverity CID: 1488872
Reported-by: Peter Maydell
Signed-off-by: Jonathan Cameron
---
hw/cxl/cxl-host.c | 5 +++--
1 file changed, 3 insertions(+)
On Fri, 5 Aug 2022 10:20:23 +0800
Bobo WL wrote:
> Hi list
>
> I want to test cxl functions in arm64, and found some problems I can't
> figure out.
Hi Bob,
Glad to see people testing this code.
>
> My test environment:
>
> 1. build latest bios from https://github.com/tianocore/edk2.git maste
On Tue, 9 Aug 2022 21:07:06 +0800
Bobo WL wrote:
> Hi Jonathan
>
> Thanks for your reply!
>
> On Mon, Aug 8, 2022 at 8:37 PM Jonathan Cameron
> wrote:
> >
> > Probably not related to your problem, but there is a disconnect in QEMU /
> > kernel assumptionsaround the presence of an HDM decoder w
On Tue, 9 Aug 2022 17:08:25 +0100
Jonathan Cameron wrote:
> On Tue, 9 Aug 2022 21:07:06 +0800
> Bobo WL wrote:
>
> > Hi Jonathan
> >
> > Thanks for your reply!
> >
> > On Mon, Aug 8, 2022 at 8:37 PM Jonathan Cameron
> > wrote:
> > >
> > > Probably not related to your problem, but there is
On Thu, 11 Aug 2022 18:08:57 +0100
Jonathan Cameron via wrote:
> On Tue, 9 Aug 2022 17:08:25 +0100
> Jonathan Cameron wrote:
>
> > On Tue, 9 Aug 2022 21:07:06 +0800
> > Bobo WL wrote:
> >
> > > Hi Jonathan
> > >
> > > Thanks for y
On Fri, 12 Aug 2022 09:03:02 -0700
Dan Williams wrote:
> Jonathan Cameron wrote:
> > On Thu, 11 Aug 2022 18:08:57 +0100
> > Jonathan Cameron via wrote:
> >
> > > On Tue, 9 Aug 2022 17:08:25 +0100
> > > Jonathan Cameron wrote:
> > >
> &
On Tue, 18 Jul 2023 17:30:57 -0400
Gregory Price wrote:
> On Mon, Jul 17, 2023 at 06:16:39PM +0100, Jonathan Cameron wrote:
> > @@ -397,8 +401,9 @@ struct CXLType3Dev {
> > AddressSpace hostpmem_as;
> > CXLComponentState cxl_cstate;
> > CXLDeviceState cxl_dstate;
> > -CXLCCI cc
On Wed, 19 Jul 2023 14:49:07 -0400
Gregory Price wrote:
> On Wed, Jul 19, 2023 at 09:19:47AM +0100, Jonathan Cameron wrote:
> > On Tue, 18 Jul 2023 17:30:57 -0400
> > Gregory Price wrote:
> >
> > > On Mon, Jul 17, 2023 at 06:16:39PM +0100, Jonathan Cameron wrote:
> > > > @@ -397,8 +401,9 @@
On Sat, 22 Jul 2023 21:52:06 -0700
Ira Weiny wrote:
> nifan@ wrote:
> > From: Fan Ni
> >
> > The patch series provides dynamic capacity device (DCD) emulation in Qemu.
>
> I don't the patches on the list.
>
> https://lore.kernel.org/all/sg2pr06mb33976bb3f9c47cbe08f02d09b2...@sg2pr06mb3397.a
On Tue, 1 Aug 2023 18:35:10 +0800
Zhao Liu wrote:
> From: Zhao Liu
>
> Hi list,
>
> This is the our v3 patch series, rebased on the master branch at the
> commit 234320cd0573 ("Merge tag 'pull-target-arm-20230731' of https:
> //git.linaro.org/people/pmaydell/qemu-arm into staging").
>
> Comp
On Tue, 25 Jul 2023 18:39:55 +
Fan Ni wrote:
> From: Fan Ni
>
> Based on CXL spec 3.0 Table 8-94 (Identify Memory Device Output
> Payload), dynamic capacity event log size should be part of
> output of the Identify command.
> Add dc_event_log_size to the output payload for the host to get t
On Fri, 21 Jul 2023 12:35:04 -0400
Gregory Price wrote:
Typo in patch title. reference
> This allows devices to have fully customized CCIs, along with complex
> devices where wrapper devices can override or add additional CCI
> commands without having to replicate full command structures or
> po
On Fri, 21 Jul 2023 12:35:06 -0400
Gregory Price wrote:
> This enables wrapper devices to customize the base device's CCI
> (for example, with custom commands outside the specification)
> without the need to change the base device.
>
> The also enabled the base device to dispatch those commands
On Tue, 25 Jul 2023 18:39:55 +
Fan Ni wrote:
> From: Fan Ni
You should fix the author on these to match the SoB
git commit --amend --author="Fan Ni " fixes them.
I'm trying to pick these up for my tree as I review them (where they aren't
invasive). So I'll fix this stuff whilst doing so.
On Tue, 25 Jul 2023 18:39:55 +
Fan Ni wrote:
> From: Fan Ni
>
> Rename mem_size as static_mem_size for type3 memdev to cover static RAM and
> pmem capacity, preparing for the introduction of dynamic capacity to support
> dynamic capacity devices.
>
> Signed-off-by: Fan Ni
Looks good. I'v
On Tue, 25 Jul 2023 18:39:55 +
Fan Ni wrote:
> From: Fan Ni
>
> With the change, when setting up memory for type3 memory device, we can
> create DC regions
> A property 'num-dc-regions' is added to ct3_props to allow users to pass the
> number of DC regions to create. To make it easier, oth
On Tue, 25 Jul 2023 18:39:56 +
Fan Ni wrote:
> From: Fan Ni
>
> Add (file/memory backed) host backend, all the dynamic capacity regions
> will share a single, large enough host backend. Set up address space for
> DC regions to support read/write operations to dynamic capacity for DCD.
>
>
On Tue, 25 Jul 2023 18:39:56 +
Fan Ni wrote:
> From: Fan Ni
>
> Not all dpa range in the dc regions is valid to access until an extent
> covering the range has been added. Add a bitmap for each region to
> record whether a dc block in the region has been backed by dc extent.
> For the bitma
On Mon, 7 Aug 2023 09:53:42 +0100
Jonathan Cameron via wrote:
> On Tue, 25 Jul 2023 18:39:56 +
> Fan Ni wrote:
>
> > From: Fan Ni
> >
> > Not all dpa range in the dc regions is valid to access until an extent
> > covering the range has been added
On Fri, 23 Feb 2024 16:56:51 +0800
Zhao Liu wrote:
> From: Zhao Liu
>
> As the comment in qapi/error, dereferencing @errp requires
> ERRP_GUARD():
>
> * = Why, when and how to use ERRP_GUARD() =
> *
> * Without ERRP_GUARD(), use of the @errp parameter is restricted:
> * - It must not be derefe
On Fri, 23 Feb 2024 16:56:47 +0800
Zhao Liu wrote:
> From: Zhao Liu
>
> As the comment in qapi/error, dereferencing @errp requires
> ERRP_GUARD():
>
> * = Why, when and how to use ERRP_GUARD() =
> *
> * Without ERRP_GUARD(), use of the @errp parameter is restricted:
> * - It must not be derefe
On Fri, 23 Feb 2024 16:56:49 +0800
Zhao Liu wrote:
> From: Zhao Liu
>
> As the comment in qapi/error, dereferencing @errp requires
> ERRP_GUARD():
>
> * = Why, when and how to use ERRP_GUARD() =
> *
> * Without ERRP_GUARD(), use of the @errp parameter is restricted:
> * - It must not be derefe
On Fri, 23 Feb 2024 12:42:23 +
wrote:
> From: Ankit Agrawal
>
> ACPI spec provides a scheme to associate "Generic Initiators" [1]
> (e.g. heterogeneous processors and accelerators, GPUs, and I/O devices with
> integrated compute or DMA engines GPUs) with Proximity Domains. This is
> achieve
On Fri, 23 Feb 2024 12:42:23 +
wrote:
> From: Ankit Agrawal
>
> ACPI spec provides a scheme to associate "Generic Initiators" [1]
> (e.g. heterogeneous processors and accelerators, GPUs, and I/O devices with
> integrated compute or DMA engines GPUs) with Proximity Domains. This is
> achieve
On Wed, 21 Feb 2024 10:15:55 -0800
nifan@gmail.com wrote:
> From: Fan Ni
>
> Per cxl spec r3.1, add dynamic capacity region representative based on
> Table 8-165 and extend the cxl type3 device definition to include dc region
> information. Also, based on info in 8.2.9.9.9.1, add 'Get Dynami
On Wed, 21 Feb 2024 10:15:57 -0800
nifan@gmail.com wrote:
> From: Fan Ni
>
> With the change, when setting up memory for type3 memory device, we can
> create DC regions.
> A property 'num-dc-regions' is added to ct3_props to allow users to pass the
> number of DC regions to create. To make i
On Wed, 21 Feb 2024 10:15:59 -0800
nifan@gmail.com wrote:
> From: Fan Ni
>
> Add (file/memory backed) host backend, all the dynamic capacity regions
> will share a single, large enough host backend. Set up address space for
> DC regions to support read/write operations to dynamic capacity fo
On Wed, 21 Feb 2024 10:16:00 -0800
nifan@gmail.com wrote:
> From: Fan Ni
>
> Add dynamic capacity extent list representative to the definition of
> CXLType3Dev and add get DC extent list mailbox command per
> CXL.spec.3.1:.8.2.9.9.9.2.
>
> Signed-off-by: Fan Ni
Follow on from earlier comme
On Wed, 21 Feb 2024 10:16:01 -0800
nifan@gmail.com wrote:
> From: Fan Ni
>
> Per CXL spec 3.1, two mailbox commands are implemented:
> Add Dynamic Capacity Response (Opcode 4802h) 8.2.9.9.9.3, and
> Release Dynamic Capacity (Opcode 4803h) 8.2.9.9.9.4.
>
> Signed-off-by: Fan Ni
Hi Fan,
C
On Wed, 21 Feb 2024 10:16:02 -0800
nifan@gmail.com wrote:
> From: Fan Ni
>
> Since fabric manager emulation is not supported yet, the change implements
> the functions to add/release dynamic capacity extents as QMP interfaces.
>
> Note: we skips any FM issued extent release request if the e
On Mon, 26 Feb 2024 17:01:22 -0800
fan wrote:
> On Mon, Feb 26, 2024 at 06:04:17PM +, Jonathan Cameron wrote:
> > On Wed, 21 Feb 2024 10:16:01 -0800
> > nifan@gmail.com wrote:
> >
> > > From: Fan Ni
> > >
> > > Per CXL spec 3.1, two mailbox commands are implemented:
> > > Add Dynamic
On Tue, 27 Feb 2024 17:20:25 +0800
Zhao Liu wrote:
> Hi Jonathan,
>
> > Hi Zhao Liu
> >
> > I like the scheme. Strikes a good balance between complexity of description
> > and systems that actually exist. Sure there are systems with more cache
> > levels etc but they are rare and support can b
On Fri, 23 Feb 2024 12:42:23 +
wrote:
> From: Ankit Agrawal
>
> ACPI spec provides a scheme to associate "Generic Initiators" [1]
> (e.g. heterogeneous processors and accelerators, GPUs, and I/O devices with
> integrated compute or DMA engines GPUs) with Proximity Domains. This is
> achieve
> diff --git a/include/hw/acpi/acpi-generic-initiator.h
> b/include/hw/acpi/acpi-generic-initiator.h
> new file mode 100644
> index 00..2f183b029a
> --- /dev/null
> +++ b/include/hw/acpi/acpi-generic-initiator.h
> +typedef struct AcpiGenericInitiatorClass {
> +ObjectClass parent
On Tue, 27 Feb 2024 08:37:15 +
Ankit Agrawal wrote:
> Thanks Jonathan for reviewing the change.
>
> Comments inline.
>
> >> The structure needs a PCI device handle [2] that consists of the device
> >> BDF.
> >> The vfio-pci device corresponding to the acpi-generic-initiator object is
> >>
On Tue, 27 Feb 2024 17:11:15 +
Jonathan Cameron via wrote:
> On Tue, 27 Feb 2024 08:37:15 +
> Ankit Agrawal wrote:
>
> > Thanks Jonathan for reviewing the change.
> >
> > Comments inline.
> >
> > >> The structure needs a PCI device handl
> > ##
> > # @RngProperties:
> > #
> > @@ -911,6 +926,7 @@
> > ##
> > { 'enum': 'ObjectType',
> >'data': [
> > +'acpi-generic-initiator',
> > 'authz-list',
> > 'authz-listfile',
> > 'authz-pam',
> > @@ -981,6 +997,7 @@
> > 'id': 'str' },
> >'discrimina
On Wed, 28 Feb 2024 16:50:30 +
Ankit Agrawal wrote:
> >>> Jonathan, you pointed out interface design issues in your review of v2.>
> >> Are you fully satisfied with the interface in v3?
> >>
> >> Yes. I'm fine with the interface in this version (though it's v7, so I'm
> >> lost
> >> on v2
On Thu, 29 Feb 2024 11:22:24 +0100
Heinrich Schuchardt wrote:
> On 29.02.24 02:11, Peter Xu wrote:
> > On Wed, Feb 28, 2024 at 08:07:47PM +0100, Heinrich Schuchardt wrote:
> >> On 28.02.24 19:39, Peter Maydell wrote:
> >>> On Wed, 28 Feb 2024 at 18:28, Heinrich Schuchardt
> >>> wrote:
> >>
On Thu, 15 Feb 2024 14:28:14 +
Jonathan Cameron via wrote:
Any comments? Almost all the other fixes I need for CXL memory to
work as normal ram are queued up so I'd love it if we can solve this one as
well.
This looks like a big series, but it's really just a refactor + trivia
On Thu, 29 Feb 2024 09:38:29 +
Peter Maydell wrote:
> On Wed, 28 Feb 2024 at 19:07, Heinrich Schuchardt
> wrote:
> >
> > On 28.02.24 19:39, Peter Maydell wrote:
> > > The limitation to a page dates back to commit 6d16c2f88f2a in 2009,
> > > which was the first implementation of this functi
On Thu, 29 Feb 2024 11:43:44 +
Ankit Agrawal wrote:
> > One thing I forgot.
> >
> > Please add a test. tests/qtest/bios-tables-test.c
>
> IIUC, we need to add a test for aarch64 to test the interface with the
> acpi-generic-initiator object.
>
> > + relevant table dumps.
>
> Sorry it
On Thu, 29 Feb 2024 11:46:27 +
Ankit Agrawal wrote:
> >> ---
> >> hw/acpi/acpi-generic-initiator.c | 84
> >> hw/arm/virt-acpi-build.c | 3 +
> >> include/hw/acpi/acpi-generic-initiator.h | 26
> > A few more comments.
> >
> > Maybe
On Tue, 27 Feb 2024 17:36:21 +
Jonathan Cameron wrote:
> On Tue, 27 Feb 2024 17:11:15 +
> Jonathan Cameron via wrote:
>
> > On Tue, 27 Feb 2024 08:37:15 +
> > Ankit Agrawal wrote:
> >
> > > Thanks Jonathan for reviewing the
Two unrelated fixes here:
1) Linux really doesn't like it when you claim non existent memory
is directly connected to an initiator (here a CPU).
It is a nonsense entry, though I also plan to try and get
a relaxation of the condition into the kernel.
Maybe we need to care about migration
If qemu is started with a proximity node containing CPUs alone,
it will provide one of these structures to say memory in this
node is directly connected to itself.
This description is arguably pointless even if there is memory
in the node. If there is no memory present, and hence no SRAT
entry it
With a numa set up such as
-numa nodeid=0,cpus=0 \
-numa nodeid=1,memdev=mem \
-numa nodeid=2,cpus=1
and appropriate hmat_lb entries the initiator list is correctly
computed and writen to HMAT as 0,2 but then the LB data is accessed
using the node id (here 2), landing outside the entry_list array
On Thu, 29 Feb 2024 13:00:27 +
Ankit Agrawal wrote:
> >> >>> Jonathan, you pointed out interface design issues in your review of
> >> >>> v2.>
> >> >> Are you fully satisfied with the interface in v3?
> >> >>
> >> >> Yes. I'm fine with the interface in this version (though it's v7, so
> >
On Thu, 29 Feb 2024 12:28:51 -0500
Gregory Price wrote:
> On Thu, Feb 29, 2024 at 04:25:44PM +, Jonathan Cameron wrote:
> > If qemu is started with a proximity node containing CPUs alone,
> > it will provide one of these structures to say memory in this
> > node is directly connected to itsel
On Mon, 4 Mar 2024 11:44:04 +0100
Thomas Huth wrote:
> When setting GLIB_VERSION_MAX_ALLOWED to GLIB_VERSION_2_58 or higher
> (which we'll certainly do in the not too distant future), glib adds
> type safety checks to the g_steal_pointer() macro. This trigger an
> error in the ct3_load_cdat() fu
On Mon, 4 Mar 2024 11:44:05 +0100
Thomas Huth wrote:
> When setting GLIB_VERSION_MAX_ALLOWED to GLIB_VERSION_2_58 or higher,
> glib adds type safety checks to the g_steal_pointer() macro. This
> triggers errors in the build_cdat_table() function which uses the
> g_steal_pointer() for type-castin
On Mon, 4 Mar 2024 11:44:06 +0100
Thomas Huth wrote:
> When setting GLIB_VERSION_MAX_ALLOWED to GLIB_VERSION_2_58 or higher,
> glib adds type safety checks to the g_steal_pointer() macro. This
> triggers errors in the ct3_build_cdat_entries_for_mr() function which
> uses the g_steal_pointer() fo
On Mon, 4 Mar 2024 15:06:51 +
Jonathan Cameron wrote:
> On Mon, 4 Mar 2024 11:44:05 +0100
> Thomas Huth wrote:
>
> > When setting GLIB_VERSION_MAX_ALLOWED to GLIB_VERSION_2_58 or higher,
> > glib adds type safety checks to the g_steal_pointer() macro. This
> > triggers errors in the build_
On Tue, 5 Mar 2024 08:17:18 +
Ankit Agrawal wrote:
> >>> Please add a test. tests/qtest/bios-tables-test.c
> >>> + relevant table dumps.
> >>
> >> Here I need to add a test that creates a vfio-pci device and numa
> >> nodes and link using the acpi-generic-initiator object. One thing
> >> h
On Tue, 5 Mar 2024 08:27:52 +0100
Thomas Huth wrote:
> On 04/03/2024 16.10, Jonathan Cameron wrote:
> > On Mon, 4 Mar 2024 11:44:06 +0100
> > Thomas Huth wrote:
> >
> >> When setting GLIB_VERSION_MAX_ALLOWED to GLIB_VERSION_2_58 or higher,
> >> glib adds type safety checks to the g_steal_poi
On Mon, 4 Mar 2024 11:34:08 -0800
nifan@gmail.com wrote:
> From: Fan Ni
>
> With the change, we add the following two QMP interfaces to print out
> extents information in the device,
> 1. cxl-display-accepted-dc-extents: print out the accepted DC extents in
>the device;
> 2. cxl-display
On Mon, 26 Feb 2024 16:42:29 +
Jonathan Cameron via wrote:
> On Fri, 23 Feb 2024 12:42:23 +
> wrote:
>
> > From: Ankit Agrawal
> >
> > ACPI spec provides a scheme to associate "Generic Initiators" [1]
> > (e.g. heterogeneous processors a
On Wed, 6 Mar 2024 10:33:17 +
Ankit Agrawal wrote:
> >> >> Jonathan, Alex, do you know how we may add tests that is dependent
> >> >> on the vfio-pci device?
> >> >
> >> > There are none.
> >> >
> >> > This would require a host device always available for passthrough and
> >> > there is no
On Wed, 6 Mar 2024 19:27:07 +0800
Yuquan Wang wrote:
> Hello, Jonathan
>
> Recently I met some problems on CXL RAS tests.
>
> I tried to use "cxl-inject-uncorrectable-errors" and
> "cxl-inject-correctable-error"
> qmp to inject CXL errors, however, there was no any kernel printing
> informat
On Wed, 6 Mar 2024 12:33:16 +
wrote:
> From: Ankit Agrawal
>
> NVIDIA GPU's support MIG (Mult-Instance GPUs) feature [1], which allows
> partitioning of the GPU device resources (including device memory) into
> several (upto 8) isolated instances. Each of the partitioned memory needs
> a de
On Wed, 6 Mar 2024 12:33:17 +
wrote:
> From: Ankit Agrawal
>
> ACPI spec provides a scheme to associate "Generic Initiators" [1]
> (e.g. heterogeneous processors and accelerators, GPUs, and I/O devices with
> integrated compute or DMA engines GPUs) with Proximity Domains. This is
> achieved
...
> > > I cannot find anything specific to this in the specification either.
> > > Since we have already detected the case where the extent range across
> > > multiple regions, the only case we need to capture here is one/multiple
> > > portions of an extents getting released and causing extent
On Thu, 22 Feb 2024 09:07:03 -1000
Richard Henderson wrote:
> On 2/19/24 07:31, Jonathan Cameron wrote:
> > v2: Changes documented in patch 3.
> > - I have not addressed Richard's comment on recursive locks as that
> > seems to be a more general issue not specific to this patch set.
> >
On Wed, 21 Feb 2024 14:18:11 -0800
nifan@gmail.com wrote:
> From: Fan Ni
>
> The whole mailbox output payload space is already zeroed after copying
> out the input payload, which happens before processing the specific mailbox
> command:
> https://elixir.bootlin.com/qemu/v8.2.1/source/hw/cxl/
On Mon, 4 Mar 2024 11:33:56 -0800
nifan@gmail.com wrote:
> From: Fan Ni
>
> Based on CXL spec r3.1 Table 8-127 (Identify Memory Device Output
> Payload), dynamic capacity event log size should be part of
> output of the Identify command.
> Add dc_event_log_size to the output payload for the
On Mon, 4 Mar 2024 11:33:57 -0800
nifan@gmail.com wrote:
> From: Fan Ni
>
> Per cxl spec r3.1, add dynamic capacity region representative based on
> Table 8-165 and extend the cxl type3 device definition to include dc region
> information. Also, based on info in 8.2.9.9.9.1, add 'Get Dynami
On Mon, 4 Mar 2024 11:33:58 -0800
nifan@gmail.com wrote:
> From: Fan Ni
>
> Rename mem_size as static_mem_size for type3 memdev to cover static RAM and
> pmem capacity, preparing for the introduction of dynamic capacity to support
> dynamic capacity devices.
>
> Signed-off-by: Fan Ni
Revi
On Mon, 4 Mar 2024 11:33:59 -0800
nifan@gmail.com wrote:
> From: Fan Ni
>
> With the change, when setting up memory for type3 memory device, we can
> create DC regions.
> A property 'num-dc-regions' is added to ct3_props to allow users to pass the
> number of DC regions to create. To make i
On Mon, 4 Mar 2024 11:34:00 -0800
nifan@gmail.com wrote:
> From: Fan Ni
>
> The function ct3_build_cdat_entries_for_mr only uses size of the passed
> memory region argument, refactor the function definition to make the passed
> arguments more specific.
Typo in title, instead
On Mon, 4 Mar 2024 11:34:00 -0800
nifan@gmail.com wrote:
> From: Fan Ni
>
> The function ct3_build_cdat_entries_for_mr only uses size of the passed
> memory region argument, refactor the function definition to make the passed
> arguments more specific.
>
> Signed-off-by: Fan Ni
Reviewed-b
On Mon, 4 Mar 2024 11:34:01 -0800
nifan@gmail.com wrote:
> From: Fan Ni
>
> Add (file/memory backed) host backend, all the dynamic capacity regions
> will share a single, large enough host backend. Set up address space for
> DC regions to support read/write operations to dynamic capacity fo
On Mon, 4 Mar 2024 11:34:02 -0800
nifan@gmail.com wrote:
> From: Fan Ni
>
> Add dynamic capacity extent list representative to the definition of
> CXLType3Dev and add get DC extent list mailbox command per
> CXL.spec.3.1:.8.2.9.9.9.2.
>
> Signed-off-by: Fan Ni
Hi Fan,
A small thing in he
On Mon, 4 Mar 2024 11:34:03 -0800
nifan@gmail.com wrote:
> From: Fan Ni
>
> Per CXL spec 3.1, two mailbox commands are implemented:
> Add Dynamic Capacity Response (Opcode 4802h) 8.2.9.9.9.3, and
> Release Dynamic Capacity (Opcode 4803h) 8.2.9.9.9.4.
>
> Signed-off-by: Fan Ni
Hmm. So I h
On Mon, 4 Mar 2024 11:34:04 -0800
nifan@gmail.com wrote:
> From: Fan Ni
>
> Since fabric manager emulation is not supported yet, the change implements
> the functions to add/release dynamic capacity extents as QMP interfaces.
We'll need them anyway, or to implement an fm interface via QMP
On Mon, 4 Mar 2024 11:34:05 -0800
nifan@gmail.com wrote:
> From: Fan Ni
>
> Not all dpa range in the DC regions is valid to access until an extent
All DPA ranges in the DC regions are invalid to access until an extent
covering the range has been added.
> covering the range has been added.
On Mon, 4 Mar 2024 11:34:06 -0800
nifan@gmail.com wrote:
> From: Fan Ni
>
> With the change, we extend the extent release mailbox command processing
> to allow more flexible release. As long as the DPA range of the extent to
> release is covered by valid extent(s) in the device, the release
On Mon, 4 Mar 2024 11:34:07 -0800
nifan@gmail.com wrote:
> From: Fan Ni
>
> Before the change, the QMP interface used for add/release DC extents
> only allows to release extents that exist in either pending-to-add list
> or accepted list in the device, which means the DPA range of the exten
On Thu, 7 Mar 2024 03:03:02 +
Ankit Agrawal wrote:
> >>
> >> [1] ACPI Spec 6.3, Section 5.2.16.6
> >> [2] ACPI Spec 6.3, Table 5.80
> >>
> >> Cc: Jonathan Cameron
> >> Cc: Alex Williamson
> >> Cc: Cedric Le Goater
> >> Signed-off-by: Ankit Agrawal
> >
> > I guess we gloss over the bisec
On Thu, 7 Mar 2024 10:58:56 +1000
Alistair Francis wrote:
> The Security Protocol and Data Model (SPDM) Specification defines
> messages, data objects, and sequences for performing message exchanges
> over a variety of transport and physical media.
> -
> https://www.dmtf.org/sites/default/file
> > > @@ -868,16 +974,24 @@ static int cxl_type3_hpa_to_as_and_dpa(CXLType3Dev
> > > *ct3d,
> > > AddressSpace **as,
> > > uint64_t *dpa_offset)
> > > {
> > > -MemoryRegion *vmr = NULL, *pmr = NULL;
> > > +Mem
On Wed, 6 Mar 2024 13:39:50 -0800
fan wrote:
> > > +}
> > > +if (len2) {
> > > +cxl_insert_extent_to_extent_list(extent_list,
> > > dpa + len,
> > > + len2, NULL, 0);
> > > +
> > > +static void cxl_destroy_dc_regions(CXLType3Dev *ct3d)
> > > +{
> > > +CXLDCExtent *ent;
> > > +
> > > +while (!QTAILQ_EMPTY(&ct3d->dc.extents)) {
> > > +ent = QTAILQ_FIRST(&ct3d->dc.extents);
> > > +cxl_remove_extent_from_extent_list(&ct3d->dc.extents, ent);
> >
>
...
> > > +list = records;
> > > +extents = g_new0(CXLDCExtentRaw, num_extents);
> > > +while (list) {
> > > +CXLDCExtent *ent;
> > > +bool skip_extent = false;
> > > +
> > > +offset = list->value->offset;
> > > +len = list->value->len;
> > > +
> > > +
> >
> > > + * remove it from the pending extent list, so later when the
> > > add
> > > + * response for the extent arrives, the device can reject the
> > > + * extent as it is not in the pending list.
> > > + */
> > > +ent = cxl_dc_
On Fri, 1 Mar 2024 13:35:26 +0800
Peter Xu wrote:
> On Fri, Mar 01, 2024 at 01:29:04PM +0800, Peter Xu wrote:
> > On Thu, Feb 15, 2024 at 02:28:16PM +, Jonathan Cameron wrote:
> > > This code will be reused for the address_space_cached accessors
> > > shortly.
> > >
> > > Also reduce scope
On Fri, 1 Mar 2024 13:44:01 +0800
Peter Xu wrote:
> On Thu, Feb 15, 2024 at 02:28:17PM +, Jonathan Cameron wrote:
>
> Can we rename the subject?
>
> physmem: Fix wrong MR in large address_space_read/write_cached_slow()
>
> IMHO "wrong MR" is misleading, as the MR was wrong only because t
v2: (Thanks to Peter Xu for reviewing!)
- New patch 1 to rename addr1 to mr_addr in the interests of meaningful naming.
- Take advantage of a cached address space only allow for a single MR to
simplify
the new code.
- Various cleanups of indentation etc.
- Cover letter and some patch description
The calls to flatview_read/write[_continue]() have parameters addr and
addr1 but the names give no indication of what they are addresses of.
Rename addr1 to mr_addr to reflect that it is the translated address
offset within the MemoryRegion returned by flatview_translate().
Similarly rename the par
Precursor to factoring out the inner loops for reuse.
Reviewed-by: Peter Xu
Signed-off-by: Jonathan Cameron
---
v2: Picked up tag from Peter.
system/physmem.c | 40
1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/system/physmem.c b/system
This code will be reused for the address_space_cached accessors
shortly.
Also reduce scope of result variable now we aren't directly
calling this in the loop.
Signed-off-by: Jonathan Cameron
---
v2: Thanks to Peter Xu
- Fix alignment of code.
- Drop unused addr parameter.
- Carry through new mr_
If the access is bigger than the MemoryRegion supports,
flatview_read/write_continue() will attempt to update the Memory Region.
but the address passed to flatview_translate() is relative to the cache, not
to the FlatView.
On arm/virt with interleaved CXL memory emulation and virtio-blk-pci this
l
1 - 100 of 2329 matches
Mail list logo
