| 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: <20240220111423.00003eae@Huawei.com>
Date: Tue, 20 Feb 2024 11:14:23 +0000
From: Jonathan Cameron <Jonathan.Cameron@...wei.com>
To: <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@...wei.com>, <prime.zeng@...ilicon.com>,
<kangkang.shen@...urewei.com>, <wanghuiqiang@...wei.com>,
<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.
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.
> +{
> + 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.
> + };
> + 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.
> +}
> +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.
> +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.
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);
Powered by blists - more mailing lists