| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <c4a8ecf535df419eae132fda68407760@huawei.com>
Date: Fri, 23 Feb 2024 12:23:03 +0000
From: Shiju Jose <shiju.jose@...wei.com>
To: Jonathan Cameron <jonathan.cameron@...wei.com>
CC: "linux-cxl@...r.kernel.org" <linux-cxl@...r.kernel.org>,
"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
"linux-mm@...ck.org" <linux-mm@...ck.org>, "dan.j.williams@...el.com"
<dan.j.williams@...el.com>, "dave@...olabs.net" <dave@...olabs.net>,
"dave.jiang@...el.com" <dave.jiang@...el.com>, "alison.schofield@...el.com"
<alison.schofield@...el.com>, "vishal.l.verma@...el.com"
<vishal.l.verma@...el.com>, "ira.weiny@...el.com" <ira.weiny@...el.com>,
"linux-edac@...r.kernel.org" <linux-edac@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"david@...hat.com" <david@...hat.com>, "Vilas.Sridharan@....com"
<Vilas.Sridharan@....com>, "leo.duran@....com" <leo.duran@....com>,
"Yazen.Ghannam@....com" <Yazen.Ghannam@....com>, "rientjes@...gle.com"
<rientjes@...gle.com>, "jiaqiyan@...gle.com" <jiaqiyan@...gle.com>,
"tony.luck@...el.com" <tony.luck@...el.com>, "Jon.Grimm@....com"
<Jon.Grimm@....com>, "dave.hansen@...ux.intel.com"
<dave.hansen@...ux.intel.com>, "rafael@...nel.org" <rafael@...nel.org>,
"lenb@...nel.org" <lenb@...nel.org>, "naoya.horiguchi@....com"
<naoya.horiguchi@....com>, "james.morse@....com" <james.morse@....com>,
"jthoughton@...gle.com" <jthoughton@...gle.com>, "somasundaram.a@....com"
<somasundaram.a@....com>, "erdemaktas@...gle.com" <erdemaktas@...gle.com>,
"pgonda@...gle.com" <pgonda@...gle.com>, "duenwen@...gle.com"
<duenwen@...gle.com>, "mike.malvestuto@...el.com"
<mike.malvestuto@...el.com>, "gthelen@...gle.com" <gthelen@...gle.com>,
"wschwartz@...erecomputing.com" <wschwartz@...erecomputing.com>,
"dferguson@...erecomputing.com" <dferguson@...erecomputing.com>, tanxiaofei
<tanxiaofei@...wei.com>, "Zengtao (B)" <prime.zeng@...ilicon.com>,
"kangkang.shen@...urewei.com" <kangkang.shen@...urewei.com>, wanghuiqiang
<wanghuiqiang@...wei.com>, Linuxarm <linuxarm@...wei.com>
Subject: RE: [RFC PATCH v6 02/12] cxl/mbox: Add GET_FEATURE mailbox command
Hi Jonathan,
Thanks for the comments.
I will post the updated version incorporated with your suggestions in the series.
>-----Original Message-----
>From: Jonathan Cameron <jonathan.cameron@...wei.com>
>Sent: 20 February 2024 11:14
>To: Shiju Jose <shiju.jose@...wei.com>
>Cc: linux-cxl@...r.kernel.org; linux-acpi@...r.kernel.org; linux-
>mm@...ck.org; dan.j.williams@...el.com; dave@...olabs.net;
>dave.jiang@...el.com; alison.schofield@...el.com; vishal.l.verma@...el.com;
>ira.weiny@...el.com; linux-edac@...r.kernel.org; linux-
>kernel@...r.kernel.org; david@...hat.com; Vilas.Sridharan@....com;
>leo.duran@....com; Yazen.Ghannam@....com; rientjes@...gle.com;
>jiaqiyan@...gle.com; tony.luck@...el.com; Jon.Grimm@....com;
>dave.hansen@...ux.intel.com; rafael@...nel.org; lenb@...nel.org;
>naoya.horiguchi@....com; james.morse@....com; jthoughton@...gle.com;
>somasundaram.a@....com; erdemaktas@...gle.com; pgonda@...gle.com;
>duenwen@...gle.com; mike.malvestuto@...el.com; gthelen@...gle.com;
>wschwartz@...erecomputing.com; dferguson@...erecomputing.com;
>tanxiaofei <tanxiaofei@...wei.com>; Zengtao (B) <prime.zeng@...ilicon.com>;
>kangkang.shen@...urewei.com; wanghuiqiang <wanghuiqiang@...wei.com>;
>Linuxarm <linuxarm@...wei.com>
>Subject: Re: [RFC PATCH v6 02/12] cxl/mbox: Add GET_FEATURE mailbox
>command
>
>On Thu, 15 Feb 2024 19:14:44 +0800
><shiju.jose@...wei.com> wrote:
>
>> From: Shiju Jose <shiju.jose@...wei.com>
>>
>> Add support for GET_FEATURE mailbox command.
>>
>> CXL spec 3.1 section 8.2.9.6 describes optional device specific features.
>> The settings of a feature can be retrieved using Get Feature command.
>Hi Shiju
>
>I think this needs to be more complex so that this utility function gets the whole
>feature, not just a section of it (subject to big enough buffer being available etc).
>We don't want the higher level code to have to deal with the complexity of small
>mailboxes.
Sure.
>
>A few other things inline.
>
>Jonathan
>
>>
>> Signed-off-by: Shiju Jose <shiju.jose@...wei.com>
>> ---
>> drivers/cxl/core/mbox.c | 22 ++++++++++++++++++++++
>> drivers/cxl/cxlmem.h | 23 +++++++++++++++++++++++
>> 2 files changed, 45 insertions(+)
>>
>> diff --git a/drivers/cxl/core/mbox.c b/drivers/cxl/core/mbox.c index
>> 191f51f3df0e..f43189b6859a 100644
>> --- a/drivers/cxl/core/mbox.c
>> +++ b/drivers/cxl/core/mbox.c
>> @@ -1313,6 +1313,28 @@ int cxl_get_supported_features(struct
>> cxl_memdev_state *mds, }
>> EXPORT_SYMBOL_NS_GPL(cxl_get_supported_features, CXL);
>>
>> +int cxl_get_feature(struct cxl_memdev_state *mds,
>> + struct cxl_mbox_get_feat_in *pi, void *feat_out)
>
>Comments below on this signature. Key is I'd expect this function to deal with
>potential need for multiple requests (small mailbox size compared to the size of
>the output data being read).
>
>To test that we'd probably have to tweak the qemu code to use a smaller
>mailbox.
>Or fake that in here so that we do multiple smaller reads.
Sure.
>
>> +{
>> + struct cxl_mbox_cmd mbox_cmd;
>> + int rc;
>> +
>> + mbox_cmd = (struct cxl_mbox_cmd) {
>> + .opcode = CXL_MBOX_OP_GET_FEATURE,
>> + .size_in = sizeof(*pi),
>> + .payload_in = pi,
>> + .size_out = le16_to_cpu(pi->count),
>> + .payload_out = feat_out,
>> + .min_out = le16_to_cpu(pi->count),
>
>Are there feature with variable responses sizes? I think there will be.
>size_out should be the size of the buffer, but min_out should be the size of the
>particular feature data header - note these will change as we iterate over
>multiple messages.
Sure.
>
>
>> + };
>> + rc = cxl_internal_send_cmd(mds, &mbox_cmd);
>> + if (rc < 0)
>> + return rc;
>> +
>> + return 0;
>I think this should return the size to the caller, rather than 0 on success.
I will change.
>
>> +}
>> +EXPORT_SYMBOL_NS_GPL(cxl_get_feature, CXL);
>> +
>> int cxl_mem_get_poison(struct cxl_memdev *cxlmd, u64 offset, u64 len,
>> struct cxl_region *cxlr)
>> {
>> diff --git a/drivers/cxl/cxlmem.h b/drivers/cxl/cxlmem.h index
>> 23e4d98b9bae..eaecc3234cfd 100644
>> --- a/drivers/cxl/cxlmem.h
>> +++ b/drivers/cxl/cxlmem.h
>> @@ -530,6 +530,7 @@ enum cxl_opcode {
>> CXL_MBOX_OP_GET_SUPPORTED_LOGS = 0x0400,
>> CXL_MBOX_OP_GET_LOG = 0x0401,
>> CXL_MBOX_OP_GET_SUPPORTED_FEATURES = 0x0500,
>> + CXL_MBOX_OP_GET_FEATURE = 0x0501,
>> CXL_MBOX_OP_IDENTIFY = 0x4000,
>> CXL_MBOX_OP_GET_PARTITION_INFO = 0x4100,
>> CXL_MBOX_OP_SET_PARTITION_INFO = 0x4101,
>> @@ -757,6 +758,26 @@ struct cxl_mbox_get_supp_feats_out {
>> struct cxl_mbox_supp_feat_entry feat_entries[]; } __packed;
>>
>> +/* Get Feature CXL 3.1 Spec 8.2.9.6.2 */
>> +/*
>> + * Get Feature input payload
>> + * CXL rev 3.1 section 8.2.9.6.2 Table 8-99 */
>> +/* Get Feature : Payload in selection */
>
>Naming of enum is good enough that I don't think we need this particular
>comment.
I will change.
>
>> +enum cxl_get_feat_selection {
>> + CXL_GET_FEAT_SEL_CURRENT_VALUE,
>> + CXL_GET_FEAT_SEL_DEFAULT_VALUE,
>> + CXL_GET_FEAT_SEL_SAVED_VALUE,
>> + CXL_GET_FEAT_SEL_MAX
>> +};
>> +
>> +struct cxl_mbox_get_feat_in {
>> + uuid_t uuid;
>> + __le16 offset;
>> + __le16 count;
>> + u8 selection;
>> +} __packed;
>> +
>> /* Get Poison List CXL 3.0 Spec 8.2.9.8.4.1 */ struct
>> cxl_mbox_poison_in {
>> __le64 offset;
>> @@ -891,6 +912,8 @@ int cxl_set_timestamp(struct cxl_memdev_state
>> *mds); int cxl_get_supported_features(struct cxl_memdev_state *mds,
>> struct cxl_mbox_get_supp_feats_in *pi,
>> void *feats_out);
>> +int cxl_get_feature(struct cxl_memdev_state *mds,
>> + struct cxl_mbox_get_feat_in *pi, void *feat_out);
>
>For this I'd expect us to wrap up the need for multi messages inside this.
>So this would then just take the feature index, a size for the output buffer overall
>size, plus min acceptable response size and a selection enum value.
Sure.
>
>int cxl_get_feature(struct cxl_memdev_state *mds,
> uuid_t feat,
> void *feat_out, size_t feat_out_min_size,
> size_t feat_out_size);
>
>> int cxl_poison_state_init(struct cxl_memdev_state *mds); int
>> cxl_mem_get_poison(struct cxl_memdev *cxlmd, u64 offset, u64 len,
>> struct cxl_region *cxlr);
Thanks,
Shiju
Powered by blists - more mailing lists