From: Ira Weiny <ira.weiny@intel.com>
To: Shiyang Ruan <ruansy.fnst@fujitsu.com>,
Ira Weiny <ira.weiny@intel.com>,
Alison Schofield <alison.schofield@intel.com>
Cc: <qemu-devel@nongnu.org>, <linux-cxl@vger.kernel.org>,
<Jonathan.Cameron@huawei.com>, <dan.j.williams@intel.com>,
<dave@stgolabs.net>, <stable@vger.kernel.org>
Subject: Re: [PATCH v3 1/2] cxl/core: correct length of DPA field masks
Date: Thu, 25 Apr 2024 09:04:43 -0700 [thread overview]
Message-ID: <662a7f1bae7c0_f81752941c@iweiny-mobl.notmuch> (raw)
In-Reply-To: <5563b68c-48ab-48e3-bbc9-b93236ea0543@fujitsu.com>
Shiyang Ruan wrote:
>
>
> 在 2024/4/24 5:04, Ira Weiny 写道:
> > Alison Schofield wrote:
> >> On Wed, Apr 17, 2024 at 03:50:52PM +0800, Shiyang Ruan wrote:
> >
> > [snip]
> >
> >>> diff --git a/drivers/cxl/core/trace.h b/drivers/cxl/core/trace.h
> >>> index e5f13260fc52..cdfce932d5b1 100644
> >>> --- a/drivers/cxl/core/trace.h
> >>> +++ b/drivers/cxl/core/trace.h
> >>> @@ -253,7 +253,7 @@ TRACE_EVENT(cxl_generic_event,
> >>> * DRAM Event Record
> >>> * CXL rev 3.0 section 8.2.9.2.1.2; Table 8-44
> >>> */
> >>> -#define CXL_DPA_FLAGS_MASK 0x3F
> >>> +#define CXL_DPA_FLAGS_MASK 0x3FULL
> >>> #define CXL_DPA_MASK (~CXL_DPA_FLAGS_MASK)
> >>>
> >>> #define CXL_DPA_VOLATILE BIT(0)
> >>
> >> This works but I'm thinking this is the time to convene on one
> >> CXL_EVENT_DPA_MASK for both all CXL events, rather than having
> >> cxl_poison event be different.
> >>
> >> I prefer how poison defines it:
> >>
> >> cxlmem.h:#define CXL_POISON_START_MASK GENMASK_ULL(63, 6)
> >>
> >> Can we rename that CXL_EVENT_DPA_MASK and use for all events?
>
> cxlmem.h:CXL_POISON_START_MASK is defined for MBOX commands (poison
> record, the lower 3 bits indicate "Error Source"), but CXL_DPA_MASK here
> is for events. They have different meaning though their values are
> same. So, I don't think we should consolidate them.
By definition the DPA in all these payloads can't use the lower 6 bits.
We are defining a mask to get the DPA. This has nothing to do with what
may be stored in the other 6 bits.
Defining a common DPA mask is correct per both sections of the spec.
>
> >
> > Ah! Great catch. I dont' know why I only masked off the 2 used bits.
>
> Per spec, the lowest 2 bits of CXL event's DPA are defined for "Volatile
> or not" and "not repairable". So there is no mistake here.
I appreciate your not calling out my code as a bug. :-D
However, bits [5:2] are also Reserved. So it is incorrect to mask off
only the lower 2 bits. Even though the reserved bits must be 0 per the
spec, it is still better to properly mask all reserved bits because they
are by definition not part of the DPA.
Could you create a common macro for the next version of the patch?
Thanks,
Ira
>
> > That was short sighted of me.
> >
> > Yes we should consolidate these.
> > Ira
>
> --
> Thanks,
> Ruan.
>
next prev parent reply other threads:[~2024-04-25 16:06 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-17 7:50 [PATCH v3 0/2] cxl: add poison creation event handler Shiyang Ruan via
2024-04-17 7:50 ` [PATCH v3 1/2] cxl/core: correct length of DPA field masks Shiyang Ruan via
2024-04-23 17:35 ` Ira Weiny
2024-04-23 17:35 ` Dan Williams
2024-04-23 17:42 ` Alison Schofield
2024-04-23 21:04 ` Ira Weiny
2024-04-25 10:05 ` Shiyang Ruan via
2024-04-25 16:04 ` Ira Weiny [this message]
2024-04-30 21:00 ` Alison Schofield
2024-05-03 11:37 ` Shiyang Ruan via
2024-04-17 7:50 ` [PATCH v3 2/2] cxl/core: add poison creation event handler Shiyang Ruan via
2024-04-17 17:30 ` Dave Jiang
2024-04-18 9:01 ` Shiyang Ruan via
2024-04-21 12:14 ` kernel test robot
2024-04-23 17:57 ` Ira Weiny
2024-05-03 10:42 ` Shiyang Ruan via
2024-05-08 16:15 ` Jonathan Cameron via
2024-04-23 18:40 ` Dan Williams
2024-05-03 11:32 ` Shiyang Ruan via
2024-05-21 5:35 ` Shiyang Ruan via
2024-05-22 6:45 ` Dan Williams
2024-05-24 15:15 ` Shiyang Ruan via
2024-05-28 10:13 ` Shiyang Ruan via
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=662a7f1bae7c0_f81752941c@iweiny-mobl.notmuch \
--to=ira.weiny@intel.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=alison.schofield@intel.com \
--cc=dan.j.williams@intel.com \
--cc=dave@stgolabs.net \
--cc=linux-cxl@vger.kernel.org \
--cc=qemu-devel@nongnu.org \
--cc=ruansy.fnst@fujitsu.com \
--cc=stable@vger.kernel.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).