- Linaro-open-discussions - op-lists.linaro.org

[PATCH 06/10] lib/asn1_encoder: Add a function to encode many byte integer values.

by Jonathan Cameron

From: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> An example is the encoding of ECC signatures used by the ECDSA signature verification code. A user is the new SPDM support where raw signatures are returned by the responder. These can then be encoded so that we can pass them to signature_verify() Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- include/linux/asn1_encoder.h | 3 ++ lib/asn1_encoder.c | 54 ++++++++++++++++++++++++++++++++++++ 2 files changed, 57 insertions(+) diff --git a/include/linux/asn1_encoder.h b/include/linux/asn1_encoder.h index 08cd0c2ad34f..30c3ebacd46c 100644 --- a/include/linux/asn1_encoder.h +++ b/include/linux/asn1_encoder.h @@ -19,6 +19,9 @@ unsigned char * asn1_encode_tag(unsigned char *data, const unsigned char *end_data, u32 tag, const unsigned char *string, int len); unsigned char * +asn1_encode_integer_large_positive(unsigned char *data, const unsigned char *end_data, + u32 tag, const unsigned char *integer, int len); +unsigned char * asn1_encode_octet_string(unsigned char *data, const unsigned char *end_data, const unsigned char *string, u32 len); diff --git a/lib/asn1_encoder.c b/lib/asn1_encoder.c index 27bbe891714f..47ff50f478cd 100644 --- a/lib/asn1_encoder.c +++ b/lib/asn1_encoder.c @@ -317,6 +317,60 @@ asn1_encode_tag(unsigned char *data, const unsigned char *end_data, } EXPORT_SYMBOL_GPL(asn1_encode_tag); +unsigned char * +asn1_encode_integer_large_positive(unsigned char *data, const unsigned char *end_data, + u32 tag, const unsigned char *integer, int len) +{ + int data_len = end_data - data; + unsigned char *d = &data[2]; + bool found = false; + int i; + + if (WARN(tag > 30, "ASN.1 tag can't be > 30")) + return ERR_PTR(-EINVAL); + + if (!integer && WARN(len > 127, + "BUG: recode tag is too big (>127)")) + return ERR_PTR(-EINVAL); + + if (IS_ERR(data)) + return data; + + if (data_len < 3) + return ERR_PTR(-EINVAL); + + + data[0] = _tagn(UNIV, PRIM, tag); + /* Leave space for length */ + data_len -= 2; + + for (i = 0; i < len; i++) { + int byte = integer[i]; + + if (!found && byte == 0) + continue; + + /* + * as per encode_integer + */ + if (!found && (byte & 0x80)) { + *d++ = 0; + data_len--; + } + found = true; + if (data_len == 0) + return ERR_PTR(-EINVAL); + + *d++ = byte; + data_len--; + } + + data[1] = d - data - 2; + + return d; +} +EXPORT_SYMBOL_GPL(asn1_encode_integer_large_positive); + /** * asn1_encode_octet_string() - encode an ASN.1 OCTET STRING * @data: pointer to encode at -- 2.32.0

4 years, 3 months

1
0
0 0

[PATCH 05/10] cxl/cdat: Parse out DSMAS data from CDAT table

by Jonathan Cameron

From: Ira Weiny <ira.weiny(a)intel.com> Parse and cache the DSMAS data from the CDAT table. Store this data in Unmarshaled data structures for use later. Signed-off-by: Ira Weiny <ira.weiny(a)intel.com> --- drivers/cxl/core/memdev.c | 111 ++++++++++++++++++++++++++++++++++++++ drivers/cxl/cxlmem.h | 23 ++++++++ 2 files changed, 134 insertions(+) diff --git a/drivers/cxl/core/memdev.c b/drivers/cxl/core/memdev.c index a0ef40395ee1..95d710e80df0 100644 --- a/drivers/cxl/core/memdev.c +++ b/drivers/cxl/core/memdev.c @@ -6,6 +6,7 @@ #include <linux/idr.h> #include <linux/pci.h> #include <cxlmem.h> +#include "cdat.h" #include "core.h" static DECLARE_RWSEM(cxl_memdev_rwsem); @@ -312,6 +313,112 @@ static const struct file_operations cxl_memdev_fops = { .llseek = noop_llseek, }; +static bool cdat_hdr_valid(struct cxl_memdev *cxlmd) +{ + u32 *data = cxlmd->cdat_table; + u8 *data8 = (u8 *)data; + u32 length, seq; + u8 rev, cs; + u8 check; + int i; + + length = FIELD_GET(CDAT_HEADER_DW0_LENGTH, data[0]); + if (length < CDAT_HEADER_LENGTH_BYTES) + return false; + + rev = FIELD_GET(CDAT_HEADER_DW1_REVISION, data[1]); + cs = FIELD_GET(CDAT_HEADER_DW1_CHECKSUM, data[1]); + seq = FIELD_GET(CDAT_HEADER_DW3_SEQUENCE, data[3]); + + /* Store the sequence for now. */ + cxlmd->cdat_seq = seq; + + for (check = 0, i = 0; i < length; i++) + check += data8[i]; + + return check == 0; +} + +static int parse_dsmas(struct cxl_memdev *cxlmd) +{ + struct cxl_dsmas *dsmas_ary = NULL; + u32 *data = cxlmd->cdat_table; + int bytes_left = cxlmd->cdat_length; + int nr_dsmas = 0; + size_t dsmas_byte_size; + int rc = 0; + + if (!data || !cdat_hdr_valid(cxlmd)) + return -ENXIO; + + /* Skip header */ + data += CDAT_HEADER_LENGTH_DW; + bytes_left -= CDAT_HEADER_LENGTH_BYTES; + + while (bytes_left > 0) { + u32 *cur_rec = data; + u8 type = FIELD_GET(CDAT_STRUCTURE_DW0_TYPE, cur_rec[0]); + u16 length = FIELD_GET(CDAT_STRUCTURE_DW0_LENGTH, cur_rec[0]); + + if (type == CDAT_STRUCTURE_DW0_TYPE_DSMAS) { + struct cxl_dsmas *new_ary; + u8 flags; + + new_ary = krealloc(dsmas_ary, + sizeof(*dsmas_ary) * (nr_dsmas+1), + GFP_KERNEL); + if (!new_ary) { + dev_err(&cxlmd->dev, + "Failed to allocate memory for DSMAS data\n"); + rc = -ENOMEM; + goto free_dsmas; + } + dsmas_ary = new_ary; + + flags = FIELD_GET(CDAT_DSMAS_DW1_FLAGS, cur_rec[1]); + + dsmas_ary[nr_dsmas].dpa_base = CDAT_DSMAS_DPA_OFFSET(cur_rec); + dsmas_ary[nr_dsmas].dpa_length = CDAT_DSMAS_DPA_LEN(cur_rec); + dsmas_ary[nr_dsmas].non_volatile = CDAT_DSMAS_NON_VOLATILE(flags); + + dev_dbg(&cxlmd->dev, "DSMAS %d: %llx:%llx %s\n", + nr_dsmas, + dsmas_ary[nr_dsmas].dpa_base, + dsmas_ary[nr_dsmas].dpa_base + + dsmas_ary[nr_dsmas].dpa_length, + (dsmas_ary[nr_dsmas].non_volatile ? + "Persistent" : "Volatile") + ); + + nr_dsmas++; + } + + data += (length/sizeof(u32)); + bytes_left -= length; + } + + if (nr_dsmas == 0) { + rc = -ENXIO; + goto free_dsmas; + } + + dev_dbg(&cxlmd->dev, "Found %d DSMAS entries\n", nr_dsmas); + + dsmas_byte_size = sizeof(*dsmas_ary) * nr_dsmas; + cxlmd->dsmas_ary = devm_kzalloc(&cxlmd->dev, dsmas_byte_size, GFP_KERNEL); + if (!cxlmd->dsmas_ary) { + rc = -ENOMEM; + goto free_dsmas; + } + + memcpy(cxlmd->dsmas_ary, dsmas_ary, dsmas_byte_size); + cxlmd->nr_dsmas = nr_dsmas; + +free_dsmas: + kfree(dsmas_ary); + return rc; +} + struct cxl_memdev *devm_cxl_add_memdev(struct cxl_dev_state *cxlds) { struct cxl_memdev *cxlmd; @@ -338,6 +445,10 @@ struct cxl_memdev *devm_cxl_add_memdev(struct cxl_dev_state *cxlds) cxl_mem_cdat_read_table(cxlds, cxlmd->cdat_table, cxlmd->cdat_length); } + rc = parse_dsmas(cxlmd); + if (rc) + dev_err(dev, "No DSMAS data found: %d\n", rc); + /* * Activate ioctl operations, no cxl_memdev_rwsem manipulation * needed as this is ordered with cdev_add() publishing the device. diff --git a/drivers/cxl/cxlmem.h b/drivers/cxl/cxlmem.h index f6c62cd537bb..d68da2610265 100644 --- a/drivers/cxl/cxlmem.h +++ b/drivers/cxl/cxlmem.h @@ -29,6 +29,23 @@ (FIELD_GET(CXLMDEV_RESET_NEEDED_MASK, status) != \ CXLMDEV_RESET_NEEDED_NOT) +/** + * struct cxl_dsmas - host unmarshaled version of DSMAS data + * + * As defined in the Coherent Device Attribute Table (CDAT) specification this + * represents a single DSMAS entry in that table. + * + * @dpa_base: The lowest DPA address associated with this DSMAD + * @dpa_length: Length in bytes of this DSMAD + * @non_volatile: If set, the memory region represents Non-Volatile memory + */ +struct cxl_dsmas { + u64 dpa_base; + u64 dpa_length; + /* Flags */ + int non_volatile:1; +}; + /** * struct cxl_memdev - CXL bus object representing a Type-3 Memory Device * @dev: driver core device object @@ -36,6 +53,9 @@ * @cxlds: The device state backing this device * @cdat_table: cache of CDAT table * @cdat_length: length of cached CDAT table + * @cdat_seq: Last read Sequence number of the CDAT table + * @dsmas_ary: Array of DSMAS entries as parsed from the CDAT table + * @nr_dsmas: Number of entries in dsmas_ary * @id: id number of this memdev instance. */ struct cxl_memdev { @@ -44,6 +64,9 @@ struct cxl_memdev { struct cxl_dev_state *cxlds; void *cdat_table; size_t cdat_length; + u32 cdat_seq; + struct cxl_dsmas *dsmas_ary; + int nr_dsmas; int id; }; -- 2.32.0

4 years, 3 months

1
0
0 0

Linaro OP-TEE Contributions (LOC) monthly meeting November 2021

by Ruchika Gupta

Hi, OP-TEE Contributions (LOC) monthly meeting is planned for Thursday Nov 25 @17.00 (UTC+2). Following topic is on the agenda: - Walkthrough of proposal on sharing of hardware resources between multiple secure entities - Jens Wiklander. If you have any other topics you'd like to discuss, please let us know and we can schedule them. Meeting details: --------------- Date/time: Nov 25(a)16.00 (UTC) https://everytimezone.com/s/a43c71b2 Connection details: https://www.trustedfirmware.org/meetings/ Meeting notes: http://bit.ly/loc-notes Regards, Ruchika on behalf of the Linaro OP-TEE team

4 years, 3 months

1
2
0 0

DOE/SPDM branch

by Lorenzo Pieralisi

Hi Jonathan, I was about to test your doe-spdm-v1 branch but it does not compile, I was wondering if you forgot to push some files. Have you managed to rebase it on top of the latest DOE patches ? Please let me know, thank you very much. Lorenzo

4 years, 4 months

2
1
0 0

Agenda for LOD Meeting Oct 25th

by Jammy Zhou

Hi all, The monthly meeting will happen next Monday (Oct 25th), please let me know if you have any topics to cover. Thanks, Jammy

4 years, 4 months

3
10
0 0

[PATCH 0/2] Wake task within the same cluster of waker if possible

by Yicong Yang

This is the follow-up work to support cluster scheduler. Previously we have added cluster level in the scheduler[1] to make tasks spread between clusters to bring more memory bandwidth and decrease cache contention. But it may hurt some workloads which are sensitive to the communication latency as they will be placed across clusters. We modified the select_idle_cpu() on the wake affine path in this series, expecting the wake affined task to be woken more likely on the same cluster with the waker. The latency will be decreased as the waker and wakee in the same cluster may benefit from the hot L3 cache tag. [1] https://lore.kernel.org/lkml/20210924085104.44806-1-21cnbao@gmail.com/ Hi Tim and Barry, This the modified patch of packing path of cluster scheduler and tests have been done on Kunpeng 920 2-socket 4-NUMA 128core platform, with 8 clusters on each NUMA. Patches based on 5.15-rc1. Barry Song (2): sched: Add per_cpu cluster domain info sched/fair: Scan from the first cpu of cluster if presents in select_idle_cpu include/linux/sched/sd_flags.h | 9 +++++++++ include/linux/sched/topology.h | 2 +- kernel/sched/fair.c | 10 +++++++--- kernel/sched/sched.h | 1 + kernel/sched/topology.c | 5 +++++ 5 files changed, 23 insertions(+), 4 deletions(-) -- 2.33.0

4 years, 4 months

3
21
0 0

SCMI protocol for interconnect scaling

by Georgi Djakov

Hi all, I am recently getting questions about hooking the interconnect framework to SCMI, so i am starting a discussion on this problem and see who might be interested in it. The SCMI spec contains various protocols like the "Performance domain management protocol". But none of the protocols mentioned in the current spec (3.0) seem to fit well into the concept we are using to scale interconnect bandwidth in Linux. I see that people are working in this area and there is already some support for clocks, resets etc. I am wondering what would be the right approach to support also interconnect bus scaling via SCMI. The interconnect framework is part of the linux kernel and it's goal is to manage the hardware and tune it to the most optimal power- performance profile according to the aggregated bandwidth demand between the various endpoints in the system (SoC). This is based on the requests coming from consumer drivers. As interconnects scaling does not map directly to any of the currently available protocols in the SCMI spec, i am curious whether there is work in progress on some other protocol that could support managing resources based on path endpoints (instead of a single ID). The interconnect framework doesn't populate every possible path, but it exposes endpoints to client drivers and the path lookup is dynamic, based on what the clients request. Maybe the SCMI host could also expose all possible endpoints and let the guest request a path from the host, based on those endpoints. There are already suggestions to create vendor-specific SCMI protocols for that, but i fear that we may end up with more than one protocol for the same thing, so that's why it might be best to discuss it in public and have a common solution that works for everyone. Thanks, Georgi

4 years, 4 months

3
3
0 0

Linaro OP-TEE Contributions (LOC) monthly meeting October 2021

by Ruchika Gupta

Hi, OP-TEE Contributions (LOC) monthly meeting is planned for Thursday Oct 28 @17.00 (UTC+2). Following topics are on the agenda: - Generic Clock Framework and Peripheral security- Clément Léger - Discussion on device driver initialization/probing - Etienne Carriere If you have any other topics you'd like to discuss, please let us know and we can schedule them. Meeting details: --------------- Date/time: October 28(a)17.00 (UTC+2) https://everytimezone.com/s/3f83a9ab Connection details: https://www.trustedfirmware.org/meetings/ Meeting notes: http://bit.ly/loc-notes Regards, Ruchika on behalf of the Linaro OP-TEE team

4 years, 5 months

1
0
0 0

LOD Meeting Agenda for September 27th

by Jammy Zhou

Hi All, I think most of you may be busy with the Linux Plumbers Conference this week. Please let me know if these is something to discuss or follow next Monday. Regards, Jammy

4 years, 5 months

4
6
0 0

Linaro OP-TEE Contributions (LOC) monthly meeting Sep 2021

by Ruchika Gupta

Hi, Linaro OP-TEE Contributions (LOC) monthly meeting is planned to take place on Thursday Sep 23(a)17.00 (UTC+2). Following topics are on the agenda: - OP-TEE Linaro Contribution - Current status and Roadmap - Ruchika - FF-A based mediator in XEN - Jens If you have any other topics you'd like to discuss, please let us know. Meeting details: --------------- Date/time: Thursday Sep 23(a)17.00 (UTC+2) https://everytimezone.com/s/35c9885e Connection details: https://www.trustedfirmware.org/meetings/ Meeting notes: http://bit.ly/loc-notes Regards, Ruchika on behalf of the Linaro OP-TEE team

4 years, 6 months

1
1
0 0

2026

2025

2024

2023

2022

2021

2020

Linaro-open-discussions