Linux CXL
 help / color / mirror / Atom feed
From: Davidlohr Bueso <dave@stgolabs.net>
To: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Gourry <gourry.memverge@gmail.com>,
	qemu-devel@nongnu.org, Gourry <gregory.price@memverge.com>,
	linux-cxl@vger.kernel.org,
	Alison Schofield <alison.schofield@intel.com>,
	"a.manzanares@samsung.com" <a.manzanares@samsung.com>,
	Ben Widawsky <bwidawsk@kernel.org>
Subject: Re: [PATCH RFC] hw/cxl: type 3 devices can now present volatile or persistent memory
Date: Fri, 7 Oct 2022 12:52:48 -0700	[thread overview]
Message-ID: <20221007195248.2i7a44fuujpbfdof@offworld> (raw)
In-Reply-To: <20221006095007.00001271@huawei.com>

On Thu, 06 Oct 2022, Jonathan Cameron wrote:

>One of the blockers for volatile support was that we had no means to poke
>it properly as the kernel doesn't yet support volatile capacity and
>no one has done the relevant work in EDK2 or similar to do it before the kernel boots.
>There has been some work on EDK2 support for ARM N2 FVPs from
>Saanta Pattanayak, but not upstream eyt.
>https://lpc.events/event/16/contributions/1254/

fwiw I had been trying to build some of the firmware bootup for the required
acpi tables that are particular to volatile capacity steps (srat/slit, hmat and
EFI Memory Map) by parameters, but got quickly out of hand. For example, the srat
could use a passed 'node' and have a cxl_build_srat(), etc. But yeah it would
be nice for the EDK2 work to advance on the x86 end.

Thanks,
Davidlohr

diff --git a/hw/acpi/cxl.c b/hw/acpi/cxl.c
index 2bf8c0799359..1c3c6d17c222 100644
--- a/hw/acpi/cxl.c
+++ b/hw/acpi/cxl.c
@@ -254,3 +255,46 @@ void build_cxl_osc_method(Aml *dev)
+static int cxl_device_list(Object *obj, void *opaque)
+{
+    GSList **list = opaque;
+
+    if (object_dynamic_cast(obj, TYPE_CXL_TYPE3)) {
+        *list = g_slist_append(*list, DEVICE(obj));
+    }
+
+    object_child_foreach(obj, cxl_device_list, opaque);
+    return 0;
+}
+
+static GSList *cxl_get_device_list(void)
+{
+    GSList *list = NULL;
+
+    object_child_foreach(qdev_get_machine(), cxl_device_list, &list);
+    return list;
+}
+
+void cxl_build_srat(GArray *table_data)
+{
+    GSList *device_list, *list = cxl_get_device_list();
+
+    for (device_list = list; device_list; device_list = device_list->next) {
+        DeviceState *dev = device_list->data;
+        Object *obj = OBJECT(dev);
+        CXLType3Dev *ct3d = CXL_TYPE3(dev);
+        MemoryRegion *mr;
+        int node;
+
+        mr = host_memory_backend_get_memory(ct3d->hostmem);
+        if (!mr) {
+            continue;
+        }
+        node = object_property_get_uint(obj, "node", &error_abort);
+
+        build_srat_memory(table_data, mr->addr, mr->size, node, MEM_AFFINITY_ENABLED);
+    }
+
+    g_slist_free(list);
+}

      parent reply	other threads:[~2022-10-07 20:13 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20221006000103.49542-1-gregory.price@memverge.com>
2022-10-06  8:45 ` [PATCH RFC] hw/cxl: type 3 devices can now present volatile or persistent memory Jonathan Cameron
2022-10-06  8:50   ` Jonathan Cameron
2022-10-06 15:52     ` Gregory Price
2022-10-06 16:42       ` Jonathan Cameron
2022-10-06 17:29         ` Gregory Price
2022-10-10 14:43           ` Jonathan Cameron
2022-10-10 15:20             ` Gregory Price
2022-10-10 16:26               ` Jonathan Cameron
2022-10-10 16:32             ` Jonathan Cameron
2022-10-10 17:18             ` Davidlohr Bueso
     [not found]           ` <CAD3UvdT1ZHJDaqj05C+n7t4rM7yhjZyM6fooXAfG12rAYnBqmw@mail.gmail.com>
2022-10-10 15:18             ` Jonathan Cameron
2022-10-10 15:25               ` Gregory Price
2022-10-11  1:23                 ` Gregory Price
2022-10-11 17:14                   ` Davidlohr Bueso
2022-10-11 17:22                     ` Gregory Price
2022-10-11 17:28                       ` Jonathan Cameron
2022-10-07 18:16         ` Davidlohr Bueso
2022-10-07 18:46           ` Gregory Price
2022-10-07 19:55             ` Davidlohr Bueso
2022-10-07 19:52     ` Davidlohr Bueso [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20221007195248.2i7a44fuujpbfdof@offworld \
    --to=dave@stgolabs.net \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=a.manzanares@samsung.com \
    --cc=alison.schofield@intel.com \
    --cc=bwidawsk@kernel.org \
    --cc=gourry.memverge@gmail.com \
    --cc=gregory.price@memverge.com \
    --cc=linux-cxl@vger.kernel.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox