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

[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

3 years, 6 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

3 years, 6 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

3 years, 6 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

3 years, 7 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

3 years, 7 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

3 years, 7 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

3 years, 7 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

3 years, 8 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

3 years, 9 months

1
1
0 0

Re: [Linaro-open-discussions] LOD Meeting Agenda for August 23

by Jonathan Cameron

On Thu, 26 Aug 2021 14:16:02 +0000 Jonathan Cameron via Linaro-open-discussions <linaro-open-discussions(a)op-lists.linaro.org> wrote: > On Fri, 20 Aug 2021 11:48:41 +0100 > Lorenzo Pieralisi <lorenzo.pieralisi(a)arm.com> wrote: > > > On Wed, Aug 18, 2021 at 08:05:18PM +0800, Jammy Zhou wrote: > > > If we move it to 1st or 2nd, is there any topic to discuss? Otherwise, > > > maybe we can cancel it for this month. > > > > I would be _extremely_ grateful if Jonathan could run a session on > > his series: > > > > https://lore.kernel.org/linux-pci/20210804161839.3492053-1-Jonathan.Cameron… > > > > in preparation for LPC. > > Sure - would be good to get my thoughts in order on this and doing it for next > week will stop me leaving it all to the last minute. > > > Actually, I wanted to ask if there is a kernel > > tree/branch I can pull in order to review those patches, I am struggling > > to find a commit base to apply them. > > My bad. I got lazy in a build up to vacation and didn't put one up anywhere. > The various trees involved are rather too dynamic for just pointing at them > and saying apply these series (which have merge conflicts to resolve). > Naughty me.... > > Currently wading through the messages backlog, but will aim to have a branch up sometime > tomorrow + ideally some more detailed instructions on getting it up and running. Hi Lorenzo / All, https://github.com/hisilicon/kernel-dev/tree/doe-spdm-v1 rebased to 5.14-rc7 https://github.com/hisilicon/qemu/tree/cxl-hacks rebased to qemu/master as of earlier today. For qemu side of things you need to be running spdm_responsder_emu --trans PCI_DOE from https://github.com/DMTF/spdm-emu first (that will act as server to qemu acting as a client). Various parameters allow you to change the algorithms advertised and the kernel code should work for all the ones CMA mandates (but nothing beyond that for now). For the cxl device the snippet of qemu commandline needed is: -device cxl-type3,bus=root_port13,memdev=cxl-mem1,lsa=cxl-mem1, id=cxl-pmem0,size=2G,spdm=true Otherwise much the same as https://people.kernel.org/jic23/ Build at least the cxl_pci driver as a module as we need to poke the certificate into the keychain before that (find the cert in spdm_emu tree). Instructions to do that with keyctl and evmctl are in the cover letter of the patch series. Hopefully I'll find some time next week to put together some proper instructions and email them in reply to the original posting. Jonathan > > Jonathan > > > > > Thanks, > > Lorenzo > > > > > On Tue, 17 Aug 2021 at 21:42, Jonathan Cameron <Jonathan.Cameron(a)huawei.com> > > > wrote: > > > > > > On Tue, 17 Aug 2021 12:28:45 +0100 > > > Lorenzo Pieralisi <lorenzo.pieralisi(a)arm.com> wrote: > > > > > > > On Mon, Aug 16, 2021 at 08:41:29AM +0000, Jonathan Cameron via > > > Linaro-open-discussions wrote: > > > > > > > > > > > > > > > Hi Jammy, > > > > > > > > > > I'll be away until the 26th, but obviously that should be no barrier > > > > > to topics I am less involved with as I can easily catch up later. > > > > > > > > Maybe it is best to reschedule it early September since it is holiday > > > > season. I could do September 1st and 2nd and the following week. > > > > > > 1st and 2nd work for me. Early the following week also fine. > > > Note Linaro connect is 8-10th Sept so we should avoid any clashes. > > > > > > Jonathan > > > > > > > > > > > > > > Please let me know what you think. > > > > > > > > Thanks, > > > > Lorenzo > > > > > > > > > > > > > > Thanks > > > > > > > > > > Jonathan > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > > Jonathan Cameron > > > > > Mobile: +44-7870588074 > > > > > Email: jonathan.cameron(a)huawei.com<mailto:jonathan.cameron@huawei.com> > > > > > From:Jammy Zhou via Linaro-open-discussions < > > > linaro-open-discussions(a)op-lists.linaro.org> > > > > > To:Lorenzo Pieralisi via Linaro-open-discussions < > > > linaro-open-discussions(a)op-lists.linaro.org> > > > > > Date:2021-08-16 06:01:50 > > > > > Subject:[Linaro-open-discussions] LOD Meeting Agenda for August 23 > > > > > > > > > > Hi all, > > > > > > > > > > We're going to have the next monthly call for Linaro Open Discussions > > > in > > > > > one week. Please let me know if you have any topic for discussion. > > > > > > > > > > Thanks, > > > > > Jammy > > > > > -- > > > > > Linaro-open-discussions mailing list > > > > > https://collaborate.linaro.org/display/LOD/Linaro+Open+Discussions+Home > > > > > https://op-lists.linaro.org/mailman/listinfo/linaro-open-discussions > > > > > -- > > > > > Linaro-open-discussions mailing list > > > > > https://collaborate.linaro.org/display/LOD/Linaro+Open+Discussions+Home > > > > > https://op-lists.linaro.org/mailman/listinfo/linaro-open-discussions > > > > > > >

3 years, 9 months

2
4
0 0

2025

2024

2023

2022

2021

2020

Linaro-open-discussions