qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Cameron via <qemu-devel@nongnu.org>
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: Tue, 6 May 2025 17:53:01 +0100	[thread overview]
Message-ID: <20250506175301.00005f1b@huawei.com> (raw)
In-Reply-To: <aBTrcAa9yt8lGHJO@debian>

On Fri, 2 May 2025 08:57:36 -0700
Fan Ni <nifan.cxl@gmail.com> wrote:

> On Fri, May 02, 2025 at 10:01:55AM +0100, Jonathan Cameron wrote:
> > 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.  
> 
> OK. Since some flags are not support yet, can we hard coded them for now?

Sure. Add some breadcrumbs / comments for later though if that makes sense.

> 
> Fan
> > 
> >   
> > > > 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 {    
> > > >     
> >   



  reply	other threads:[~2025-05-06 17:11 UTC|newest]

Thread overview: 34+ 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 via
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 via
2025-03-31 19:38     ` Anisa Su
2025-04-14 16:52       ` Anisa Su
2025-04-24 10:21       ` Jonathan Cameron via
2025-04-16 21:25     ` Anisa Su
2025-04-24 10:30   ` Jonathan Cameron via
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 via
2025-05-01 20:21     ` Fan Ni
2025-05-02  9:01       ` Jonathan Cameron via
2025-05-02 15:57         ` Fan Ni
2025-05-06 16:53           ` Jonathan Cameron via [this message]
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 via
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 via
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 via
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 via
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 via
2025-04-28 20:41     ` Fan Ni
2025-05-05 16:40     ` Anisa Su
2025-05-06 16:55       ` Jonathan Cameron via
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 via
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=20250506175301.00005f1b@huawei.com \
    --to=qemu-devel@nongnu.org \
    --cc=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 \
    /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).