From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
To: Fan Ni <nifan.cxl@gmail.com>
Cc: <anisa.su887@gmail.com>, <qemu-devel@nongnu.org>,
<dave@stgolabs.net>, <linux-cxl@vger.kernel.org>,
Anisa Su <anisa.su@samsung.com>
Subject: Re: [PATCH 3/9] cxl/type3: Add dsmas_flags to CXLDCRegion struct
Date: Fri, 2 May 2025 10:01:55 +0100 [thread overview]
Message-ID: <20250502100155.00003bfa@huawei.com> (raw)
In-Reply-To: <aBPV80J9TULzRslk@fanair.local>
On Thu, 1 May 2025 20:21:56 +0000
Fan Ni <nifan.cxl@gmail.com> wrote:
> On Thu, Apr 24, 2025 at 11:42:59AM +0100, Jonathan Cameron wrote:
> > On Mon, 17 Mar 2025 16:31:30 +0000
> > anisa.su887@gmail.com wrote:
> >
> > > From: Anisa Su <anisa.su@samsung.com>
> > >
> > > Add dsmas_flags field to DC Region struct in preparation for next
> > > command, which returns the dsmas flags in the response.
> > >
> > > Signed-off-by: Anisa Su <anisa.su@samsung.com>
> > > ---
> > > hw/mem/cxl_type3.c | 2 ++
> > > include/hw/cxl/cxl_device.h | 1 +
> > > 2 files changed, 3 insertions(+)
> > >
> > > diff --git a/hw/mem/cxl_type3.c b/hw/mem/cxl_type3.c
> > > index 731497ebda..452a0c101a 100644
> > > --- a/hw/mem/cxl_type3.c
> > > +++ b/hw/mem/cxl_type3.c
> > > @@ -237,6 +237,8 @@ static int ct3_build_cdat_table(CDATSubHeader ***cdat_table, void *priv)
> > > ct3d->dc.regions[i].len,
> > > false, true, region_base);
> > > ct3d->dc.regions[i].dsmadhandle = dsmad_handle - 1;
> > > + CDATDsmas *dsmas = (CDATDsmas *) table[cur_ent + CT3_CDAT_DSMAS];
> > > + ct3d->dc.regions[i].dsmas_flags = dsmas->flags;
> >
> Hi Jonathan,
> Thanks for the feedback.
> > This is relying to much on the ordering of creating fields in
> > ct3_build_cdat_entries_for_mr().
> I am not sure whether I understand this clearly.
> In current qemu implemtation, each mr (ram,pmem or dc region) will have the
> whole set of cdat table entries (dsmas, dslbis0-3, etc), so as long as we point
> to the right table entry, we can get the table correctly.
> What do you mean "the ordering of creating fields"?
It is an implementation detail only that the first bit of that table is
the DSMAS entry. I think we shouldn't rely on that.
> >
> > I'd rather you just stored the information flags is built from in CXLDCRegion
> > and then built the field that is wonderfully called 'Note' in the DC region
I got distracted by the spec oddity :)
> This sentence is kind of broken for me, not totally clear what you are
> suggesting :-(. Can you explain more?
> Are you suggesting not directly take dsmas->flags as dsmas_flags, but
> use bit op to generate the value used in Table 7-66 in cxl spec 3.2?
No. Just store the various bools etc that become dsmas->flags in the
CXLDCRegion structure directly rather than reading back from dsmas->flags.
Probably as explicit bools etc not a single value.
Then pass those in to ct3_build_cdat_entries_for_mr() . Mostly they overlap
with current true / false parameters that are hard coded.
> > configuration in 6.2 spec. I've sent a mail to see if we can clean that
> 6.2 spec???
> > 'what is the field called' question for future spec releases.
> >
> > Whilst the flag definitions cross refer the CDAT spec, the actual locations
> > of those flags matches, but doesn't cross refer so maybe in the future
> > we will have other flags in here and locations might not match.
> For the flags stored in dsmas table, do we expect there can be more than those
> defined in Table 7-66 in spec 3.2?
Not for now. Though I'm sure something will come along at some point.
The comment is about there being particular reason the flag locations should match
between CDAT and what we report via the commands being added here. The definitions
of individual bits cross refer between specs, the register as a whole does not.
Jonathan
>
> Fan
>
> >
> > >
> > > cur_ent += CT3_CDAT_NUM_ENTRIES;
> > > region_base += ct3d->dc.regions[i].len;
> > > diff --git a/include/hw/cxl/cxl_device.h b/include/hw/cxl/cxl_device.h
> > > index bebed04085..81b826f570 100644
> > > --- a/include/hw/cxl/cxl_device.h
> > > +++ b/include/hw/cxl/cxl_device.h
> > > @@ -609,6 +609,7 @@ typedef struct CXLDCRegion {
> > > uint8_t flags;
> > > unsigned long *blk_bitmap;
> > > uint64_t supported_blk_size_bitmask;
> > > + uint8_t dsmas_flags;
> > > } CXLDCRegion;
> > >
> > > typedef struct CXLSetFeatureInfo {
> >
next prev parent reply other threads:[~2025-05-02 9:02 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-17 16:31 [PATCH 0/9] CXL: FMAPI DCD Management Commands 0x5600-0x5605 anisa.su887
2025-03-17 16:31 ` [PATCH 1/9] cxl/type3: Add supported block sizes bitmask to CXLDCRegion struct anisa.su887
2025-04-24 10:11 ` Jonathan Cameron
2025-04-29 17:56 ` Anisa Su
2025-03-17 16:31 ` [PATCH 2/9] cxl-mailbox-utils: 0x5600 - FMAPI Get DCD Info anisa.su887
2025-03-18 15:56 ` Jonathan Cameron
2025-03-31 19:38 ` Anisa Su
2025-04-24 10:21 ` Jonathan Cameron
2025-04-16 21:25 ` Anisa Su
2025-04-24 10:30 ` Jonathan Cameron
2025-03-17 16:31 ` [PATCH 3/9] cxl/type3: Add dsmas_flags to CXLDCRegion struct anisa.su887
2025-04-24 10:42 ` Jonathan Cameron
2025-05-01 20:21 ` Fan Ni
2025-05-02 9:01 ` Jonathan Cameron [this message]
2025-05-02 15:57 ` Fan Ni
2025-05-06 16:53 ` Jonathan Cameron
2025-03-17 16:31 ` [PATCH 4/9] cxl-mailbox-utils: 0x5601 - FMAPI Get Host Region Config anisa.su887
2025-04-24 10:53 ` Jonathan Cameron
2025-03-17 16:31 ` [PATCH 5/9] cxl_events.h: move definition for dynamic_capacity_uuid and enum for DC event types anisa.su887
2025-04-24 10:55 ` Jonathan Cameron
2025-03-17 16:31 ` [PATCH 6/9] cxl-mailbox-utils: 0x5602 - FMAPI Set DC Region Config anisa.su887
2025-04-16 21:33 ` Anisa Su
2025-04-24 11:05 ` Jonathan Cameron
2025-03-17 16:31 ` [PATCH 7/9] cxl-mailbox-utils: 0x5603 - FMAPI Get DC Region Extent Lists anisa.su887
2025-04-24 11:10 ` Jonathan Cameron
2025-03-17 16:31 ` [PATCH 8/9] cxl-mailbox-utils: 0x5604 - FMAPI Initiate DC Add anisa.su887
2025-04-24 11:19 ` Jonathan Cameron
2025-04-28 20:41 ` Fan Ni
2025-05-05 16:40 ` Anisa Su
2025-05-06 16:55 ` Jonathan Cameron
2025-03-17 16:31 ` [PATCH 9/9] cxl-mailbox-utils: 0x5605 - FMAPI Initiate DC Release anisa.su887
2025-04-24 11:23 ` Jonathan Cameron
2025-04-28 20:44 ` Fan Ni
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=20250502100155.00003bfa@huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=anisa.su887@gmail.com \
--cc=anisa.su@samsung.com \
--cc=dave@stgolabs.net \
--cc=linux-cxl@vger.kernel.org \
--cc=nifan.cxl@gmail.com \
--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