From: Jonathan Cameron via <qemu-devel@nongnu.org>
To: Gregory Price <gourry.memverge@gmail.com>
Cc: <qemu-devel@nongnu.org>, <linux-cxl@vger.kernel.org>,
Alison Schofield <alison.schofield@intel.com>,
Davidlohr Bueso <dave@stgolabs.net>, <a.manzanares@samsung.com>,
Ben Widawsky <bwidawsk@kernel.org>,
Gregory Price <gregory.price@memverge.com>, <mst@redhat.com>,
<hchkuo@avery-design.com.tw>, <cbrowy@avery-design.com>,
<ira.weiny@intel.com>
Subject: Re: [PATCH v7 4/5] hw/mem/cxl-type3: Add CXL CDAT Data Object Exchange
Date: Thu, 13 Oct 2022 15:40:21 +0100 [thread overview]
Message-ID: <20221013154021.00007b02@huawei.com> (raw)
In-Reply-To: <Y0gGAW6eRPuv1Y3b@fedora>
On Thu, 13 Oct 2022 08:35:13 -0400
Gregory Price <gourry.memverge@gmail.com> wrote:
> fwiw this is what my function looked like after the prior changes, very
> similar to yours proposed below
Makes sense given only real change is exactly where the size comes from ;)
FYI, I've pushed out latest version on top of qemu/master
at gitlab.com/jic23/ as tag doe-v8
Just as soon as I finish bouncing patches to a machine I can push from
I'll push out the rest of my queue.
My current thought is to slide your series under the rest of that queue
(so directly on top of the DOE set - v8+ depending on reviews).
The other series coming through is Ira's event injection but my guess
is that will take a bit more time to stabilize.
Jonathan
>
> static int ct3_build_cdat_table(CDATSubHeader ***cdat_table,
> void *priv)
> {
> CXLType3Dev *ct3d = priv;
> MemoryRegion *vmr = NULL, *pmr = NULL;
> uint64_t dpa_base = 0;
> int dsmad_handle = 0;
> int num_ents = 0;
> int cur_ent = 0;
> int ret = 0;
>
> if (ct3d->hostvmem) {
> vmr = host_memory_backend_get_memory(ct3d->hostvmem);
> if (!vmr)
> return -EINVAL;
> num_ents += CT3_CDAT_SUBTABLE_SIZE;
> }
> if (ct3d->hostpmem) {
> pmr = host_memory_backend_get_memory(ct3d->hostpmem);
> if (!pmr)
> return -EINVAL;
> num_ents += CT3_CDAT_SUBTABLE_SIZE;
> }
> if (!num_ents) {
> return 0;
> }
>
> *cdat_table = g_malloc0(num_ents * sizeof(*cdat_table));
> if (!*cdat_table) {
> return -ENOMEM;
> }
>
> /* Volatile aspects are mapped first */
> if (vmr) {
> ret = ct3_build_cdat_subtable(*cdat_table, vmr, dsmad_handle++,
> false, dpa_base);
> if (ret < 0) {
> goto error_cleanup;
> }
> dpa_base = vmr->size;
> cur_ent += ret;
> }
> /* Non volatile aspects */
> if (pmr) {
> /* non-volatile entries follow the volatile entries */
> ret = ct3_build_cdat_subtable(&(*cdat_table)[cur_ent], pmr,
> dsmad_handle, true, dpa_base);
> if (ret < 0) {
> goto error_cleanup;
> }
> cur_ent += ret;
> }
> assert(cur_ent == num_ents);
>
> return ret;
> error_cleanup:
> int i;
> for (i = 0; i < num_ents; i++) {
Might as well loop only to cur_ent as the rest will be NULL.
> g_free(*cdat_table[i]);
> }
> g_free(*cdat_table);
> return ret;
> }
>
>
> On Thu, Oct 13, 2022 at 12:53:13PM +0100, Jonathan Cameron wrote:
> > On Thu, 13 Oct 2022 07:36:28 -0400
> > Gregory Price <gourry.memverge@gmail.com> wrote:
> >
> > > Reading through your notes, everything seems reasonable, though I'm not
> > > sure I agree with the two pass notion, though I'll wait to see the patch
> > > set.
> > >
> > > The enum is a good idea, *forehead slap*, I should have done it. If we
> > > have a local enum, why not just make it global (within the file) and
> > > allocate the table as I have once we know how many MRs are present?
> >
> > It's not global as we need the entries to be packed. So if just one mr
> > (which ever one) the entries for that need to be at the beginning of
> > cdat_table. I also don't want to bake into the outer caller that the
> > entries will always be the same size for different MRs.
> >
> > For the two pass case...
> >
> > I'll send code in a few mins, but in meantime my thought is that
> > the extended code for volatile + non volatile will looks something like:
> > (variable names made up)
> >
> > if (ct3d->volatile_mem) {
> > volatile_mr = host_memory_backend_get_memory(ct3d->volatile_mem....);
> > if (!volatile_mr) {
> > return -ENINVAL;
> > }
> > rc = ct3_build_cdat_entries_for_mr(NULL, dsmad++, volatile_mr);
> > if (rc < 0) {
> > return rc;
> > }
> > volatile_len = rc;
> > }
> >
> > if (ct3d->nonvolatile_mem) {
> > nonvolatile_mr = host_memory_backend_get_memory(ct3d->nonvolatile_mem);
> > if (!nonvolatile_mr) {
> > return -ENINVAL;
> > }
> > rc = ct3_build_cdat_entries_for_mr(NULL, dmsmad++, nonvolatile_mr....);
> > if (rc < 0) {
> > return rc;
> > }
> > nonvolatile_len = rc;
> > }
> >
> > dsmad = 0;
> >
> > table = g_malloc(0, (volatile_len + nonvolatile_len) * sizeof(*table));
> > if (!table) {
> > return -ENOMEM;
> > }
> >
> > if (volatile_len) {
> > rc = ct3_build_cdat_entries_for_mr(&table[0], dmsad++, volatile_mr....);
> > if (rc < 0) {
> > return rc;
> > }
> > }
> > if (nonvolatile_len) {
> > rc = ct3_build_cdat_entries_for_mr(&table[volatile_len], dsmad++, nonvolatile_mr...);
> > if (rc < 0) {
> > /* Only place we need error handling. Could make it more generic of course */
> > for (i = 0; i < volatile_len; i++) {
> > g_free(cdat_table[i]);
> > }
> > return rc;
> > }
> > }
> >
> > *cdat_table = g_steal_pointer(&table);
> >
> >
> > Jonathan
> >
> > >
> > > 6 eggs/half dozen though, I'm ultimately fine with either.
> > >
> > > On Thu, Oct 13, 2022, 4:58 AM Jonathan Cameron <Jonathan.Cameron@huawei.com>
> > > wrote:
> > >
> > > > On Wed, 12 Oct 2022 14:21:15 -0400
> > > > Gregory Price <gourry.memverge@gmail.com> wrote:
> > > >
> > > > > Included in this response is a recommended patch set on top of this
> > > > > patch that resolves a number of issues, including style and a heap
> > > > > corruption bug.
> > > > >
> > > > > The purpose of this patch set is to refactor the CDAT initialization
> > > > > code to support future patch sets that will introduce multi-region
> > > > > support in CXL Type3 devices.
> > > > >
> > > > > 1) Checkpatch errors in the immediately prior patch
> > > > > 2) Flatting of code in cdat initialization
> > > > > 3) Changes in allocation and error checking for cleanliness
> > > > > 4) Change in the allocation/free strategy of CDAT sub-tables to simplify
> > > > > multi-region allocation in the future. Also resolves a heap
> > > > > corruption bug
> > > > > 5) Refactor of CDAT initialization code into a function that initializes
> > > > > sub-tables per memory-region.
> > > > >
> > > > > Gregory Price (5):
> > > > > hw/mem/cxl_type3: fix checkpatch errors
> > > > > hw/mem/cxl_type3: Pull validation checks ahead of functional code
> > > > > hw/mem/cxl_type3: CDAT pre-allocate and check resources prior to work
> > > > > hw/mem/cxl_type3: Change the CDAT allocation/free strategy
> > > > > hw/mem/cxl_type3: Refactor CDAT sub-table entry initialization into a
> > > > > function
> > > > >
> > > > > hw/mem/cxl_type3.c | 240 +++++++++++++++++++++++----------------------
> > > > > 1 file changed, 122 insertions(+), 118 deletions(-)
> > > > >
> > > >
> > > > Thanks, I'm going to roll this stuff into the original patch set for v8.
> > > > Some of this I already have (like the check patch stuff).
> > > > Some I may disagree with in which case I'll reply to the patches - note
> > > > I haven't looked at them in detail yet!
> > > >
> > > > Jonathan
> > > >
> > >
> >
next prev parent reply other threads:[~2022-10-13 14:42 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-07 15:21 [PATCH v7 0/5] QEMU PCIe DOE for PCIe 4.0/5.0 and CXL 2.0 Jonathan Cameron via
2022-10-07 15:21 ` [PATCH v7 1/5] hw/pci: PCIe Data Object Exchange emulation Jonathan Cameron via
2022-10-07 15:21 ` [PATCH v7 2/5] hw/mem/cxl-type3: Add MSIX support Jonathan Cameron via
2022-10-07 15:21 ` [PATCH v7 3/5] hw/cxl/cdat: CXL CDAT Data Object Exchange implementation Jonathan Cameron via
2022-10-13 11:04 ` Jonathan Cameron via
2022-10-07 15:21 ` [PATCH v7 4/5] hw/mem/cxl-type3: Add CXL CDAT Data Object Exchange Jonathan Cameron via
2022-10-12 16:01 ` Gregory Price
2022-10-13 10:40 ` Jonathan Cameron via
2022-10-13 10:56 ` Jonathan Cameron via
2022-10-12 18:21 ` Gregory Price
2022-10-12 18:21 ` [PATCH 1/5] hw/mem/cxl_type3: fix checkpatch errors Gregory Price
2022-10-12 18:21 ` [PATCH 2/5] hw/mem/cxl_type3: Pull validation checks ahead of functional code Gregory Price
2022-10-13 9:07 ` Jonathan Cameron via
2022-10-13 10:42 ` Jonathan Cameron via
2022-10-12 18:21 ` [PATCH 3/5] hw/mem/cxl_type3: CDAT pre-allocate and check resources prior to work Gregory Price
2022-10-13 10:44 ` Jonathan Cameron via
2022-10-12 18:21 ` [PATCH 4/5] hw/mem/cxl_type3: Change the CDAT allocation/free strategy Gregory Price
2022-10-13 10:45 ` Jonathan Cameron via
2022-10-12 18:21 ` [PATCH 5/5] hw/mem/cxl_type3: Refactor CDAT sub-table entry initialization into a function Gregory Price
2022-10-13 10:47 ` Jonathan Cameron via
2022-10-13 19:40 ` Gregory Price
2022-10-14 15:29 ` Jonathan Cameron via
2022-10-13 8:57 ` [PATCH v7 4/5] hw/mem/cxl-type3: Add CXL CDAT Data Object Exchange Jonathan Cameron via
2022-10-13 11:36 ` Gregory Price
2022-10-13 11:53 ` Jonathan Cameron via
2022-10-13 12:35 ` Gregory Price
2022-10-13 14:40 ` Jonathan Cameron via [this message]
2022-10-07 15:21 ` [PATCH v7 5/5] hw/pci-bridge/cxl-upstream: Add a CDAT table access DOE Jonathan Cameron via
2022-10-10 10:30 ` [PATCH v7 0/5] QEMU PCIe DOE for PCIe 4.0/5.0 and CXL 2.0 Jonathan Cameron via
2022-10-11 9:45 ` Huai-Cheng
2022-10-11 21:19 ` [PATCH 0/5] Multi-Region and Volatile Memory support for CXL Type-3 Devices Gregory Price
2022-10-11 21:19 ` [PATCH 1/5] hw/cxl: set cxl-type3 device type to PCI_CLASS_MEMORY_CXL Gregory Price
2022-10-11 21:19 ` [PATCH 2/5] hw/cxl: Add CXL_CAPACITY_MULTIPLIER definition Gregory Price
2022-10-11 21:19 ` [PATCH 3/5] hw/mem/cxl_type: Generalize CDATDsmas initialization for Memory Regions Gregory Price
2022-10-12 14:10 ` Jonathan Cameron via
2022-10-11 21:19 ` [PATCH 4/5] hw/cxl: Multi-Region CXL Type-3 Devices (Volatile and Persistent) Gregory Price
2022-10-11 21:19 ` [PATCH 5/5] cxl: update tests and documentation for new cxl properties Gregory Price
2022-10-11 22:20 ` [PATCH 0/5] Multi-Region and Volatile Memory support for CXL Type-3 Devices Michael S. Tsirkin
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=20221013154021.00007b02@huawei.com \
--to=qemu-devel@nongnu.org \
--cc=Jonathan.Cameron@huawei.com \
--cc=a.manzanares@samsung.com \
--cc=alison.schofield@intel.com \
--cc=bwidawsk@kernel.org \
--cc=cbrowy@avery-design.com \
--cc=dave@stgolabs.net \
--cc=gourry.memverge@gmail.com \
--cc=gregory.price@memverge.com \
--cc=hchkuo@avery-design.com.tw \
--cc=ira.weiny@intel.com \
--cc=linux-cxl@vger.kernel.org \
--cc=mst@redhat.com \
/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;
as well as URLs for NNTP newsgroup(s).