On 2025-08-26 2:43 pm, Mark Rutland wrote:
On Wed, Aug 13, 2025 at 06:01:10PM +0100, Robin Murphy wrote:
Only a handful of CPU PMUs accept PERF_TYPE_{RAW,HARDWARE,HW_CACHE}
events without registering themselves as PERF_TYPE_RAW in the first
place. Add an explicit opt-in for these special cases
On 2025-08-26 2:28 pm, Mark Rutland wrote:
On Tue, Aug 26, 2025 at 03:08:06PM +0200, Peter Zijlstra wrote:
On Wed, Aug 13, 2025 at 06:01:08PM +0100, Robin Murphy wrote:
Sampling is inherently a feature for CPU PMUs, given that the thing
to be sampled is a CPU context. These days, we have many
On 2025-08-26 2:11 pm, Leo Yan wrote:
On Wed, Aug 13, 2025 at 06:01:08PM +0100, Robin Murphy wrote:
Sampling is inherently a feature for CPU PMUs, given that the thing
to be sampled is a CPU context. These days, we have many more
uncore/system PMUs than CPU PMUs, so it no longer makes much
On 2025-08-26 2:03 pm, Peter Zijlstra wrote:
On Wed, Aug 13, 2025 at 06:01:04PM +0100, Robin Murphy wrote:
It may have been different long ago, but today it seems wrong for these
drivers to skip counting disabled sibling events in group validation,
given that perf_event_enable() could make them
On 2025-08-26 12:15 pm, Mark Rutland wrote:
On Wed, Aug 13, 2025 at 06:00:54PM +0100, Robin Murphy wrote:
The group validation logic shared by the HiSilicon HNS3/PCIe drivers is
a bit off, in that given a software group leader, it will consider that
event *in place of* the actual new event
Hi Thomas,
On 2025-08-20 9:09 am, Thomas Richter wrote:
On 8/19/25 15:15, Robin Murphy wrote:
On 13/08/2025 6:01 pm, Robin Murphy wrote:
Only a handful of CPU PMUs accept PERF_TYPE_{RAW,HARDWARE,HW_CACHE}
events without registering themselves as PERF_TYPE_RAW in the first
place. Add an
ab-lkp/linux/commits/Robin-Murphy/perf-arm-cmn-Fix-event-validation/20250814-010626
base: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git
91325f31afc1026de28665cf1a7b6e157fa4d39d
patch link:
https://lore.kernel.org/all/ace3532a8a438a96338bf349a27636d8294c7111.1755096883.git.robin.m
On 13/08/2025 6:01 pm, Robin Murphy wrote:
[...]
diff --git a/arch/x86/events/intel/uncore.c b/arch/x86/events/intel/uncore.c
index 297ff5adb667..98ffab403bb4 100644
--- a/arch/x86/events/intel/uncore.c
+++ b/arch/x86/events/intel/uncore.c
@@ -731,24 +731,11 @@ static int uncore_pmu_event_init
On 13/08/2025 6:01 pm, Robin Murphy wrote:
Only a handful of CPU PMUs accept PERF_TYPE_{RAW,HARDWARE,HW_CACHE}
events without registering themselves as PERF_TYPE_RAW in the first
place. Add an explicit opt-in for these special cases, so that we can
make life easier for every other driver (and
to look like one of the hardware siblings.
The uncore framework avoids that particular issue, but all 3 also share
the common issue of not preventing racy access to the sibling list, and
some redundant checks which can be cleaned up.
Signed-off-by: Robin Murphy
---
drivers/perf/hisilicon
having perf_try_init_event() do the basic type
checking to cover the majority of cases.
Signed-off-by: Robin Murphy
---
A further possibility is to automatically add the cap to PERF_TYPE_RAW
PMUs in perf_pmu_register() to have a single point-of-use condition; I'm
undecided...
---
arch
ING.
- has_branch_stack()
Now doubly-illogical for PMUs which never supported sampling
anyway.
Signed-off-by: Robin Murphy
---
arch/arm/mach-imx/mmdc.c | 14 -
arch/arm/mm/cache-l2x0-pmu.c | 10 ---
arch/powerpc/perf/hv-24x7.c
Now that we have a well-defined cap for sampling support, clean up the
remains of the mildly unintuitive and inconsistently-applied
PERF_PMU_CAP_NO_INTERRUPT. Not to mention the obvious redundancy of
some of these drivers still checking for sampling in event_init too.
Signed-off-by: Robin Murphy
(or erroneously fail to). Instead, let's
introduce a positive opt-in capability that's more obvious and easier to
maintain.
Signed-off-by: Robin Murphy
---
arch/alpha/kernel/perf_event.c | 3 ++-
arch/arc/kernel/perf_event.c | 2 ++
arch/csky/kernel/perf_event.c
).
Signed-off-by: Robin Murphy
---
drivers/perf/arm-cci.c | 47 +++---
1 file changed, 12 insertions(+), 35 deletions(-)
diff --git a/drivers/perf/arm-cci.c b/drivers/perf/arm-cci.c
index 1cc3214d6b6d..086d4363fcc8 100644
--- a/drivers/perf/arm-cci.c
+++ b
software-only group.
In particular it took a while to see that marvell_cn10k_tad_pmu was
seemingly trying to rely on the empirical behaviour of perf tool
creating group leader events with disabled=1 and subsequent siblings
with disabled=0. Down with this sort of thing!
Signed-off-by: Robin Murphy
down to
trivial counting.
Signed-off-by: Robin Murphy
---
drivers/perf/arm_cspmu/arm_cspmu.c | 7 ++-
drivers/perf/arm_dsu_pmu.c | 6 ++
drivers/perf/arm_pmu.c | 11 ++-
drivers/perf/thunderx2_pmu.c | 30 +++---
4 files changed, 13 in
ility
of their own events within the given group, for now at least removing
this redundant code makes it even clearer that they are not.
Signed-off-by: Robin Murphy
---
drivers/perf/arm-ccn.c | 16
drivers/perf/fsl_imx9_ddr_perf.c | 16
drivers/per
truly dead then it stands to reason that the whole
group is dead, so it's not worth going to any special effort to try to
squeeze in a new event that's never going to run anyway. Thus, we can
simply remove all these checks.
Signed-off-by: Robin Murphy
---
arch/alpha/kernel/perf_eve
which doesn't belong to our PMU. Similarly drop the early return
paths since they can almost never actually return early.
Signed-off-by: Robin Murphy
---
drivers/perf/arm-ni.c | 29 +
1 file changed, 13 insertions(+), 16 deletions(-)
diff --git a/drivers/perf/arm-ni.c
The group validation here is almost right, but fails to count the new
event itself. While we fix that, also adopt the standard pattern to
avoid racy access the sibling list and drop checks that are redundant
with core code.
Signed-off-by: Robin Murphy
---
arch/arm/mm/cache-l2x0-pmu.c | 9
vents which do not belong to our PMU.
The L2 driver gets a cleanup of some slightly suspicious logic, and both
can have the same overall simplification to not duplicate things that perf
core will already do, and avoid racy access to the sibling list of group
leader events.
Signed-off-by: Robin M
Signed-off-by: Robin Murphy
---
drivers/perf/arm_smmuv3_pmu.c | 22 +-
1 file changed, 9 insertions(+), 13 deletions(-)
diff --git a/drivers/perf/arm_smmuv3_pmu.c b/drivers/perf/arm_smmuv3_pmu.c
index 621f02a7f43b..7cac380a3528 100644
--- a/drivers/perf/arm_smmuv3_pmu.c
+++
with core code.
Signed-off-by: Robin Murphy
---
arch/arm/mach-imx/mmdc.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-imx/mmdc.c b/arch/arm/mach-imx/mmdc.c
index 94e4f4a2f73f..f9d432b385a2 100644
--- a/arch/arm/mach-imx/mmdc.c
+++ b/arch/arm
ss to the sibling list when the event is its own group leader.
Signed-off-by: Robin Murphy
---
drivers/iommu/intel/perfmon.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/iommu/intel/perfmon.c b/drivers/iommu/intel/perfmon.c
index 75f493b
The group validation code here is superficially the right shape, but
is failing to count the group leader, while also erroneously counting
software siblings. Just correctly count the events which belong to our
PMU, and let perf core worry about the rest.
Signed-off-by: Robin Murphy
---
drivers
there... Thankfully the way to be more robust is to be
less clever - stop trying to special-case software events and simply
skip any event that isn't for our PMU.
Signed-off-by: Robin Murphy
---
drivers/perf/arm-cmn.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/driver
() will already check for us.
Signed-off-by: Robin Murphy
---
drivers/perf/fsl_imx8_ddr_perf.c | 21 +
1 file changed, 5 insertions(+), 16 deletions(-)
diff --git a/drivers/perf/fsl_imx8_ddr_perf.c b/drivers/perf/fsl_imx8_ddr_perf.c
index b989ffa95d69..56fe281974d2 100644
---
e rest into per-driver patches, but I'm sure
nobody wants a ~70-patch series out of the gate :)
Thanks,
Robin.
Robin Murphy (19):
perf/arm-cmn: Fix event validation
perf/hisilicon: Fix group validation
perf/imx8_ddr: Fix group validation
perf/starfive: Fix group validation
iommu
seems to be the first "bad"
commit
`
commit bcb81ac6ae3c2ef95b44e7b54c3c9522364a245c
Author: Robin Murphy mailto:robin.mur...@arm.com
Date: Fri Feb 28 15:46:33 2025 +
iommu:
On 11/04/2024 4:04 pm, Thorsten Blum wrote:
Use `find . -type f -exec sed -i 's/\/the/g' {} +` to find all
occurrences of "the the" and replace them with a single "the".
[...]
diff --git a/arch/arm/include/asm/unwind.h b/arch/arm/include/asm/unwind.h
index d60b09a5acfc..a75da9a01f91 100644
---
here from search lore (hope
I didn't miss anything), so let's give it a try.
Ciao, Thorsten
On Thursday, 22 September 2022 14:09:35 CEST Robin Murphy wrote:
On 22/09/2022 11:10 am, Janusz Krzysztofik wrote:
From: Chris Wilson
Manual revert of commit f598a497bc7d ("iova: Add CP
On 22/09/2022 11:10 am, Janusz Krzysztofik wrote:
From: Chris Wilson
Manual revert of commit f598a497bc7d ("iova: Add CPU hotplug handler to
flush rcaches"). It is trying to instantiate a cpuhp notifier from inside
a cpuhp callback. That code replaced intel_iommu implementation of
flushing pe
On 2022-09-14 16:01, Lucas De Marchi wrote:
On Wed, Sep 14, 2022 at 02:40:45PM +0200, Karolina Drobnik wrote:
This reverts commit ac9a5d522bb80be50ea84965699e1c8257d745ce.
This change introduces a regression on Alder Lake that completely
blocks testing. To enable CI and avoid possible circular
Matt Roper
Matt, Lucas, any feed back here?
On 2022-03-02 4:49 a.m., Robin Murphy wrote:
On 2022-02-25 19:27, Michael Cheng wrote:
Hi Robin,
[ +arm64 maintainers for their awareness, which would have been a
good thing to do from the start ]
* Thanks for adding the arm64 maintainer and s
you have for using clflush in the first place can no longer be
assumed to be valid.
Robin.
On 2022-02-25 10:24 a.m., Robin Murphy wrote:
[ +arm64 maintainers for their awareness, which would have been a good
thing to do from the start ]
On 2022-02-25 03:24, Michael Cheng wrote:
Add arm64
[ +arm64 maintainers for their awareness, which would have been a good
thing to do from the start ]
On 2022-02-25 03:24, Michael Cheng wrote:
Add arm64 support for drm_clflush_virt_range. caches_clean_inval_pou
performs a flush by first performing a clean, follow by an invalidation
operation.
mples
of it around). So from the IOMMU perspective,
Acked-by: Robin Murphy
Perhaps the AGP driver could also be tweaked and intel_iommu_gfx_mapped
cleaned away entirely, but I'll leave that for Baolu to think about :)
Cheers,
Robin.
It was suggested to additionally
On 2021-11-10 09:35, Tvrtko Ursulin wrote:
On 10/11/2021 07:25, Lu Baolu wrote:
On 2021/11/10 1:35, Tvrtko Ursulin wrote:
On 09/11/2021 17:19, Lucas De Marchi wrote:
On Tue, Nov 09, 2021 at 12:17:59PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
On igfx + dgfx setups, it appears that
On 2021-11-10 14:11, Tvrtko Ursulin wrote:
On 10/11/2021 12:35, Lu Baolu wrote:
On 2021/11/10 20:08, Tvrtko Ursulin wrote:
On 10/11/2021 12:04, Lu Baolu wrote:
On 2021/11/10 17:30, Tvrtko Ursulin wrote:
On 10/11/2021 07:12, Lu Baolu wrote:
Hi Tvrtko,
On 2021/11/9 20:17, Tvrtko Ursulin wr
Hi,
FWIW this patch itself looks fine, but it does highlight some things
which could be further cleaned up if anyone's interested...
On 2021-08-22 22:06, Christophe JAILLET wrote:
[...]
diff --git a/drivers/gpu/drm/i915/gt/intel_region_lmem.c
b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
ind
On 2021-07-06 15:05, Christoph Hellwig wrote:
On Tue, Jul 06, 2021 at 03:01:04PM +0100, Robin Murphy wrote:
FWIW I was pondering the question of whether to do something along those
lines or just scrap the default assignment entirely, so since I hadn't got
round to saying that I've
On 2021-07-06 14:24, Will Deacon wrote:
On Tue, Jul 06, 2021 at 06:48:48AM +0200, Christoph Hellwig wrote:
On Mon, Jul 05, 2021 at 08:03:52PM +0100, Will Deacon wrote:
So at this point, the AMD IOMMU driver does:
swiotlb= (iommu_default_passthrough() || sme_me_mask) ? 1 : 0;
w
On 2021-07-02 14:58, Will Deacon wrote:
Hi Nathan,
On Thu, Jul 01, 2021 at 12:52:20AM -0700, Nathan Chancellor wrote:
On 7/1/2021 12:40 AM, Will Deacon wrote:
On Wed, Jun 30, 2021 at 08:56:51AM -0700, Nathan Chancellor wrote:
On Wed, Jun 30, 2021 at 12:43:48PM +0100, Will Deacon wrote:
On We
On 2021-07-02 04:08, Guenter Roeck wrote:
Hi,
On Thu, Jun 24, 2021 at 11:55:26PM +0800, Claire Chang wrote:
If a device is not behind an IOMMU, we look up the device node and set
up the restricted DMA when the restricted-dma-pool is presented.
Signed-off-by: Claire Chang
Tested-by: Stefano St
On 2021-06-24 07:05, Claire Chang wrote:
On Thu, Jun 24, 2021 at 1:43 PM Christoph Hellwig wrote:
On Wed, Jun 23, 2021 at 02:44:34PM -0400, Qian Cai wrote:
is_swiotlb_force_bounce at /usr/src/linux-next/./include/linux/swiotlb.h:119
is_swiotlb_force_bounce() was the new function introduced i
On 2021-06-24 12:18, Will Deacon wrote:
On Thu, Jun 24, 2021 at 12:14:39PM +0100, Robin Murphy wrote:
On 2021-06-24 07:05, Claire Chang wrote:
On Thu, Jun 24, 2021 at 1:43 PM Christoph Hellwig wrote:
On Wed, Jun 23, 2021 at 02:44:34PM -0400, Qian Cai wrote:
is_swiotlb_force_bounce at /usr
On 2021-06-03 10:17, Tvrtko Ursulin wrote:
Hi,
On 03/06/2021 09:40, Joonas Lahtinen wrote:
+ Tvrtko to take a look
Quoting Konrad Rzeszutek Wilk (2021-05-20 18:12:58)
On Mon, May 10, 2021 at 05:25:25PM +0200, Christoph Hellwig wrote:
Hi all,
swiotlb_max_segment is a rather strange "API" ex
On 2021-04-22 09:15, Claire Chang wrote:
The restricted DMA pool is preferred if available.
The restricted DMA pools provide a basic level of protection against the
DMA overwriting buffer contents at unexpected times. However, to protect
against general data leakage and system memory corruption,
On 2021-04-22 09:15, Claire Chang wrote:
Update is_swiotlb_active to add a struct device argument. This will be
useful later to allow for restricted DMA pool.
Signed-off-by: Claire Chang
---
drivers/gpu/drm/i915/gem/i915_gem_internal.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_ttm.c| 2
On 2021-04-22 09:15, Claire Chang wrote:
If a device is not behind an IOMMU, we look up the device node and set
up the restricted DMA when the restricted-dma-pool is presented.
Signed-off-by: Claire Chang
---
drivers/of/address.c| 25 +
drivers/of/device.c |
On 2021-02-04 07:29, Christoph Hellwig wrote:
On Wed, Feb 03, 2021 at 03:37:05PM -0800, Dongli Zhang wrote:
This patch converts several swiotlb related variables to arrays, in
order to maintain stat/status for different swiotlb buffers. Here are
variables involved:
- io_tlb_start and io_tlb_end
On 2020-09-27 07:34, Lu Baolu wrote:
Combining the sg segments exposes a bug in the Intel i915 driver which
causes visual artifacts and the screen to freeze. This is most likely
because of how the i915 handles the returned list. It probably doesn't
respect the returned value specifying the number
On 2020-09-15 09:31, Tvrtko Ursulin wrote:
On 15/09/2020 02:47, Lu Baolu wrote:
Hi Tvrtko,
On 9/14/20 4:04 PM, Tvrtko Ursulin wrote:
Hi,
On 12/09/2020 04:21, Lu Baolu wrote:
Tom Murphy has almost done all the work. His latest patch series was
posted here.
https://lore.kernel.org/linux-iom
On 2020-09-18 21:47, Logan Gunthorpe wrote:
Hi Lu,
On 2020-09-11 9:21 p.m., Lu Baolu wrote:
Tom Murphy has almost done all the work. His latest patch series was
posted here.
https://lore.kernel.org/linux-iommu/20200903201839.7327-1-murph...@tcd.ie/
Thanks a lot!
This series is a follow-up wi
On 2020-09-09 21:06, Joe Perches wrote:
fallthrough to a separate case/default label break; isn't very readable.
Convert pseudo-keyword fallthrough; statements to a simple break; when
the next label is case or default and the only statement in the next
label block is break;
Found using:
$ grep
: Bartlomiej Zolnierkiewicz ; David Airlie
; intel-gfx@lists.freedesktop.org; Robin Murphy
; Christoph Hellwig ; linux-arm-
ker...@lists.infradead.org; Marek Szyprowski
Subject: [Intel-gfx] [PATCH v9 08/32] drm: i915: fix common struct sg_table
related issues
The Documentation/DMA-API-HOWTO.txt
es the common DMA-mapping wrappers operating
directly on the struct sg_table objects to the dmabuf related functions,
so the other drivers, which might share buffers with i915 could rely on
the properly set nents and orig_nents values.
This one looks mechanical enough :)
Reviewed-by: Robin
Hi Tom,
On 2019-12-21 15:03, Tom Murphy wrote:
This patchset converts the intel iommu driver to the dma-iommu api.
While converting the driver I exposed a bug in the intel i915 driver which
causes a huge amount of artifacts on the screen of my laptop. You can see a
picture of it here:
https:/
On 2020-04-28 4:32 pm, Daniel Vetter wrote:
On Tue, Apr 28, 2020 at 04:02:57PM +0200, Christoph Hellwig wrote:
On Tue, Apr 28, 2020 at 03:19:48PM +0200, Marek Szyprowski wrote:
1. introduce a dma_{map,sync,unmap}_sgtable() wrappers, which will use
a proper sg_table entries and call respecti
On 2019-12-23 10:37 am, Jani Nikula wrote:
On Sat, 21 Dec 2019, Tom Murphy wrote:
This patchset converts the intel iommu driver to the dma-iommu api.
While converting the driver I exposed a bug in the intel i915 driver
which causes a huge amount of artifacts on the screen of my
laptop. You can
t; check. Does that match
your reasoning?
Assuming I haven't completely misread the problem, I can't think of a
more appropriate way to fix it, so;
Reviewed-by: Robin Murphy
I could swear I did consider that corner case at some point, but since
Leizhen and I rewrote this stuff abo
On 14/06/2019 15:50, 'Christoph Hellwig' wrote:
On Fri, Jun 14, 2019 at 02:15:44PM +, David Laight wrote:
Does this still guarantee that requests for 16k will not cross a 16k boundary?
It looks like you are losing the alignment parameter.
The DMA API never gave you alignment guarantees to
63 matches
Mail list logo
