CoreSight November 2024

coresight@lists.linaro.org

7 participants
33 discussions

[PATCH v6 0/3] coresight: Add static trace id support

by Mao Jinlong

Some HW has static trace id which cannot be changed via software programming. For this case, configure the trace id in device tree with "arm,static-trace-id = <xxx>", and call coresight_trace_id_get_static_system_id with the trace id value in device probe function. The id will be reserved for the HW all the time if the device is probed. Changes since V5: 1. Remove the warn for staic id not available. 2. Drop the system_id if registering the coresight device fails. 3. Return busy when static id is not available in dummy driver. Changes since V4: 1. Use fwnode_property_read_u32 in fwnode_property_read_u32. 2. Update date and version in sysfs-bus-coresight-devices-dummy-source Changes since V3: 1. Adda new API function int coresight_trace_id_get_system_static_id(int trace_id). 2. Use the term "static trace id" for these devices where the hardware sets a non-programmable trace ID. Changes since V2: 1. Change "trace-id" to "arm,trace-id". 2. Add trace id flag for getting preferred id or ODD id. Changes since V1: 1. Add argument to coresight_trace_id_get_system_id for preferred id instead of adding new function coresight_trace_id_reserve_system_id. 2. Add constraint to trace-id in dt-binding file. Mao Jinlong (3): dt-bindings: arm: Add arm,static-trace-id for coresight dummy source coresight: Add support to get static id for system trace sources coresight: dummy: Add static trace id support for dummy source .../sysfs-bus-coresight-devices-dummy-source | 15 ++++ .../arm/arm,coresight-dummy-source.yaml | 6 ++ drivers/hwtracing/coresight/coresight-dummy.c | 81 ++++++++++++++++--- .../hwtracing/coresight/coresight-platform.c | 6 ++ .../hwtracing/coresight/coresight-trace-id.c | 39 ++++++--- .../hwtracing/coresight/coresight-trace-id.h | 9 +++ include/linux/coresight.h | 1 + 7 files changed, 137 insertions(+), 20 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-bus-coresight-devices-dummy-source -- 2.17.1

5 months

[PATCH v5 0/4] source filtering for multi-port output

by Tao Zhang

In our hardware design, by combining a funnel and a replicator, it implement a hardware device with one-to-one correspondence between output ports and input ports. The programming usage on this device is the same as funnel. The software uses a funnel and a static replicator to implement the driver of this device. Since original funnels only support a single output connection and original replicator only support a single input connection, the code needs to be modified to support this new feature. The following is a typical topology diagram of multi-port output mechanism. |----------| |---------| |----------| |---------| | TPDM 0 | | Source0 | | Source 1 | | TPDM 1 | |----------| |---------| |----------| |---------| | | | | | | | | | --------- | | | | | | | | | | | | | | | \-------------/ ---------------------- | \ Funnel 0 / | | ----------- | ------------------------------ | | | | | | \------------------/ \ Funnel 1 / ----| \--------------/ | | |----> Combine a funnel and a | | static replicator /-----------------\ | / replicator 0 \ ----| /---------------------\ | | | | | |-----------| | |---------| | | |TPDM0 |TPDM1 | \-----------------/ | \ TPDA 0 / | \-------------/ | | | | |Source0/1 | \-------------------------------/ \ Funnel 2 / \---------------------------/ Changes in V5: 1. Replace "filter-src" with "filter-source" in the dt-binding document. -- Suzuki K Poulose 2. Optimize the comments of the patch "coresight: Add support for trace filtering by source" due to bad example. -- Suzuki K Poulose 3. Correct spelling errors in the patch "coresight: Add support for trace filtering by source". -- Suzuki K Poulose 4. Optimize the function "coresight_blocks_source". -- Suzuki K Poulose 5. Add { } in the function "of_coresight_parse_endpoint". -- Suzuki K Poulose 6. Adjust the order of the patches. -- Suzuki K Poulose 7. Adjust the alignment in "coresight-platform.c". -- Suzuki K Poulose Changes in V4: 1. Use "coresight_get_source(path)" in the function "coresight_disable_path_from" instead of explicitly passing the source. -- Suzuki K Poulose 2. Optimize the order of the input parameters for "_coresight_build_path". -- Suzuki K Poulose 3. Reuse the method "coresight_block_source" in "_coresight_build_path". -- Suzuki K Poulose 4. Remove the unnecessary () in "coresight_build_path". -- Suzuki K Poulose 5. Add a helper to check if a device is SOURCE. -- Suzuki K Poulose 6. Adjust the posistion of setting "still_orphan" in "coresight_build_path". -- Suzuki K Poulose Changes in V3: 1. Rename the function "coresight_source_filter" to "coresight_block_source". And refine this function. -- Suzuki K Poulose 2. Rename the parameters of the function "coresight_find_out_connection" to avoid confusion. -- Suzuki K Poulose 3. Get the source of path in "coresight_enable_path" and "coresight_disable_path". -- Suzuki K Poulose 4. Fix filter source device before skip the port in "coresight_orphan_match". -- Suzuki K Poulose 5. Make sure the device still orphan if whter is a filter source firmware node but the filter source device is null. -- Suzuki K Poulose 6. Walk through the entire coresight bus and fixup the "filter_src_dev" if the source is being removed. -- Suzuki K Poulose 7. Refine the commit description of patch#2. -- Suzuki K Poulose 8. Fix the warning reported by kernel test robot. -- kernel test robot. 9. Use the source device directly if the port has a hardcoded filter in "tpda_get_element_size". -- Suzuki K Poulose Changes in V2: 1. Change the reference for endpoint property in dt-binding. -- Krzysztof Kozlowski 2. Change the property name "filter_src" to "filter-src". -- Krzysztof Kozlowski 3. Fix the errors in running 'make dt_binding_check'. -- Rob Herring 4. Pass in the source parameter instead of path. -- Suzuki K Poulose 5. Reset the "filter_src_dev" if the "src" csdev is being removed. -- Suzuki K Poulose 6. Add a warning if the "filter_src_dev" is of not the type DEV_TYPE_SOURCE. -- Suzuki K Poulose 7. Optimize the procedure for handling all possible cases. -- Suzuki K Poulose Changes in V1: 1. Add a static replicator connect to a funnel to implement the correspondence between the output ports and the input ports on funnels. -- Suzuki K Poulose 2. Add filter_src_dev and filter_src_dev phandle to "coresight_connection" struct, and populate them if there is one. -- Suzuki K Poulose 3. To look at the phandle and then fixup/remove the filter_src device in fixup/remove connections. -- Suzuki K Poulose 4. When TPDA reads DSB/CMB element size, it is implemented by looking up filter src device in the connections. -- Suzuki K Poulose Tao Zhang (4): dt-bindings: arm: qcom,coresight-static-replicator: Add property for source filtering coresight: Add a helper to check if a device is source coresight: Add support for trace filtering by source coresight-tpda: Optimize the function of reading element size .../arm/arm,coresight-static-replicator.yaml | 19 ++- drivers/hwtracing/coresight/coresight-core.c | 113 +++++++++++++++--- .../hwtracing/coresight/coresight-platform.c | 18 +++ drivers/hwtracing/coresight/coresight-tpda.c | 13 +- include/linux/coresight.h | 12 +- 5 files changed, 152 insertions(+), 23 deletions(-) -- 2.17.1

5 months

Re: [PATCH 04/15] coresight: etm4x: don't include 'pm_wakeup.h' directly

by Suzuki K Poulose

On 18/11/2024 07:29, Wolfram Sang wrote: > The header clearly states that it does not want to be included directly, > only via 'device.h'. 'platform_device.h' works equally well. Remove the > direct inclusion. > > Signed-off-by: Wolfram Sang <wsa+renesas(a)sang-engineering.com> > --- > drivers/hwtracing/coresight/coresight-etm4x-core.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/hwtracing/coresight/coresight-etm4x-core.c b/drivers/hwtracing/coresight/coresight-etm4x-core.c > index 66d44a404ad0..559972a00fdf 100644 > --- a/drivers/hwtracing/coresight/coresight-etm4x-core.c > +++ b/drivers/hwtracing/coresight/coresight-etm4x-core.c > @@ -23,7 +23,6 @@ > #include <linux/cpu_pm.h> > #include <linux/coresight.h> > #include <linux/coresight-pmu.h> > -#include <linux/pm_wakeup.h> > #include <linux/amba/bus.h> > #include <linux/seq_file.h> > #include <linux/uaccess.h> If you plan to take this as a collection outside of CoreSight tree, Acked-by: Suzuki K Poulose <suzuki.poulose(a)arm.com> Otherwise, I can pick this up. Suzuki

5 months

Re: [PATCH v7 04/12] KVM: arm64: Make vcpu flag macros more generic

by James Clark

On 18/11/2024 9:00 am, Marc Zyngier wrote: > On Tue, 12 Nov 2024 10:37:03 +0000, > James Clark <james.clark(a)linaro.org> wrote: >> >> Rename vcpu_* to kvm_* so that the same flags mechanism can be used in >> places other than vcpu without being confusing. Wherever macros are >> still related to vcpu like vcpu_get_flag() with hard coded v->arch, keep >> the vcpu_* name, otherwise change it. >> >> Also move the "v->arch" access one macro higher for the same reason. >> >> This will be used for moving flags to host_data in a later commit. >> >> Signed-off-by: James Clark <james.clark(a)linaro.org> >> --- >> arch/arm64/include/asm/kvm_host.h | 88 +++++++++++++++---------------- >> arch/arm64/kvm/hyp/exception.c | 12 ++--- >> arch/arm64/kvm/inject_fault.c | 4 +- >> arch/arm64/kvm/mmio.c | 10 ++-- >> 4 files changed, 57 insertions(+), 57 deletions(-) >> >> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h >> index f333b189fb43..34aa59f498c4 100644 >> --- a/arch/arm64/include/asm/kvm_host.h >> +++ b/arch/arm64/include/asm/kvm_host.h >> @@ -790,22 +790,22 @@ struct kvm_vcpu_arch { >> /* >> * Each 'flag' is composed of a comma-separated triplet: >> * >> - * - the flag-set it belongs to in the vcpu->arch structure >> + * - the flag-set it belongs to in the structure pointed to by 'v' >> * - the value for that flag >> * - the mask for that flag >> * >> - * __vcpu_single_flag() builds such a triplet for a single-bit flag. >> - * unpack_vcpu_flag() extract the flag value from the triplet for >> + * __kvm_single_flag() builds such a triplet for a single-bit flag. >> + * unpack_kvm_flag() extract the flag value from the triplet for >> * direct use outside of the flag accessors. >> */ >> -#define __vcpu_single_flag(_set, _f) _set, (_f), (_f) >> +#define __kvm_single_flag(_set, _f) _set, (_f), (_f) >> >> #define __unpack_flag(_set, _f, _m) _f >> -#define unpack_vcpu_flag(...) __unpack_flag(__VA_ARGS__) >> +#define unpack_kvm_flag(...) __unpack_flag(__VA_ARGS__) >> >> #define __build_check_flag(v, flagset, f, m) \ >> do { \ >> - typeof(v->arch.flagset) *_fset; \ >> + typeof(v.flagset) *_fset; \ >> \ >> /* Check that the flags fit in the mask */ \ >> BUILD_BUG_ON(HWEIGHT(m) != HWEIGHT((f) | (m))); \ >> @@ -813,11 +813,11 @@ struct kvm_vcpu_arch { >> BUILD_BUG_ON((sizeof(*_fset) * 8) <= __fls(m)); \ >> } while (0) >> >> -#define __vcpu_get_flag(v, flagset, f, m) \ >> +#define __kvm_get_flag(v, flagset, f, m) \ >> ({ \ >> __build_check_flag(v, flagset, f, m); \ >> \ >> - READ_ONCE(v->arch.flagset) & (m); \ >> + READ_ONCE(v.flagset) & (m); \ >> }) >> >> /* >> @@ -826,64 +826,64 @@ struct kvm_vcpu_arch { >> */ >> #ifdef __KVM_NVHE_HYPERVISOR__ >> /* the nVHE hypervisor is always non-preemptible */ >> -#define __vcpu_flags_preempt_disable() >> -#define __vcpu_flags_preempt_enable() >> +#define __kvm_flags_preempt_disable() >> +#define __kvm_flags_preempt_enable() >> #else >> -#define __vcpu_flags_preempt_disable() preempt_disable() >> -#define __vcpu_flags_preempt_enable() preempt_enable() >> +#define __kvm_flags_preempt_disable() preempt_disable() >> +#define __kvm_flags_preempt_enable() preempt_enable() >> #endif >> >> -#define __vcpu_set_flag(v, flagset, f, m) \ >> +#define __kvm_set_flag(v, flagset, f, m) \ > > Hell no. Never. The whole point of this naming is that we know what > this applies to. Here, you might as well have replaced 'vcpu' with > 'carrot', and the result would be the same. > > Not to mention the insane churn this generates. > > So no, not happening. > > M. > Fair enough, I wasn't feeling to strongly about this either, was just anticipating that there might be objection to bare flags if this more abstracted mechanism existed elsewhere. Looks like Oliver already did it with just flags for the same end goal here [1], so I will drop this. [1]: https://lore.kernel.org/kvmarm/20241115224924.2132364-4-oliver.upton@linux.…

5 months

Re: [PATCH 1/2] coresight: tmc: Don't change the buffer size if it's in use

by James Clark

On 14/11/2024 2:51 pm, Yicong Yang wrote: > On 2024/11/14 18:30, James Clark wrote: >> >> >> On 14/11/2024 8:16 am, Yicong Yang wrote: >>> From: Yicong Yang <yangyicong(a)hisilicon.com> >>> >>> Enable the trace in below steps will crash the kernel by NULL pointer >>> dereferencing: >>> echo 1 > /sys/bus/coresight/devices/tmc_etr0/enable_sink >>> echo 1 > /sys/bus/coresight/devices/etm0/enable_source >>> echo 0x400000 > /sys/bus/coresight/devices/tmc_etr0/buffer_size >>> echo 1 > /sys/bus/coresight/devices/etm2/enable_source >>> dd if=/dev/tmc_etr0 of=test_etm_sysfs_etr_030.data >>> >>> The call trace will be like: >>> WARNING: CPU: 39 PID: 8586 at drivers/hwtracing/coresight/coresight-tmc-etr.c:1123 __tmc_etr_disable_hw+0x108/0x140 [coresight_tmc] >>> [...] >>> Call trace: >>> __tmc_etr_disable_hw+0x108/0x140 [coresight_tmc] >>> tmc_read_prepare_etr+0xc0/0xd0 [coresight_tmc] >>> tmc_open+0x60/0xa0 [coresight_tmc] >>> misc_open+0x11c/0x170 >>> chrdev_open+0xcc/0x2b0 >>> do_dentry_open+0x140/0x4e0 >>> vfs_open+0x34/0xf8 >>> path_openat+0x2b0/0xf58 >>> do_filp_open+0x8c/0x148 >>> do_sys_openat2+0xb8/0xe8 >>> __arm64_sys_openat+0x70/0xc0 >>> el0_svc_common.constprop.0+0x64/0x148 >>> do_el0_svc+0x24/0x38 >>> el0_svc+0x40/0x140 >>> el0t_64_sync_handler+0xc0/0xc8 >>> el0t_64_sync+0x1a4/0x1a8 >>> ---[ end trace 0000000000000000 ]--- >>> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000028 >>> [...] >>> Call trace: >>> tmc_etr_get_sysfs_trace+0x10/0x80 [coresight_tmc] >>> vfs_read+0xcc/0x310 >>> ksys_read+0x74/0x108 >>> __arm64_sys_read+0x24/0x38 >>> el0_svc_common.constprop.0+0x64/0x148 >>> do_el0_svc+0x24/0x38 >>> el0_svc+0x40/0x140 >>> >>> Due to the buffer size changed, the buffer will be reallocated in >>> tmc_etr_get_sysfs_buffer() when the second source enabled. At trace >>> end tmc_etr_sync_sysfs_buf() will reset the drvdata->sysfs_buf and >>> trigger the later NULL pointer dereference when reading out the >>> data. >>> >>> But it doesn't make sense to change the buffer size when it's >>> already in use. So block such behavior. >>> >>> Signed-off-by: Yicong Yang <yangyicong(a)hisilicon.com> >>> --- >>> drivers/hwtracing/coresight/coresight-tmc-core.c | 5 +++++ >>> 1 file changed, 5 insertions(+) >>> >>> diff --git a/drivers/hwtracing/coresight/coresight-tmc-core.c b/drivers/hwtracing/coresight/coresight-tmc-core.c >>> index 475fa4bb6813..9660af63e9bc 100644 >>> --- a/drivers/hwtracing/coresight/coresight-tmc-core.c >>> +++ b/drivers/hwtracing/coresight/coresight-tmc-core.c >>> @@ -319,6 +319,11 @@ static ssize_t buffer_size_store(struct device *dev, >>> if (drvdata->config_type != TMC_CONFIG_TYPE_ETR) >>> return -EPERM; >>> + /* Don't change the buffer size if it's in use */ >>> + guard(spinlock)(&drvdata->spinlock); >>> + if (coresight_get_mode(drvdata->csdev) != CS_MODE_DISABLED) >> >> Size isn't used in perf mode is it? So it can be -EBUSY only when mode == CS_MODE_SYSFS. >> > > alloc_etr_buf() on the perf path will read drvdata->size, not sure it matters if user > change it through sysfs in the meanwhile. Will test and have a check if there are any > other places using size on the perf path. > Hmmm I assumed that Perf mode completely ignored anything from sysfs mode. I see that alloc_etr_buf() does sometimes use the sysfs value. I don't really see why that's necessary because that means it sometimes ignores the buffer size from the perf command line depending on what's in sysfs, but the modes should be mutually exclusive. Unless we fix that then I think you do need to use the device spinlock. But I think we should tidy up alloc_etr_buf() to only try to allocate from the Perf size down to TMC_ETR_PERF_MIN_BUF_SIZE, ignoring drvdata->size. Then the behavior is less surprising to users and also anyone reading the code. And rename it to alloc_etr_buf_perf(). Unless Suzuki knows of a reason it was done that way to begin with? I checked the commit message but it just says that it was like that but not why. >>> + return -EBUSY; >>> + >>> ret = kstrtoul(buf, 0, &val); >>> if (ret) >>> return ret; >> >> Looks ok to me. Although for consistency it might be worth changing to guard(mutex)(&coresight_mutex) because this is about sysfs mode only and other usages of mode and comments point to coresight_mutex. Using the device's spinlock will technically work but it did make me go and double check the code. And there are other cases of reading the mode like this: >> > > ok, I thought to also serialize the use of drvdata->size. But as you mentioned > use coresight_mutex is enough and will be consistenct with other places. > >> static ssize_t enable_source_show(struct device *dev, >> struct device_attribute *attr, >> char *buf) >> { >> struct coresight_device *csdev = to_coresight_device(dev); >> >> guard(mutex)(&coresight_mutex); >> return scnprintf(buf, PAGE_SIZE, "%u\n", >> coresight_get_mode(csdev) == CS_MODE_SYSFS); >> } >> >> Mode can change to CS_MODE_PERF while inside coresight_mutex but the device would end up not being enabled for sysfs, so it's still ok to update the sysfs size value in that case. >> >> With that change: >> >> Reviewed-by: James Clark <james.clark(a)linaro.org> > > Thanks. >

5 months

Re: [PATCH 2/2] coresight: tmc: Add missing doc of tmc_drvdata::reading

by James Clark

On 14/11/2024 8:16 am, Yicong Yang wrote: > From: Yicong Yang <yangyicong(a)hisilicon.com> > > tmc_drvdata::reading is used to indicate whether a reading process > is performed through /dev/xyz.tmc. Document it. > > Signed-off-by: Yicong Yang <yangyicong(a)hisilicon.com> > --- > drivers/hwtracing/coresight/coresight-tmc.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/hwtracing/coresight/coresight-tmc.h b/drivers/hwtracing/coresight/coresight-tmc.h > index 2671926be62a..fdf7955e7350 100644 > --- a/drivers/hwtracing/coresight/coresight-tmc.h > +++ b/drivers/hwtracing/coresight/coresight-tmc.h > @@ -174,6 +174,7 @@ struct etr_buf { > * @pid: Process ID of the process that owns the session that is using > * this component. For example this would be the pid of the Perf > * process. > + * @reading: buffer's in the reading through "/dev/xyz.tmc" entry > * @buf: Snapshot of the trace data for ETF/ETB. > * @etr_buf: details of buffer used in TMC-ETR > * @len: size of the available trace for ETF/ETB. Reviewed-by: James Clark <james.clark(a)linaro.org>

5 months

Re: [PATCH 1/2] coresight: tmc: Don't change the buffer size if it's in use

by James Clark

On 14/11/2024 8:16 am, Yicong Yang wrote: > From: Yicong Yang <yangyicong(a)hisilicon.com> > > Enable the trace in below steps will crash the kernel by NULL pointer > dereferencing: > echo 1 > /sys/bus/coresight/devices/tmc_etr0/enable_sink > echo 1 > /sys/bus/coresight/devices/etm0/enable_source > echo 0x400000 > /sys/bus/coresight/devices/tmc_etr0/buffer_size > echo 1 > /sys/bus/coresight/devices/etm2/enable_source > dd if=/dev/tmc_etr0 of=test_etm_sysfs_etr_030.data > > The call trace will be like: > WARNING: CPU: 39 PID: 8586 at drivers/hwtracing/coresight/coresight-tmc-etr.c:1123 __tmc_etr_disable_hw+0x108/0x140 [coresight_tmc] > [...] > Call trace: > __tmc_etr_disable_hw+0x108/0x140 [coresight_tmc] > tmc_read_prepare_etr+0xc0/0xd0 [coresight_tmc] > tmc_open+0x60/0xa0 [coresight_tmc] > misc_open+0x11c/0x170 > chrdev_open+0xcc/0x2b0 > do_dentry_open+0x140/0x4e0 > vfs_open+0x34/0xf8 > path_openat+0x2b0/0xf58 > do_filp_open+0x8c/0x148 > do_sys_openat2+0xb8/0xe8 > __arm64_sys_openat+0x70/0xc0 > el0_svc_common.constprop.0+0x64/0x148 > do_el0_svc+0x24/0x38 > el0_svc+0x40/0x140 > el0t_64_sync_handler+0xc0/0xc8 > el0t_64_sync+0x1a4/0x1a8 > ---[ end trace 0000000000000000 ]--- > Unable to handle kernel NULL pointer dereference at virtual address 0000000000000028 > [...] > Call trace: > tmc_etr_get_sysfs_trace+0x10/0x80 [coresight_tmc] > vfs_read+0xcc/0x310 > ksys_read+0x74/0x108 > __arm64_sys_read+0x24/0x38 > el0_svc_common.constprop.0+0x64/0x148 > do_el0_svc+0x24/0x38 > el0_svc+0x40/0x140 > > Due to the buffer size changed, the buffer will be reallocated in > tmc_etr_get_sysfs_buffer() when the second source enabled. At trace > end tmc_etr_sync_sysfs_buf() will reset the drvdata->sysfs_buf and > trigger the later NULL pointer dereference when reading out the > data. > > But it doesn't make sense to change the buffer size when it's > already in use. So block such behavior. > > Signed-off-by: Yicong Yang <yangyicong(a)hisilicon.com> > --- > drivers/hwtracing/coresight/coresight-tmc-core.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/drivers/hwtracing/coresight/coresight-tmc-core.c b/drivers/hwtracing/coresight/coresight-tmc-core.c > index 475fa4bb6813..9660af63e9bc 100644 > --- a/drivers/hwtracing/coresight/coresight-tmc-core.c > +++ b/drivers/hwtracing/coresight/coresight-tmc-core.c > @@ -319,6 +319,11 @@ static ssize_t buffer_size_store(struct device *dev, > if (drvdata->config_type != TMC_CONFIG_TYPE_ETR) > return -EPERM; > > + /* Don't change the buffer size if it's in use */ > + guard(spinlock)(&drvdata->spinlock); > + if (coresight_get_mode(drvdata->csdev) != CS_MODE_DISABLED) Size isn't used in perf mode is it? So it can be -EBUSY only when mode == CS_MODE_SYSFS. > + return -EBUSY; > + > ret = kstrtoul(buf, 0, &val); > if (ret) > return ret; Looks ok to me. Although for consistency it might be worth changing to guard(mutex)(&coresight_mutex) because this is about sysfs mode only and other usages of mode and comments point to coresight_mutex. Using the device's spinlock will technically work but it did make me go and double check the code. And there are other cases of reading the mode like this: static ssize_t enable_source_show(struct device *dev, struct device_attribute *attr, char *buf) { struct coresight_device *csdev = to_coresight_device(dev); guard(mutex)(&coresight_mutex); return scnprintf(buf, PAGE_SIZE, "%u\n", coresight_get_mode(csdev) == CS_MODE_SYSFS); } Mode can change to CS_MODE_PERF while inside coresight_mutex but the device would end up not being enabled for sysfs, so it's still ok to update the sysfs size value in that case. With that change: Reviewed-by: James Clark <james.clark(a)linaro.org>

5 months

Re: [PATCH v2] Coresight: Narrow down the matching range of tpdm

by Suzuki K Poulose

On 09/10/2024 10:17, Songwei Chai wrote: > The format of tpdm's peripheral id is 1f0exx. To avoid potential > conflicts in the future, update the .id_table's id to 0x001f0e00. > This update will narrow down the matching range and prevent incorrect > matches. For example, another component's peripheral id might be > f0e00, which would incorrectly match the old id. > > Fixes: b3c71626a9333b0b29f9921a39ce ("Coresight: Add coresight TPDM source driver") > Signed-off-by: Songwei Chai <quic_songchai(a)quicinc.com> > --- > drivers/hwtracing/coresight/coresight-tpdm.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/hwtracing/coresight/coresight-tpdm.c b/drivers/hwtracing/coresight/coresight-tpdm.c > index b7d99e91ab84..3230d76aed90 100644 > --- a/drivers/hwtracing/coresight/coresight-tpdm.c > +++ b/drivers/hwtracing/coresight/coresight-tpdm.c > @@ -1308,8 +1308,8 @@ static void tpdm_remove(struct amba_device *adev) > */ > static struct amba_id tpdm_ids[] = { > { > - .id = 0x000f0e00, > - .mask = 0x000fff00, > + .id = 0x001f0e00, > + .mask = 0x00ffff00, > }, > { 0, 0, NULL }, > }; > Looks good to me, will queue this for v6.14. Apologies for missing the v6.13 cycle Suzuki

5 months

Re: [PATCH V11 0/2] arm-cs-trace-disasm.py/perf must accommodate non-zero DSO text offset

by Steve Clevenger

On 11/9/2024 8:37 AM, Namhyung Kim wrote: > On Fri, 08 Nov 2024 12:11:19 -0700, Steve Clevenger wrote: > >> Changes in V11: >> - Corrected prefix. >> - Fixed compile-time error for perf debug build by substituting in >> the map__pgoff macro (trace_event_python.c). >> >> Changes in V10: >> - Removed errant space in patch file 0002. Passed 'git apply --check' >> at perf-tools-next, 6.11.0-rc6. >> - Added back missing prefixes. >> >> [...] > > Applied to perf-tools-next, thanks! > > Best regards, > Namhyung > Thanks, Namhyung. Steve C.

5 months, 1 week

[PATCH v7 00/12] kvm/coresight: Support exclude guest and exclude host

by James Clark

FEAT_TRF is a Coresight feature that allows trace capture to be completely filtered at different exception levels, unlike the existing TRCVICTLR controls which may still emit target addresses of branches, even if the following trace is filtered. Without FEAT_TRF, it was possible to start a trace session on a host and also collect trace from the guest as TRCVICTLR was never programmed to exclude guests (and it could still emit target addresses even if it was). With FEAT_TRF, the current behavior of trace in guests exists depends on whether nVHE or VHE are being used. Both of the examples below are from the host's point of view, as Coresight isn't accessible from guests. This patchset is only relevant to when FEAT_TRF exists, otherwise there is no change. Current behavior: nVHE/pKVM: Because the host and the guest are both using TRFCR_EL1, trace will be generated in guests depending on the same filter rules the host is using. For example if the host is tracing userspace only, then guest userspace trace will also be collected. (This is further limited by whether TRBE is used because an issue with TRBE means that it's completely disabled in nVHE guests, but it's possible to have other tracing components.) VHE: With VHE, the host filters will be in TRFCR_EL2, but the filters in TRFCR_EL1 will be active when the guest is running. Because we don't write to TRFCR_EL1, guest trace will be completely disabled. New behavior: The guest filtering rules from the Perf session are now honored for both nVHE and VHE modes. This is done by either writing to TRFCR_EL12 at the start of the Perf session and doing nothing else further, or caching the guest value and writing it at guest switch for nVHE. In pKVM, trace is now be disabled for both protected and unprotected guests. There is also an optimization where the SPE and Coresight drivers pass their enabled state to KVM. This means in the common case KVM doesn't have to touch any sysregs when the feature isn't in use. Applies to kvmarm/next (25a8556b54007) --- Changes since V6 [5]: * Implement a better "do nothing" case where both the SPE and Coresight drivers give the enabled state to KVM, allowing some register reads to be dropped. * Move the state and feature flags out of the vCPU into the per-CPU host_debug_state. * Simplify the switch logic by adding a new flag HOST_STATE_SWAP_TRFCR and only storing a single TRFCR value. * Rename vcpu flag macros to a more generic kvm_flag... Changes since V5 [4]: * Sort new sysreg entries by encoding * Add a comment about sorting arch/arm64/tools/sysreg * Warn on preemptible() before calling smp_processor_id() * Pickup tags * Change TRFCR_EL2 from SysregFields to Sysreg because it was only used once Changes since V4 [3]: * Remove all V3 changes that made it work in pKVM and just disable trace there instead * Restore PMU host/hyp state sharing back to how it was (kvm_pmu_update_vcpu_events()) * Simplify some of the duplication in the comments and function docs * Add a WARN_ON_ONCE() if kvm_etm_set_guest_trfcr() is called when the trace filtering feature doesn't exist. * Split sysreg change into a tools update followed by the new register addition Changes since V3: * Create a new shared area to store the host state instead of copying it before each VCPU run * Drop commit that moved SPE and trace registers from host_debug_state into the kvm sysregs array because the guest values were never used * Document kvm_etm_set_guest_trfcr() * Guard kvm_etm_set_guest_trfcr() with a feature check * Drop Mark B and Suzuki's review tags on the sysreg patch because it turned out that broke the Perf build and needed some unconventional changes to fix it (as in: to update the tools copy of the headers in the same commit as the kernel changes) Changes since V2: * Add a new iflag to signify presence of FEAT_TRF and keep the existing TRBE iflag. This fixes the issue where TRBLIMITR_EL1 was being accessed even if TRBE didn't exist * Reword a commit message Changes since V1: * Squashed all the arm64/tools/sysreg changes into the first commit * Add a new commit to move SPE and TRBE regs into the kvm sysreg array * Add a comment above the TRFCR global that it's per host CPU rather than vcpu Changes since nVHE RFC [1]: * Re-write just in terms of the register value to be written for the host and the guest. This removes some logic from the hyp code and a value of kvm_vcpu_arch:trfcr_el1 = 0 no longer means "don't restore". * Remove all the conditional compilation and new files. * Change the kvm_etm_update_vcpu_events macro to a function. * Re-use DEBUG_STATE_SAVE_TRFCR so iflags don't need to be expanded anymore. * Expand the cover letter. Changes since VHE v3 [2]: * Use the same interface as nVHE mode so TRFCR_EL12 is now written by kvm. [1]: https://lore.kernel.org/kvmarm/20230804101317.460697-1-james.clark@arm.com/ [2]: https://lore.kernel.org/kvmarm/20230905102117.2011094-1-james.clark@arm.com/ [3]: https://lore.kernel.org/linux-arm-kernel/20240104162714.1062610-1-james.cla… [4]: https://lore.kernel.org/all/20240220100924.2761706-1-james.clark@arm.com/ [5]: https://lore.kernel.org/linux-arm-kernel/20240226113044.228403-1-james.clar… James Clark (12): arm64/sysreg: Add a comment that the sysreg file should be sorted tools: arm64: Update sysreg.h header files arm64/sysreg/tools: Move TRFCR definitions to sysreg KVM: arm64: Make vcpu flag macros more generic KVM: arm64: Move SPE and TRBE flags to host data KVM: arm64: Add flag for FEAT_TRF KVM: arm64: arm_spe: Give SPE enabled state to KVM KVM: arm64: Don't hit sysregs to see if SPE is enabled or not KVM: arm64: coresight: Give TRBE enabled state to KVM KVM: arm64: Don't hit sysregs to see if TRBE is enabled or not KVM: arm64: Swap TRFCR on guest switch coresight: Pass guest TRFCR value to KVM arch/arm64/include/asm/kvm_host.h | 123 +++--- arch/arm64/include/asm/kvm_hyp.h | 2 +- arch/arm64/include/asm/sysreg.h | 12 - arch/arm64/kvm/arm.c | 3 - arch/arm64/kvm/debug.c | 97 ++++- arch/arm64/kvm/hyp/exception.c | 12 +- arch/arm64/kvm/hyp/nvhe/debug-sr.c | 118 +++-- arch/arm64/kvm/hyp/nvhe/switch.c | 2 +- arch/arm64/kvm/inject_fault.c | 4 +- arch/arm64/kvm/mmio.c | 10 +- arch/arm64/tools/sysreg | 38 ++ .../coresight/coresight-etm4x-core.c | 43 +- drivers/hwtracing/coresight/coresight-etm4x.h | 2 +- drivers/hwtracing/coresight/coresight-priv.h | 3 + drivers/hwtracing/coresight/coresight-trbe.c | 15 +- drivers/perf/arm_spe_pmu.c | 13 +- tools/arch/arm64/include/asm/sysreg.h | 410 +++++++++++++++++- tools/include/linux/kasan-tags.h | 15 + 18 files changed, 755 insertions(+), 167 deletions(-) create mode 100644 tools/include/linux/kasan-tags.h -- 2.34.1

5 months, 1 week

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

CoreSight November 2024