* Re: [RFC PATCH 4/8] mm/vmalloc: Eliminate page table zigzag for huge vmalloc mappings
From: Barry Song @ 2026-04-13 19:49 UTC (permalink / raw)
To: Mike Rapoport
Cc: linux-mm, linux-arm-kernel, catalin.marinas, will, akpm, urezki,
linux-kernel, anshuman.khandual, ryan.roberts, ajd, david,
Xueyuan.chen21
In-Reply-To: <ad0Wyq5--L0SeIqr@kernel.org>
On Tue, Apr 14, 2026 at 12:16 AM Mike Rapoport <rppt@kernel.org> wrote:
>
> On Wed, Apr 08, 2026 at 10:51:11AM +0800, Barry Song (Xiaomi) wrote:
> > For vmalloc() allocations with VM_ALLOW_HUGE_VMAP, we no longer
> > need to iterate over pages one by one, which would otherwise lead to
> > zigzag page table mappings.
> >
> > The code is now unified with the PAGE_SHIFT case by simply
> > calling vmap_small_pages_range_noflush().
> >
> > Signed-off-by: Barry Song (Xiaomi) <baohua@kernel.org>
> > ---
> > mm/vmalloc.c | 22 ++++------------------
> > 1 file changed, 4 insertions(+), 18 deletions(-)
> >
> > diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> > index 5bf072297536..eba436386929 100644
> > --- a/mm/vmalloc.c
> > +++ b/mm/vmalloc.c
> > @@ -689,27 +689,13 @@ static int vmap_small_pages_range_noflush(unsigned long addr, unsigned long end,
> > int __vmap_pages_range_noflush(unsigned long addr, unsigned long end,
> > pgprot_t prot, struct page **pages, unsigned int page_shift)
> > {
> > - unsigned int i, nr = (end - addr) >> PAGE_SHIFT;
> > -
> > WARN_ON(page_shift < PAGE_SHIFT);
> >
> > - if (!IS_ENABLED(CONFIG_HAVE_ARCH_HUGE_VMALLOC) ||
> > - page_shift == PAGE_SHIFT)
> > - return vmap_small_pages_range_noflush(addr, end, prot, pages, PAGE_SHIFT);
> > -
> > - for (i = 0; i < nr; i += 1U << (page_shift - PAGE_SHIFT)) {
> > - int err;
> > -
> > - err = vmap_range_noflush(addr, addr + (1UL << page_shift),
> > - page_to_phys(pages[i]), prot,
> > - page_shift);
> > - if (err)
> > - return err;
> > + if (!IS_ENABLED(CONFIG_HAVE_ARCH_HUGE_VMALLOC))
> > + page_shift = PAGE_SHIFT;
> >
> > - addr += 1UL << page_shift;
> > - }
> > -
> > - return 0;
> > + return vmap_small_pages_range_noflush(addr, end, prot, pages,
> > + min(page_shift, PMD_SHIFT));
>
> Wouldn't vmap_range_noflush() already "do the right thing" even without
> changes to vmap_small_pages_range_noflush()?
vmap_range_noflush does the right thing for the contiguous physical
address - ioremap case where we map contiguous physical addresses
for iomem etc.
for pages array, they are not contiguous physical addresses. they might be
multiple contiguous physical addresses, but they are not contiguous as
a whole.
>
> > }
> >
> > int vmap_pages_range_noflush(unsigned long addr, unsigned long end,
> > --
Thanks
Barry
^ permalink raw reply
* Re: [RFC PATCH 5/8] mm/vmalloc: map contiguous pages in batches for vmap() if possible
From: Barry Song @ 2026-04-13 19:56 UTC (permalink / raw)
To: David Hildenbrand (Arm)
Cc: Uladzislau Rezki, Dev Jain, linux-mm, linux-arm-kernel,
catalin.marinas, will, akpm, linux-kernel, anshuman.khandual,
ryan.roberts, ajd, rppt, Xueyuan.chen21
In-Reply-To: <1ed24e47-538a-493d-bf37-af76a789ce76@kernel.org>
On Tue, Apr 14, 2026 at 3:24 AM David Hildenbrand (Arm)
<david@kernel.org> wrote:
>
> On 4/10/26 03:02, Barry Song wrote:
> > On Thu, Apr 9, 2026 at 6:20 PM Uladzislau Rezki <urezki@gmail.com> wrote:
> > [...]
> >>>
> >> It would be good if you could combine the work together with Jain.
> >>
> >
> > Sure, thanks! After discussing with Dev Jain, we’ll also
> > support non-compound pages in the next version.
>
> Will there be a v3 or should I review v2?
>
> https://lore.kernel.org/r/20260404084333.55984-1-baohua@kernel.org
Hi David, sorry for the confusion. During development, I
found many more opportunities across vmalloc, ioremap, and
vmap, so I dropped the original approach that only targeted
vmap.
Let me reply there and say that it has been withdrawn.
>
> --
> Cheers,
>
> David
^ permalink raw reply
* Re: [PATCH RFC v3 4/4] mm: add PMD-level huge page support for remap_pfn_range()
From: David Hildenbrand (Arm) @ 2026-04-13 20:02 UTC (permalink / raw)
To: Yin Tirui, linux-kernel, linux-mm, x86, linux-arm-kernel, willy,
catalin.marinas, will, tglx, mingo, bp, dave.hansen, hpa, luto,
peterz, akpm, lorenzo.stoakes, ziy, baolin.wang, Liam.Howlett,
npache, ryan.roberts, dev.jain, baohua, lance.yang, vbabka, rppt,
surenb, mhocko, anshuman.khandual, rmclure, kevin.brodsky,
apopple, ajd, pasha.tatashin, bhe, thuth, coxu, dan.j.williams,
yu-cheng.yu, yangyicong, baolu.lu, jgross, conor.dooley,
Jonathan.Cameron, riel
Cc: wangkefeng.wang, chenjun102
In-Reply-To: <20260228070906.1418911-5-yintirui@huawei.com>
On 2/28/26 08:09, Yin Tirui wrote:
> Add PMD-level huge page support to remap_pfn_range(), automatically
> creating huge mappings when prerequisites are satisfied (size, alignment,
> architecture support, etc.) and falling back to normal page mappings
> otherwise.
>
> Implement special huge PMD splitting by utilizing the pgtable deposit/
> withdraw mechanism. When splitting is needed, the deposited pgtable is
> withdrawn and populated with individual PTEs created from the original
> huge mapping.
>
> Signed-off-by: Yin Tirui <yintirui@huawei.com>
> ---
[...]
>
> if (!vma_is_anonymous(vma)) {
> old_pmd = pmdp_huge_clear_flush(vma, haddr, pmd);
> +
> + if (!vma_is_dax(vma) && vma_is_special_huge(vma)) {
These magical vma checks are really bad. This all needs a cleanup
(Lorenzo is doing some, hoping it will look better on top of that).
> + pte_t entry;
> +
> + if (!pmd_special(old_pmd)) {
If you are using pmd_special(), you are doing something wrong.
Hint: vm_normal_page_pmd() is usually what you want.
> + zap_deposited_table(mm, pmd);
> + return;
> + }
> + pgtable = pgtable_trans_huge_withdraw(mm, pmd);
> + if (unlikely(!pgtable))
> + return;
> + pmd_populate(mm, &_pmd, pgtable);
> + pte = pte_offset_map(&_pmd, haddr);
> + entry = pfn_pte(pmd_pfn(old_pmd), pmd_pgprot(old_pmd));
> + set_ptes(mm, haddr, pte, entry, HPAGE_PMD_NR);
> + pte_unmap(pte);
> +
> + smp_wmb(); /* make pte visible before pmd */
> + pmd_populate(mm, pmd, pgtable);
> + return;
> + }
> +
> /*
> * We are going to unmap this huge page. So
> * just go ahead and zap it
> */
> if (arch_needs_pgtable_deposit())
> zap_deposited_table(mm, pmd);
> - if (!vma_is_dax(vma) && vma_is_special_huge(vma))
> - return;
> +
> if (unlikely(pmd_is_migration_entry(old_pmd))) {
> const softleaf_t old_entry = softleaf_from_pmd(old_pmd);
>
> diff --git a/mm/memory.c b/mm/memory.c
> index 07778814b4a8..affccf38cbcf 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -2890,6 +2890,40 @@ static int remap_pte_range(struct mm_struct *mm, pmd_t *pmd,
> return err;
> }
>
> +#ifdef CONFIG_ARCH_SUPPORTS_PMD_PFNMAP
Why exactly do we need arch support for that in form of a Kconfig.
Usually, we guard pmd support by CONFIG_TRANSPARENT_HUGEPAGE.
And then, we must check at runtime if PMD leaves are actually supported.
Luiz is working on a cleanup series:
https://lore.kernel.org/r/cover.1775679721.git.luizcap@redhat.com
pgtable_has_pmd_leaves() is what you would want to check.
> +static int remap_try_huge_pmd(struct mm_struct *mm, pmd_t *pmd,
> + unsigned long addr, unsigned long end,
> + unsigned long pfn, pgprot_t prot)
Use two-tab indent. (currently 3? :) )
Also, we tend to call these things now "pmd leaves". Call it
"remap_try_pmd_leaf" or something even more expressive like
"remap_try_install_pmd_leaf()"
> +{
> + pgtable_t pgtable;
> + spinlock_t *ptl;
> +
> + if ((end - addr) != PMD_SIZE)
if (end - addr != PMD_SIZE)
Should work
> + return 0;
> +
> + if (!IS_ALIGNED(addr, PMD_SIZE))
> + return 0;
> +
You could likely combine both things into a
if (!IS_ALIGNED(addr | end, PMD_SIZE))
> + if (!IS_ALIGNED(pfn, HPAGE_PMD_NR))
Another sign that you piggy-back on THP support ;)
> + return 0;
> +
> + if (pmd_present(*pmd) && !pmd_free_pte_page(pmd, addr))
> + return 0;
Ripping out a page table?! That doesn't sound right :)
Why is that required? We shouldn't be doing that here. Gah.
Especially, without any pmd locks etc.
> +
> + pgtable = pte_alloc_one(mm);
> + if (unlikely(!pgtable))
> + return 0;
> +
> + mm_inc_nr_ptes(mm);
> + ptl = pmd_lock(mm, pmd);
> + set_pmd_at(mm, addr, pmd, pmd_mkspecial(pmd_mkhuge(pfn_pmd(pfn, prot))));
> + pgtable_trans_huge_deposit(mm, pmd, pgtable);
> + spin_unlock(ptl);
> +
> + return 1;
> +}
> +#endif
> +
> static inline int remap_pmd_range(struct mm_struct *mm, pud_t *pud,
> unsigned long addr, unsigned long end,
> unsigned long pfn, pgprot_t prot)
> @@ -2905,6 +2939,12 @@ static inline int remap_pmd_range(struct mm_struct *mm, pud_t *pud,
> VM_BUG_ON(pmd_trans_huge(*pmd));
> do {
> next = pmd_addr_end(addr, end);
> +#ifdef CONFIG_ARCH_SUPPORTS_PMD_PFNMAP
> + if (remap_try_huge_pmd(mm, pmd, addr, next,
> + pfn + (addr >> PAGE_SHIFT), prot)) {
Please provide a stub instead so we don't end up with ifdef in this code.
--
Cheers,
David
^ permalink raw reply
* Re: [RFC PATCH 3/8] mm/vmalloc: Extend vmap_small_pages_range_noflush() to support larger page_shift sizes
From: Barry Song @ 2026-04-13 20:16 UTC (permalink / raw)
To: Mike Rapoport
Cc: linux-mm, linux-arm-kernel, catalin.marinas, will, akpm, urezki,
linux-kernel, anshuman.khandual, ryan.roberts, ajd, david,
Xueyuan.chen21
In-Reply-To: <ad0U-IEvZkFwpBsg@kernel.org>
On Tue, Apr 14, 2026 at 12:08 AM Mike Rapoport <rppt@kernel.org> wrote:
>
> Hi Barry,
Thanks for reviewing, Mike!
>
> On Wed, Apr 08, 2026 at 10:51:10AM +0800, Barry Song (Xiaomi) wrote:
> > vmap_small_pages_range_noflush() provides a clean interface by taking
> > struct page **pages and mapping them via direct PTE iteration. This
> > avoids the page table zigzag seen when using
> > vmap_range_noflush() for page_shift values other than PAGE_SHIFT.
> >
> > Extend it to support larger page_shift values, and add PMD- and
> > contiguous-PTE mappings as well.
> >
> > Signed-off-by: Barry Song (Xiaomi) <baohua@kernel.org>
> > ---
> > mm/vmalloc.c | 54 ++++++++++++++++++++++++++++++++++++++++------------
> > 1 file changed, 42 insertions(+), 12 deletions(-)
> >
> > diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> > index 57eae99d9909..5bf072297536 100644
> > --- a/mm/vmalloc.c
> > +++ b/mm/vmalloc.c
> > @@ -524,8 +524,9 @@ void vunmap_range(unsigned long addr, unsigned long end)
> >
> > static int vmap_pages_pte_range(pmd_t *pmd, unsigned long addr,
> > unsigned long end, pgprot_t prot, struct page **pages, int *nr,
> > - pgtbl_mod_mask *mask)
> > + pgtbl_mod_mask *mask, unsigned int shift)
> > {
> > + unsigned int steps = 1;
> > int err = 0;
> > pte_t *pte;
> >
> > @@ -543,6 +544,7 @@ static int vmap_pages_pte_range(pmd_t *pmd, unsigned long addr,
> > do {
> > struct page *page = pages[*nr];
> >
> > + steps = 1;
> > if (WARN_ON(!pte_none(ptep_get(pte)))) {
> > err = -EBUSY;
> > break;
> > @@ -556,9 +558,24 @@ static int vmap_pages_pte_range(pmd_t *pmd, unsigned long addr,
> > break;
> > }
> >
> > +#ifdef CONFIG_HUGETLB_PAGE
>
> Why is this related to HUGETLB_PAGE?
This is also a question I asked myself during development.
Currently, huge mappings in mm/vmalloc have an ugly
dependency on HUGETLB, as hugetlb provides the APIs for
mapping multiple PTEs. Right now, set_ptes() is mainly used
for large folios in userspace; if it can fully support kernel
page tables, I would be very happy to remove this dependency
on HUGETLB entirely, including in the ioremap case in
vmap_pte_range().
I recall Ryan once mentioned some issues with using set_ptes()
for kernel mappings?
Once that issue is resolved, we can entirely remove the
HUGETLB dependency in mm/vmalloc.c.
>
> > + if (shift != PAGE_SHIFT) {
> > + unsigned long pfn = page_to_pfn(page), size;
> > +
> > + size = arch_vmap_pte_range_map_size(addr, end, pfn, shift);
> > + if (size != PAGE_SIZE) {
> > + steps = size >> PAGE_SHIFT;
> > + pte_t entry = pfn_pte(pfn, prot);
> > +
> > + entry = arch_make_huge_pte(entry, ilog2(size), 0);
> > + set_huge_pte_at(&init_mm, addr, pte, entry, size);
> > + continue;
> > + }
> > + }
> > +#endif
> > +
> > set_pte_at(&init_mm, addr, pte, mk_pte(page, prot));
> > - (*nr)++;
> > - } while (pte++, addr += PAGE_SIZE, addr != end);
> > + } while (pte += steps, *nr += steps, addr += PAGE_SIZE * steps, addr != end);
> >
> > lazy_mmu_mode_disable();
> > *mask |= PGTBL_PTE_MODIFIED;
> > @@ -568,7 +585,7 @@ static int vmap_pages_pte_range(pmd_t *pmd, unsigned long addr,
> >
> > static int vmap_pages_pmd_range(pud_t *pud, unsigned long addr,
> > unsigned long end, pgprot_t prot, struct page **pages, int *nr,
> > - pgtbl_mod_mask *mask)
> > + pgtbl_mod_mask *mask, unsigned int shift)
> > {
> > pmd_t *pmd;
> > unsigned long next;
> > @@ -578,7 +595,20 @@ static int vmap_pages_pmd_range(pud_t *pud, unsigned long addr,
> > return -ENOMEM;
> > do {
> > next = pmd_addr_end(addr, end);
> > - if (vmap_pages_pte_range(pmd, addr, next, prot, pages, nr, mask))
> > +
> > + if (shift == PMD_SHIFT) {
> > + struct page *page = pages[*nr];
> > + phys_addr_t phys_addr = page_to_phys(page);
> > +
> > + if (vmap_try_huge_pmd(pmd, addr, next, phys_addr, prot,
> > + shift)) {
> > + *mask |= PGTBL_PMD_MODIFIED;
> > + *nr += 1 << (shift - PAGE_SHIFT);
> > + continue;
> > + }
>
> With this vmap_pages_pmd_range() looks quite similar to vmap_pmd_range().
> Any changes we can consolidate the two?
vmap_pmd_range() is for the ioremap case where we may have
8MB of contiguous memory. This is the case where we have
8MB total, but it is composed of 2MB chunks plus some
remainder. We might be able to extract some common code
though.
Thanks
Barry
^ permalink raw reply
* Re: [PATCH net-next] net: stmmac: enable RPS and RBU interrupts
From: Jakub Kicinski @ 2026-04-13 20:50 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Andrew Lunn, Alexandre Torgue, Andrew Lunn, David S. Miller,
Eric Dumazet, linux-arm-kernel, linux-stm32, netdev, Paolo Abeni,
Sam Edwards
In-Reply-To: <ad06yiZZbLC9k3jY@shell.armlinux.org.uk>
On Mon, 13 Apr 2026 19:49:46 +0100 Russell King (Oracle) wrote:
> > Firing interrupts when Rx fill ring runs dry (which IIUC this patches
> > dies?) is not a good idea.
>
> Well, I'm thinking that at least on some platforms, such as the Jetson
> Xavier NX, unless a different solution can be found, we need the RBU
> interrupt to fire off a reset of the stmmac IP when this happens to
> reduce the PAUSE frame flood on the network.
>
> If we can't do that, then I think stmmac on these platforms needs to be
> marked with CONFIG_BROKEN because right now there doesn't seem to be any
> other viable solution.
>
> My intention with this patch is merely to start collecting the already
> existing statistics so other users can start seeing whether they are
> hitting the same or similar problem. If we're not prepared to do that,
> then we should delete the useless statistics from ethtool -S, but I
> suspect they're now part of the UAPI, even though without this patch
> they will remain stedfastly stuck at zero.
Understood, thanks for the extra context. And the statistic we are
talking about is rx_buf_unav_irq ?
^ permalink raw reply
* Re: [PATCH net-next] net: stmmac: enable RPS and RBU interrupts
From: Russell King (Oracle) @ 2026-04-13 20:53 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Andrew Lunn, Alexandre Torgue, Andrew Lunn, David S. Miller,
Eric Dumazet, linux-arm-kernel, linux-stm32, netdev, Paolo Abeni,
Sam Edwards
In-Reply-To: <20260413135018.59fbd3a1@kernel.org>
On Mon, Apr 13, 2026 at 01:50:18PM -0700, Jakub Kicinski wrote:
> On Mon, 13 Apr 2026 19:49:46 +0100 Russell King (Oracle) wrote:
> > > Firing interrupts when Rx fill ring runs dry (which IIUC this patches
> > > dies?) is not a good idea.
> >
> > Well, I'm thinking that at least on some platforms, such as the Jetson
> > Xavier NX, unless a different solution can be found, we need the RBU
> > interrupt to fire off a reset of the stmmac IP when this happens to
> > reduce the PAUSE frame flood on the network.
> >
> > If we can't do that, then I think stmmac on these platforms needs to be
> > marked with CONFIG_BROKEN because right now there doesn't seem to be any
> > other viable solution.
> >
> > My intention with this patch is merely to start collecting the already
> > existing statistics so other users can start seeing whether they are
> > hitting the same or similar problem. If we're not prepared to do that,
> > then we should delete the useless statistics from ethtool -S, but I
> > suspect they're now part of the UAPI, even though without this patch
> > they will remain stedfastly stuck at zero.
>
> Understood, thanks for the extra context. And the statistic we are
> talking about is rx_buf_unav_irq ?
Yes, correct.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH v4 0/8] perf libunwind multiple remote support
From: Ian Rogers @ 2026-04-13 21:01 UTC (permalink / raw)
To: acme
Cc: 9erthalion6, adrian.hunter, alex, alexander.shishkin,
andrew.jones, aou, atrajeev, blakejones, ctshao, dapeng1.mi,
howardchu95, james.clark, john.g.garry, jolsa, leo.yan,
libunwind-devel, linux-arm-kernel, linux-kernel, linux-perf-users,
linux-riscv, mingo, namhyung, palmer, peterz, pjw, shimin.guo,
tglozar, tmricht, will, yuzhuo
In-Reply-To: <20260413024805.1316480-1-irogers@google.com>
On Sun, Apr 12, 2026 at 7:48 PM Ian Rogers <irogers@google.com> wrote:
>
> Fix the libunwind build for when libdw and libunwind are feature
> detected, currently failing with a duplicate symbol.
>
> Refactor the libunwind support so that whenever a remote target is
> available, perf functions using the ELF machine can use that remote
> target regardless of what the host/local machine is. Migrate existing
> libunwind supported architectures like powerpc, arm64 and loongarch so
> that they can work in a cross-architecture way. Add support for
> RISC-V. Make the code more regular in function names, etc. and avoid
> including a C-file. This increases the lines of code. It is similar in
> style to the unwind-libdw implementation. It is hoped that the more
> uniform nature of the code with help with refactoring the perf
> registers for SIMD/APX support.
>
> Aside from local host testing these patches are under tested, in part
> as I'm failing to see how to build libunwind with support for multiple
> remote targets. Please could I get help in testing.
Hmm.. these were reposted in part for Sashiko reviews but that has failed:
https://sashiko.dev/#/log/baseline/9180/2
```
Trying baseline: perf-tools-next/perf-tools-next
(4e03d6494f9504f8af46ba68a2a8b6877c196789)
Patch 9180/4 (ID: 24748) failed to apply.
Application failed.
```
While my local tree shows that I have perf-tools-next plus these 8
patches. I'll wait a while, rebase and repost.
Thanks,
Ian
> v4: Rebase, in particular the zalloc->calloc change conflicted.
>
> v3: Minor whitespace clean up and warn when a dynamic choice of libdw
> or libunwind is selected for unwinding and support is missing (Arnaldo).
> https://lore.kernel.org/lkml/20260404054032.1538095-1-irogers@google.com/
>
> v2: Move two fixes patches to position 1 and 2 in the series. Fix
> struct naming inconsistency, Andrew Jones
> <andrew.jones@oss.qualcomm.com>. Fix other inconsistencies and
> potential non-x86 build issues.
> https://lore.kernel.org/lkml/20260305221927.3237145-1-irogers@google.com/
>
> v1: https://lore.kernel.org/lkml/20260224142938.26088-1-irogers@google.com/
>
> Ian Rogers (8):
> perf unwind: Refactor get_entries to allow dynamic libdw/libunwind
> selection
> perf build loongarch: Remove reference to missing file
> tools build: Deduplicate test-libunwind for different architectures
> perf build: Be more programmatic when setting up libunwind variables
> perf unwind-libunwind: Make libunwind register reading cross platform
> perf unwind-libunwind: Move flush/finish access out of local
> perf unwind-libunwind: Remove libunwind-local
> perf unwind-libunwind: Add RISC-V libunwind support
>
> tools/build/feature/Makefile | 38 +-
> tools/build/feature/test-libunwind-aarch64.c | 27 -
> tools/build/feature/test-libunwind-arm.c | 28 -
> .../test-libunwind-debug-frame-aarch64.c | 17 -
> .../feature/test-libunwind-debug-frame-arm.c | 17 -
> .../feature/test-libunwind-debug-frame.c | 1 -
> tools/build/feature/test-libunwind-x86.c | 28 -
> tools/build/feature/test-libunwind-x86_64.c | 28 -
> tools/build/feature/test-libunwind.c | 1 -
> tools/perf/Makefile.config | 215 ++---
> tools/perf/arch/arm/util/Build | 2 -
> tools/perf/arch/arm/util/unwind-libunwind.c | 50 --
> tools/perf/arch/arm64/util/Build | 1 -
> tools/perf/arch/arm64/util/unwind-libunwind.c | 17 -
> tools/perf/arch/loongarch/util/Build | 3 -
> .../arch/loongarch/util/unwind-libunwind.c | 82 --
> tools/perf/arch/mips/Build | 1 -
> tools/perf/arch/mips/util/Build | 1 -
> tools/perf/arch/mips/util/unwind-libunwind.c | 22 -
> tools/perf/arch/powerpc/util/Build | 1 -
> .../perf/arch/powerpc/util/unwind-libunwind.c | 92 --
> tools/perf/arch/x86/util/Build | 3 -
> tools/perf/arch/x86/util/unwind-libunwind.c | 115 ---
> tools/perf/builtin-inject.c | 4 +
> tools/perf/builtin-report.c | 4 +
> tools/perf/builtin-script.c | 4 +
> tools/perf/util/Build | 5 +-
> tools/perf/util/libunwind-arch/Build | 11 +
> .../perf/util/libunwind-arch/libunwind-arch.c | 319 +++++++
> .../perf/util/libunwind-arch/libunwind-arch.h | 296 +++++++
> .../perf/util/libunwind-arch/libunwind-arm.c | 290 ++++++
> .../util/libunwind-arch/libunwind-arm64.c | 289 ++++++
> .../perf/util/libunwind-arch/libunwind-i386.c | 312 +++++++
> .../util/libunwind-arch/libunwind-loongarch.c | 297 +++++++
> .../perf/util/libunwind-arch/libunwind-mips.c | 299 +++++++
> .../util/libunwind-arch/libunwind-ppc32.c | 301 +++++++
> .../util/libunwind-arch/libunwind-ppc64.c | 303 +++++++
> .../util/libunwind-arch/libunwind-riscv.c | 297 +++++++
> .../perf/util/libunwind-arch/libunwind-s390.c | 299 +++++++
> .../util/libunwind-arch/libunwind-x86_64.c | 320 +++++++
> tools/perf/util/libunwind/arm64.c | 40 -
> tools/perf/util/libunwind/x86_32.c | 41 -
> tools/perf/util/maps.c | 29 +-
> tools/perf/util/maps.h | 4 +-
> tools/perf/util/symbol_conf.h | 10 +
> tools/perf/util/thread.c | 29 +-
> tools/perf/util/unwind-libdw.c | 2 +-
> tools/perf/util/unwind-libunwind-local.c | 831 ------------------
> tools/perf/util/unwind-libunwind.c | 679 ++++++++++++--
> tools/perf/util/unwind.c | 98 +++
> tools/perf/util/unwind.h | 77 +-
> 51 files changed, 4549 insertions(+), 1731 deletions(-)
> delete mode 100644 tools/build/feature/test-libunwind-aarch64.c
> delete mode 100644 tools/build/feature/test-libunwind-arm.c
> delete mode 100644 tools/build/feature/test-libunwind-debug-frame-aarch64.c
> delete mode 100644 tools/build/feature/test-libunwind-debug-frame-arm.c
> delete mode 100644 tools/build/feature/test-libunwind-x86.c
> delete mode 100644 tools/build/feature/test-libunwind-x86_64.c
> delete mode 100644 tools/perf/arch/arm/util/unwind-libunwind.c
> delete mode 100644 tools/perf/arch/arm64/util/unwind-libunwind.c
> delete mode 100644 tools/perf/arch/loongarch/util/unwind-libunwind.c
> delete mode 100644 tools/perf/arch/mips/Build
> delete mode 100644 tools/perf/arch/mips/util/Build
> delete mode 100644 tools/perf/arch/mips/util/unwind-libunwind.c
> delete mode 100644 tools/perf/arch/powerpc/util/unwind-libunwind.c
> delete mode 100644 tools/perf/arch/x86/util/unwind-libunwind.c
> create mode 100644 tools/perf/util/libunwind-arch/Build
> create mode 100644 tools/perf/util/libunwind-arch/libunwind-arch.c
> create mode 100644 tools/perf/util/libunwind-arch/libunwind-arch.h
> create mode 100644 tools/perf/util/libunwind-arch/libunwind-arm.c
> create mode 100644 tools/perf/util/libunwind-arch/libunwind-arm64.c
> create mode 100644 tools/perf/util/libunwind-arch/libunwind-i386.c
> create mode 100644 tools/perf/util/libunwind-arch/libunwind-loongarch.c
> create mode 100644 tools/perf/util/libunwind-arch/libunwind-mips.c
> create mode 100644 tools/perf/util/libunwind-arch/libunwind-ppc32.c
> create mode 100644 tools/perf/util/libunwind-arch/libunwind-ppc64.c
> create mode 100644 tools/perf/util/libunwind-arch/libunwind-riscv.c
> create mode 100644 tools/perf/util/libunwind-arch/libunwind-s390.c
> create mode 100644 tools/perf/util/libunwind-arch/libunwind-x86_64.c
> delete mode 100644 tools/perf/util/libunwind/arm64.c
> delete mode 100644 tools/perf/util/libunwind/x86_32.c
> delete mode 100644 tools/perf/util/unwind-libunwind-local.c
> create mode 100644 tools/perf/util/unwind.c
>
> --
> 2.53.0.1213.gd9a14994de-goog
>
^ permalink raw reply
* Re: [PATCH v2 3/4] KVM: arm64: sefltests: Add basic NV selftest
From: Itaru Kitayama @ 2026-04-13 21:31 UTC (permalink / raw)
To: Wei-Lin Chang
Cc: linux-arm-kernel, kvmarm, kvm, linux-kselftest, linux-kernel,
Marc Zyngier, Oliver Upton, Joey Gouly, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, Will Deacon, Paolo Bonzini,
Shuah Khan
In-Reply-To: <ddr6exocupk6mzshjwvu6sqt57aeqiyxqss3rpgcxxyh54cw4g@rxvm5zh3ybrw>
On Mon, Apr 13, 2026 at 10:18:42AM +0100, Wei-Lin Chang wrote:
> Hi Itaru,
>
> On Mon, Apr 13, 2026 at 08:19:25AM +0900, Itaru Kitayama wrote:
> > On Sun, Apr 12, 2026 at 03:22:15PM +0100, Wei-Lin Chang wrote:
> > > This selftest simply starts an L1, which starts its own guest (L2). L2
> > > runs without stage-1 and 2 translations, it calls an HVC to jump back
> > > to L1.
> >
> > How do you disable both the nested guest (L2)'s MMU and stage 2
> > translations?
>
> Guest stage-2 is disabled by not setting HCR_EL2.VM in prepare_hyp(),
> and stage-1 is disabled by not writing to SCTLR_EL12 in init_vcpu(),
> effectively using the default value set by L0. However since SCTLR_EL1
> has many architecturally UNKNOWN bits (including SCTLR_EL1.M), it should
> be better to write a value before running L2 I suppose...
Thanks. What do you think of using copy_el2_to_el1() macro in at.c, so we
can prepare in guest_code() to manipulate the SCTLR_EL12 System register
with the sensible programmed values?
Itaru.
>
> Thanks,
> Wei-Lin Chang
>
> >
> > Itaru.
> >
> > >
> > > Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>
> > > ---
> > > tools/testing/selftests/kvm/Makefile.kvm | 1 +
> > > .../selftests/kvm/arm64/hello_nested.c | 103 ++++++++++++++++++
> > > 2 files changed, 104 insertions(+)
> > > create mode 100644 tools/testing/selftests/kvm/arm64/hello_nested.c
> > >
> > > diff --git a/tools/testing/selftests/kvm/Makefile.kvm b/tools/testing/selftests/kvm/Makefile.kvm
> > > index 3dc3e39f7025..e8c108e0c487 100644
> > > --- a/tools/testing/selftests/kvm/Makefile.kvm
> > > +++ b/tools/testing/selftests/kvm/Makefile.kvm
> > > @@ -168,6 +168,7 @@ TEST_GEN_PROGS_arm64 += arm64/arch_timer_edge_cases
> > > TEST_GEN_PROGS_arm64 += arm64/at
> > > TEST_GEN_PROGS_arm64 += arm64/debug-exceptions
> > > TEST_GEN_PROGS_arm64 += arm64/hello_el2
> > > +TEST_GEN_PROGS_arm64 += arm64/hello_nested
> > > TEST_GEN_PROGS_arm64 += arm64/host_sve
> > > TEST_GEN_PROGS_arm64 += arm64/hypercalls
> > > TEST_GEN_PROGS_arm64 += arm64/external_aborts
> > > diff --git a/tools/testing/selftests/kvm/arm64/hello_nested.c b/tools/testing/selftests/kvm/arm64/hello_nested.c
> > > new file mode 100644
> > > index 000000000000..97387e4697b3
> > > --- /dev/null
> > > +++ b/tools/testing/selftests/kvm/arm64/hello_nested.c
> > > @@ -0,0 +1,103 @@
> > > +// SPDX-License-Identifier: GPL-2.0-only
> > > +/*
> > > + * hello_nested - Go from vEL2 to EL1 then back
> > > + */
> > > +
> > > +#include "nested.h"
> > > +#include "processor.h"
> > > +#include "test_util.h"
> > > +#include "ucall.h"
> > > +
> > > +#define XLATE2GPA (0xABCD)
> > > +#define L2STACKSZ (0x100)
> > > +
> > > +/*
> > > + * TPIDR_EL2 is used to store vcpu id, so save and restore it.
> > > + */
> > > +static vm_paddr_t ucall_translate_to_gpa(void *gva)
> > > +{
> > > + vm_paddr_t gpa;
> > > + u64 vcpu_id = read_sysreg(tpidr_el2);
> > > +
> > > + GUEST_SYNC2(XLATE2GPA, gva);
> > > +
> > > + /* get the result from userspace */
> > > + gpa = read_sysreg(tpidr_el2);
> > > +
> > > + write_sysreg(vcpu_id, tpidr_el2);
> > > +
> > > + return gpa;
> > > +}
> > > +
> > > +static void l2_guest_code(void)
> > > +{
> > > + do_hvc();
> > > +}
> > > +
> > > +static void guest_code(void)
> > > +{
> > > + struct vcpu vcpu;
> > > + struct hyp_data hyp_data;
> > > + int ret;
> > > + vm_paddr_t l2_pc, l2_stack_top;
> > > + /* force 16-byte alignment for the stack pointer */
> > > + u8 l2_stack[L2STACKSZ] __attribute__((aligned(16)));
> > > +
> > > + GUEST_ASSERT_EQ(get_current_el(), 2);
> > > + GUEST_PRINTF("vEL2 entry\n");
> > > +
> > > + l2_pc = ucall_translate_to_gpa(l2_guest_code);
> > > + l2_stack_top = ucall_translate_to_gpa(&l2_stack[L2STACKSZ]);
> > > +
> > > + init_vcpu(&vcpu, l2_pc, l2_stack_top);
> > > + prepare_hyp();
> > > +
> > > + ret = run_l2(&vcpu, &hyp_data);
> > > + GUEST_ASSERT_EQ(ret, ARM_EXCEPTION_TRAP);
> > > + GUEST_DONE();
> > > +}
> > > +
> > > +int main(void)
> > > +{
> > > + struct kvm_vcpu_init init;
> > > + struct kvm_vcpu *vcpu;
> > > + struct kvm_vm *vm;
> > > + struct ucall uc;
> > > + vm_paddr_t gpa;
> > > +
> > > + TEST_REQUIRE(kvm_check_cap(KVM_CAP_ARM_EL2));
> > > + vm = vm_create(1);
> > > +
> > > + kvm_get_default_vcpu_target(vm, &init);
> > > + init.features[0] |= BIT(KVM_ARM_VCPU_HAS_EL2);
> > > + vcpu = aarch64_vcpu_add(vm, 0, &init, guest_code);
> > > + kvm_arch_vm_finalize_vcpus(vm);
> > > +
> > > + while (true) {
> > > + vcpu_run(vcpu);
> > > +
> > > + switch (get_ucall(vcpu, &uc)) {
> > > + case UCALL_SYNC:
> > > + if (uc.args[0] == XLATE2GPA) {
> > > + gpa = addr_gva2gpa(vm, (vm_vaddr_t)uc.args[1]);
> > > + vcpu_set_reg(vcpu, KVM_ARM64_SYS_REG(SYS_TPIDR_EL2), gpa);
> > > + }
> > > + break;
> > > + case UCALL_PRINTF:
> > > + pr_info("%s", uc.buffer);
> > > + break;
> > > + case UCALL_DONE:
> > > + pr_info("DONE!\n");
> > > + goto end;
> > > + case UCALL_ABORT:
> > > + REPORT_GUEST_ASSERT(uc);
> > > + fallthrough;
> > > + default:
> > > + TEST_FAIL("Unhandled ucall: %ld\n", uc.cmd);
> > > + }
> > > + }
> > > +
> > > +end:
> > > + kvm_vm_free(vm);
> > > + return 0;
> > > +}
> > > --
> > > 2.43.0
> > >
^ permalink raw reply
* [PATCH] arm64: dts: rockchip: Enable the NPU on rk3588-rock-5-itx
From: Sten-Silver Ots @ 2026-04-13 21:52 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: Sten-Silver Ots, FUKAUMI Naoki, Torsten Duwe, Dmitry Baryshkov,
Andy Yan, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
This commit enables the NPU on Radxa Rock 5 ITX board.
The regulator vdd_npu_s0 was already in place and since the NPUs
power domain supply is now described remove the always-on property
from the regulator.
Signed-off-by: Sten-Silver Ots <stensilver@gmail.com>
---
.../boot/dts/rockchip/rk3588-rock-5-itx.dts | 35 ++++++++++++++++++-
1 file changed, 34 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-rock-5-itx.dts b/arch/arm64/boot/dts/rockchip/rk3588-rock-5-itx.dts
index de154adb1497..d3ab6c68a60b 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-rock-5-itx.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588-rock-5-itx.dts
@@ -421,7 +421,6 @@ vdd_npu_s0: regulator@42 {
reg = <0x42>;
fcs,suspend-voltage-selector = <1>;
regulator-name = "vdd_npu_s0";
- regulator-always-on;
regulator-boot-on;
regulator-min-microvolt = <550000>;
regulator-max-microvolt = <950000>;
@@ -683,6 +682,10 @@ &pd_gpu {
domain-supply = <&vdd_gpu_s0>;
};
+&pd_npu {
+ domain-supply = <&vdd_npu_s0>;
+};
+
&pinctrl {
hym8563 {
rtc_int: rtc-int {
@@ -802,6 +805,36 @@ dp1_hpd: dp1-hpd {
};
};
+&rknn_core_0 {
+ npu-supply = <&vdd_npu_s0>;
+ sram-supply = <&vdd_npu_s0>;
+ status = "okay";
+};
+
+&rknn_core_1 {
+ npu-supply = <&vdd_npu_s0>;
+ sram-supply = <&vdd_npu_s0>;
+ status = "okay";
+};
+
+&rknn_core_2 {
+ npu-supply = <&vdd_npu_s0>;
+ sram-supply = <&vdd_npu_s0>;
+ status = "okay";
+};
+
+&rknn_mmu_0 {
+ status = "okay";
+};
+
+&rknn_mmu_1 {
+ status = "okay";
+};
+
+&rknn_mmu_2 {
+ status = "okay";
+};
+
&pwm14 {
pinctrl-names = "default";
pinctrl-0 = <&pwm14m1_pins>;
--
2.53.0
^ permalink raw reply related
* Re: [PATCH net-next] net: stmmac: enable RPS and RBU interrupts
From: Sam Edwards @ 2026-04-13 21:54 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Jakub Kicinski, Andrew Lunn, Alexandre Torgue, Andrew Lunn,
David S. Miller, Eric Dumazet,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
linux-stm32, Linux Network Development Mailing List, Paolo Abeni
In-Reply-To: <ad06yiZZbLC9k3jY@shell.armlinux.org.uk>
On Mon, Apr 13, 2026, 11:49 Russell King (Oracle) <linux@armlinux.org.uk> wrote:
>
> On Mon, Apr 13, 2026 at 11:02:22AM -0700, Jakub Kicinski wrote:
> > On Fri, 10 Apr 2026 14:07:51 +0100 Russell King (Oracle) wrote:
> > > Since we are seeing receive buffer exhaustion on several platforms,
> > > let's enable the interrupts so the statistics we publish via ethtool -S
> > > actually work to aid diagnosis. I've been in two minds about whether
> > > to send this patch, but given the problems with stmmac at the moment,
> > > I think it should be merged.
> >
> > Sorry for a under-research response but wasn't there are person trying
> > to fix the OOM starvation issue? Who was supposed to add a timer?
> > Is your problem also OOM related or do you suspect something else?
>
> It is not OOM related. I have this patch applied:
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index 131ea887bedc..614d0e10e3e6 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -5095,14 +5095,18 @@ static inline void stmmac_rx_refill(struct stmmac_priv *priv, u32 queue)
>
> if (!buf->page) {
> buf->page = page_pool_alloc_pages(rx_q->page_pool, gfp);
> - if (!buf->page)
> + if (!buf->page) {
> + netdev_err(priv->dev, "q%u: no buffer 1\n", queue);
> break;
> + }
> }
>
> if (priv->sph_active && !buf->sec_page) {
> buf->sec_page = page_pool_alloc_pages(rx_q->page_pool, gfp);
> - if (!buf->sec_page)
> + if (!buf->sec_page) {
> + netdev_err(priv->dev, "q%u: no buffer 2\n", queue);
> break;
> + }
>
> buf->sec_addr = page_pool_get_dma_addr(buf->sec_page);
> }
>
> and it is silent, so we are not suffering starvation of buffers.
>
> However, the hardware hangs during iperf3, and because it triggers the
> MAC to stream PAUSE frames, and my network uses Netgear GS108 and GS116
> unmanaged switches that always use flow-control between them (there's no
> way not to) it takes down the entire network - as we've discussed
> before. So, this problem is pretty fatal to the *entire* network.
>
> With this patch, the existing statistical counters for this condition
> are incremented, and thus users can use ethtool -S to see what happened
> and report whether they are seeing the same issue.
>
> Without this patch applied, there are no diagnostics from stmmac that
> report what the state is. ethtool -d doesn't list the appropriate
> registers (as I suspect part of the problem is the number of queues
> is somewhat dynamic - userspace can change that configuration through
> ethtool).
>
> Thus, one has to resort to using devmem2 to find out what's happened.
> That's not user friendly.
>
> For me, devmem2 shows:
>
> Channel 0 status register:
> Value at address 0x02491160: 0x00000484
> bit 10: ETI early transmit interrupt - set
> bit 9 : RWT receive watchdog - clear
> bit 8 : RPS receieve process stopped - clear
> bit 7 : RBU receive buffer unavailable - set
> bit 6 : RI receive interrupt - clear
> bit 2 : TBU transmit buffer unavailable - set
> bit 1 : TPS transmit process stopped - clear
> bit 0 : TI transmit interrupt - clear
>
> Debug status register:
> Value at address 0x0249100c: 0x00006300
> TPS[3:0] = 6 = Suspended, Tx descriptor unavailable or Tx buffer
> underflow
> RPS[3:0] = 3 = Running, waiting for Rx packet
>
> Metal Queue 0 debug register:
> Value at address 0x02490d38: 0x002e0020
> PRXQ[13:0] = 0x2e = 46 packets in receive queue
> RXQSTS[1:0] = 2 = Rx queue fill-level above flow-control activate
> threshold
> RRCSTS[1:0] = 0 = Rx Queue Read Controller State = Idle
>
> > Firing interrupts when Rx fill ring runs dry (which IIUC this patches
> > dies?) is not a good idea.
>
> Well, I'm thinking that at least on some platforms, such as the Jetson
> Xavier NX, unless a different solution can be found, we need the RBU
> interrupt to fire off a reset of the stmmac IP when this happens to
> reduce the PAUSE frame flood on the network.
Hi Russell,
Should that reset trigger be RPS, not RBU? My understanding of these
status bits is RBU is just "RxDMA has failed to take a frame from the
RxFIFO" while RPS is "the RxFIFO is full." That would make RBU our
critical threshold to start proactively refilling, and RPS the "too
late, we lose" threshold.
Thinking aloud: Do you suppose the RxDMA waits for a wakeup signal
sent whenever a frame is added to RxFIFO? That might explain why the
former never recovers once the latter is full: a manual wakeup needs
to be sent whenever we resolve RBU. Does the .enable_dma_reception()
op need to be implemented for dwmac5, or have you tried that already?
>
> If we can't do that, then I think stmmac on these platforms needs to be
> marked with CONFIG_BROKEN because right now there doesn't seem to be any
> other viable solution.
>
> My intention with this patch is merely to start collecting the already
> existing statistics so other users can start seeing whether they are
> hitting the same or similar problem. If we're not prepared to do that,
> then we should delete the useless statistics from ethtool -S, but I
> suspect they're now part of the UAPI, even though without this patch
> they will remain stedfastly stuck at zero.
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH net-next] net: stmmac: enable RPS and RBU interrupts
From: patchwork-bot+netdevbpf @ 2026-04-13 22:00 UTC (permalink / raw)
To: Russell King
Cc: andrew, alexandre.torgue, andrew+netdev, davem, edumazet, kuba,
linux-arm-kernel, linux-stm32, netdev, pabeni, cfsworks
In-Reply-To: <E1wBBaR-0000000GZHR-1dbM@rmk-PC.armlinux.org.uk>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Fri, 10 Apr 2026 14:07:51 +0100 you wrote:
> Enable receive process stopped and receive buffer unavailable
> interrupts, so that the statistic counters can be updated.
>
> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
> ---
> Since we are seeing receive buffer exhaustion on several platforms,
> let's enable the interrupts so the statistics we publish via ethtool -S
> actually work to aid diagnosis. I've been in two minds about whether
> to send this patch, but given the problems with stmmac at the moment,
> I think it should be merged.
>
> [...]
Here is the summary with links:
- [net-next] net: stmmac: enable RPS and RBU interrupts
https://git.kernel.org/netdev/net-next/c/1b9707e6f1a9
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v2 1/7] dt-bindings: soc: move,rename google,gs101-pmu-intr-gen and add exynos850
From: Rob Herring (Arm) @ 2026-04-13 22:11 UTC (permalink / raw)
To: Alexey Klimov
Cc: linux-arm-kernel, linux-samsung-soc, Krzysztof Kozlowski,
devicetree, linux-kernel, Sam Protsenko, André Draszik,
Alim Akhtar, Peter Griffin, Tudor Ambarus, Krzysztof Kozlowski,
Conor Dooley
In-Reply-To: <20260401-exynos850-cpuhotplug-v2-1-c5a760a3e259@linaro.org>
On Wed, 01 Apr 2026 05:51:54 +0100, Alexey Klimov wrote:
> The PMU interrupt generation block introduced for the Google GS101 is
> actually a standard Samsung Exynos IP block found in older SoCs, such
> as the Exynos850, and is not exclusive to Google SoCs. To accurately
> reflect its origin, move the schema file to under soc/samsung/
> directory and rename it.
> Concurrently, add the new "samsung,exynos850-pmu-intr-gen" compatible
> string to the bindings. Support for this block is required to enable
> power management features like CPU hotplug and idle states on Exynos850
> platforms.
> Also, move this file under Exynos850 SoC in MAINTAINERS entry.
>
> Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
> ---
> .../samsung,exynos850-pmu-intr-gen.yaml} | 8 +++++---
> MAINTAINERS | 2 +-
> 2 files changed, 6 insertions(+), 4 deletions(-)
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 2/7] dt-bindings: soc: samsung: exynos-pmu: add samsung,pmu-intr-gen phandle
From: Rob Herring @ 2026-04-13 22:16 UTC (permalink / raw)
To: Alexey Klimov
Cc: Sam Protsenko, linux-samsung-soc, Krzysztof Kozlowski,
Peter Griffin, André Draszik, Conor Dooley, Alim Akhtar,
Tudor Ambarus, Krzysztof Kozlowski, linux-arm-kernel, devicetree,
linux-kernel
In-Reply-To: <20260401-exynos850-cpuhotplug-v2-2-c5a760a3e259@linaro.org>
On Wed, Apr 01, 2026 at 05:51:55AM +0100, Alexey Klimov wrote:
> Some Exynos-based SoCs, for instance Exynos850, require access
> to the pmu interrupt generation register region which is exposed
> as a syscon. Update the exynos-pmu bindings documentation to
> reflect this.
>
> Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
> ---
> .../devicetree/bindings/soc/samsung/exynos-pmu.yaml | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml b/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml
> index 76ce7e98c10f..92acdfd5d44e 100644
> --- a/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml
> +++ b/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml
> @@ -110,6 +110,11 @@ properties:
> description:
> Node for reboot method
>
> + samsung,pmu-intr-gen-syscon:
> + $ref: /schemas/types.yaml#/definitions/phandle
> + description:
> + Phandle to PMU interrupt generation interface.
> +
> google,pmu-intr-gen-syscon:
Does this mean the driver is just going to have to look at both
properties for the same thing? If so, just use the existing property. We
don't need 2. Yeah, 'google' in Samsung SoCs is a bit weird, but that's
Samsung's fault for not upstreaming support for their h/w first.
Rob
^ permalink raw reply
* Re: [PATCH RFC bpf-next 1/8] kasan: expose generic kasan helpers
From: Andrey Konovalov @ 2026-04-13 22:19 UTC (permalink / raw)
To: Alexis Lothoré (eBPF Foundation)
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Kumar Kartikeya Dwivedi,
Song Liu, Yonghong Song, Jiri Olsa, John Fastabend,
David S. Miller, David Ahern, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, Shuah Khan,
Maxime Coquelin, Alexandre Torgue, Andrey Ryabinin,
Alexander Potapenko, Dmitry Vyukov, Vincenzo Frascino,
Andrew Morton, ebpf, Bastien Curutchet, Thomas Petazzoni,
Xu Kuohai, bpf, linux-kernel, netdev, linux-kselftest,
linux-stm32, linux-arm-kernel, kasan-dev, linux-mm
In-Reply-To: <20260413-kasan-v1-1-1a5831230821@bootlin.com>
On Mon, Apr 13, 2026 at 8:29 PM Alexis Lothoré (eBPF Foundation)
<alexis.lothore@bootlin.com> wrote:
>
> In order to prepare KASAN helpers to be called from the eBPF subsystem
> (to add KASAN instrumentation at runtime when JITing eBPF programs),
> expose the __asan_{load,store}X functions in linux/kasan.h
>
> Signed-off-by: Alexis Lothoré (eBPF Foundation) <alexis.lothore@bootlin.com>
> ---
> include/linux/kasan.h | 13 +++++++++++++
> mm/kasan/kasan.h | 10 ----------
> 2 files changed, 13 insertions(+), 10 deletions(-)
>
> diff --git a/include/linux/kasan.h b/include/linux/kasan.h
> index 338a1921a50a..6f580d4a39e4 100644
> --- a/include/linux/kasan.h
> +++ b/include/linux/kasan.h
> @@ -710,4 +710,17 @@ void kasan_non_canonical_hook(unsigned long addr);
> static inline void kasan_non_canonical_hook(unsigned long addr) { }
> #endif /* CONFIG_KASAN_GENERIC || CONFIG_KASAN_SW_TAGS */
>
> +#ifdef CONFIG_KASAN_GENERIC
> +void __asan_load1(void *p);
> +void __asan_store1(void *p);
> +void __asan_load2(void *p);
> +void __asan_store2(void *p);
> +void __asan_load4(void *p);
> +void __asan_store4(void *p);
> +void __asan_load8(void *p);
> +void __asan_store8(void *p);
> +void __asan_load16(void *p);
> +void __asan_store16(void *p);
> +#endif /* CONFIG_KASAN_GENERIC */
This looks ugly, let's not do this unless it's really required.
You can just use kasan_check_read/write() instead - these are public
wrappers around the same shadow memory checking functions. And they
also work with the SW_TAGS mode, in case the BPF would want to use
that mode at some point. (For HW_TAGS, we only have kasan_check_byte()
that checks a single byte, but it can be extended in the future if
required to be used by BPF.)
> +
> #endif /* LINUX_KASAN_H */
> diff --git a/mm/kasan/kasan.h b/mm/kasan/kasan.h
> index fc9169a54766..3bfce8eb3135 100644
> --- a/mm/kasan/kasan.h
> +++ b/mm/kasan/kasan.h
> @@ -594,16 +594,6 @@ void __asan_handle_no_return(void);
> void __asan_alloca_poison(void *, ssize_t size);
> void __asan_allocas_unpoison(void *stack_top, ssize_t stack_bottom);
>
> -void __asan_load1(void *);
> -void __asan_store1(void *);
> -void __asan_load2(void *);
> -void __asan_store2(void *);
> -void __asan_load4(void *);
> -void __asan_store4(void *);
> -void __asan_load8(void *);
> -void __asan_store8(void *);
> -void __asan_load16(void *);
> -void __asan_store16(void *);
> void __asan_loadN(void *, ssize_t size);
> void __asan_storeN(void *, ssize_t size);
>
>
> --
> 2.53.0
>
^ permalink raw reply
* Re: [PATCH RFC bpf-next 3/8] bpf: add BPF_JIT_KASAN for KASAN instrumentation of JITed programs
From: Andrey Konovalov @ 2026-04-13 22:20 UTC (permalink / raw)
To: Alexis Lothoré (eBPF Foundation)
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Kumar Kartikeya Dwivedi,
Song Liu, Yonghong Song, Jiri Olsa, John Fastabend,
David S. Miller, David Ahern, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, Shuah Khan,
Maxime Coquelin, Alexandre Torgue, Andrey Ryabinin,
Alexander Potapenko, Dmitry Vyukov, Vincenzo Frascino,
Andrew Morton, ebpf, Bastien Curutchet, Thomas Petazzoni,
Xu Kuohai, bpf, linux-kernel, netdev, linux-kselftest,
linux-stm32, linux-arm-kernel, kasan-dev, linux-mm
In-Reply-To: <20260413-kasan-v1-3-1a5831230821@bootlin.com>
On Mon, Apr 13, 2026 at 8:29 PM Alexis Lothoré (eBPF Foundation)
<alexis.lothore@bootlin.com> wrote:
>
> Add a new Kconfig option CONFIG_BPF_JIT_KASAN that automatically enables
> KASAN (Kernel Address Sanitizer) memory access checks for JIT-compiled
> BPF programs, when both KASAN and JIT compiler are enabled. When
> enabled, the JIT compiler will emit shadow memory checks before memory
> loads and stores to detect use-after-free, out-of-bounds, and other
> memory safety bugs at runtime. The option is gated behind
> HAVE_EBPF_JIT_KASAN, as it needs proper arch-specific implementation.
>
> Signed-off-by: Alexis Lothoré (eBPF Foundation) <alexis.lothore@bootlin.com>
> ---
> kernel/bpf/Kconfig | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/kernel/bpf/Kconfig b/kernel/bpf/Kconfig
> index eb3de35734f0..28392adb3d7e 100644
> --- a/kernel/bpf/Kconfig
> +++ b/kernel/bpf/Kconfig
> @@ -17,6 +17,10 @@ config HAVE_CBPF_JIT
> config HAVE_EBPF_JIT
> bool
>
> +# KASAN support for JIT compiler
> +config HAVE_EBPF_JIT_KASAN
> + bool
> +
> # Used by archs to tell that they want the BPF JIT compiler enabled by
> # default for kernels that were compiled with BPF JIT support.
> config ARCH_WANT_DEFAULT_BPF_JIT
> @@ -101,4 +105,9 @@ config BPF_LSM
>
> If you are unsure how to answer this question, answer N.
>
> +config BPF_JIT_KASAN
> + bool
> + depends on HAVE_EBPF_JIT_KASAN
> + default y if BPF_JIT && KASAN_GENERIC
Should this be "depends on KASAN && KASAN_GENERIC"?
> +
> endmenu # "BPF subsystem"
>
> --
> 2.53.0
>
^ permalink raw reply
* Re: [PATCH RFC bpf-next 8/8] selftests/bpf: add tests to validate KASAN on JIT programs
From: Andrey Konovalov @ 2026-04-13 22:20 UTC (permalink / raw)
To: Alexis Lothoré (eBPF Foundation)
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Kumar Kartikeya Dwivedi,
Song Liu, Yonghong Song, Jiri Olsa, John Fastabend,
David S. Miller, David Ahern, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, Shuah Khan,
Maxime Coquelin, Alexandre Torgue, Andrey Ryabinin,
Alexander Potapenko, Dmitry Vyukov, Vincenzo Frascino,
Andrew Morton, ebpf, Bastien Curutchet, Thomas Petazzoni,
Xu Kuohai, bpf, linux-kernel, netdev, linux-kselftest,
linux-stm32, linux-arm-kernel, kasan-dev, linux-mm
In-Reply-To: <20260413-kasan-v1-8-1a5831230821@bootlin.com>
On Mon, Apr 13, 2026 at 8:29 PM Alexis Lothoré (eBPF Foundation)
<alexis.lothore@bootlin.com> wrote:
>
> Add a basic KASAN test runner that loads and test-run programs that can
> trigger memory management bugs. The test captures kernel logs and ensure
> that the expected KASAN splat is emitted by searching for the
> corresponding first lines in the report.
>
> This version implements two faulty programs triggering either a
> user-after-free, or an out-of-bounds memory usage. The bugs are
> triggered thanks to some dedicated kfuncs in bpf_testmod.c, but two
> different techniques are used, as some cases can be quite hard to
> trigger in a pure "black box" approach:
> - for reads, we can make the used kfuncs return some faulty pointers
> that ebpf programs will manipulate, they will generate legitimate
> kasan reports as a consequence
> - applying the same trick for faulty writes is harder, as ebpf programs
> can't write kernel data freely. So ebpf programs can call another
> specific testing kfunc that will alter the shadow memory matching the
> passed memory (eg: a map). When the program will try to write to the
> corresponding memory, it will trigger a report as well.
>
> Signed-off-by: Alexis Lothoré (eBPF Foundation) <alexis.lothore@bootlin.com>
> ---
> The way of bringing kasan_poison into bpf_testmod is definitely not
> ideal. But I would like to validate the testing approach (triggering
> real faulty accesses, which is hard on some cases, VS manually poisoning
> BPF-manipulated memory) before eventually making clean bridges between
> KASAN APIs and bpf_testmod.c, if the latter approach is the valid one.
Would it make sense to put these tests into KASAN KUnit tests in
mm/kasan/kasan_test_c.c? I assume there is a kernel API to JIT BPF
programs from the kernel itself?
There, you can just call kasan_poison(), some tests already do this.
And you can also extend the KASAN KUnit test framework to find out
whether the bad access is a read or write, if you want to check this.
> ---
> tools/testing/selftests/bpf/prog_tests/kasan.c | 165 +++++++++++++++++++++
> tools/testing/selftests/bpf/progs/kasan.c | 146 ++++++++++++++++++
> .../testing/selftests/bpf/test_kmods/bpf_testmod.c | 79 ++++++++++
> 3 files changed, 390 insertions(+)
>
> diff --git a/tools/testing/selftests/bpf/prog_tests/kasan.c b/tools/testing/selftests/bpf/prog_tests/kasan.c
> new file mode 100644
> index 000000000000..fd628aaa8005
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/prog_tests/kasan.c
> @@ -0,0 +1,165 @@
> +// SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
> +#include <bpf/bpf.h>
> +#include <fcntl.h>
> +#include <linux/if_ether.h>
> +#include <sys/klog.h>
> +#include <test_progs.h>
> +#include <unpriv_helpers.h>
> +#include "kasan.skel.h"
> +
> +#define SUBTEST_NAME_MAX_LEN 64
> +#define SYSLOG_ACTION_READ_ALL 3
> +#define SYSLOG_ACTION_CLEAR 5
> +
> +#define MAX_LOG_SIZE (8*1024)
> +#define READ_CHUNK_SIZE 128
> +
> +#define KASAN_PATTERN_SLAB_UAF "BUG: KASAN: slab-use-after-free in bpf_prog_"
> +#define KASAN_PATTERN_GLOBAL_OOB "BUG: KASAN: global-out-of-bounds in bpf_prog_"
> +
> +static char klog_buffer[MAX_LOG_SIZE];
> +
> +static int read_kernel_logs(char *buf, size_t max_len)
> +{
> + return klogctl(SYSLOG_ACTION_READ_ALL, buf, max_len);
> +}
> +
> +static int clear_kernel_logs(void)
> +{
> + return klogctl(SYSLOG_ACTION_CLEAR, NULL, 0);
> +}
> +
> +static int kernel_logs_have_matching_kasan_report(char *buf, char *pattern,
> + bool is_write, int size)
> +{
> + char *access_desc_start, *access_desc_end, *tmp;
> + char access_log[READ_CHUNK_SIZE];
> + char *kasan_report_start;
> + int hsize, nsize;
> + /* Searched kasan report is valid if
> + * - it contains the expected kasan pattern
> + * - the next line is the description of the faulty access
> + * - faulty access properties match the tested type and size
> + */
> + kasan_report_start = strstr(buf, pattern);
> +
> + if (!kasan_report_start)
> + return 1;
> +
> + /* Find next line */
> + access_desc_start = strchr(kasan_report_start, '\n');
> + if (!access_desc_start)
> + return 1;
> + access_desc_start++;
> +
> + access_desc_end = strchr(access_desc_start, '\n');
> + if (!access_desc_end)
> + return 1;
> +
> + nsize = snprintf(access_log, READ_CHUNK_SIZE, "%s of size %d at addr",
> + is_write ? "Write" : "Read", size);
> +
> + hsize = access_desc_end - access_desc_start;
> + tmp = memmem(access_desc_start, hsize, access_log, nsize);
> +
> + if (!tmp)
> + return 1;
> +
> + return 0;
> +}
> +
> +struct test_spec {
> + char *prog_name;
> + char *expected_report_pattern;
> +};
> +
> +static struct test_spec tests[] = {
> + {
> + .prog_name = "bpf_kasan_uaf",
> + .expected_report_pattern = KASAN_PATTERN_SLAB_UAF
> + },
> + {
> + .prog_name = "bpf_kasan_oob",
> + .expected_report_pattern = KASAN_PATTERN_GLOBAL_OOB
> + }
> +};
> +
> +static void run_test_with_type_and_size(struct kasan *skel,
> + struct test_spec *test, bool is_write,
> + int access_size)
> +{
> + char subtest_name[SUBTEST_NAME_MAX_LEN];
> + struct bpf_program *prog;
> + uint8_t buf[ETH_HLEN];
> + int ret;
> +
> + prog = bpf_object__find_program_by_name(skel->obj, test->prog_name);
> + if (!ASSERT_OK_PTR(prog, "find test prog"))
> + return;
> +
> + snprintf(subtest_name, SUBTEST_NAME_MAX_LEN, "%s_%s_%d",
> + test->prog_name, is_write ? "write" : "read", access_size);
> +
> + if (!test__start_subtest(subtest_name))
> + return;
> +
> + ret = clear_kernel_logs();
> + if (!ASSERT_OK(ret, "reset log buffer"))
> + return;
> +
> + LIBBPF_OPTS(bpf_test_run_opts, topts);
> + topts.sz = sizeof(struct bpf_test_run_opts);
> + topts.data_size_in = ETH_HLEN;
> + topts.data_in = buf;
> + skel->bss->is_write = is_write;
> + skel->bss->access_size = access_size;
> + ret = bpf_prog_test_run_opts(bpf_program__fd(prog), &topts);
> + if (!ASSERT_OK(ret, "run prog"))
> + return;
> +
> + ret = read_kernel_logs(klog_buffer, MAX_LOG_SIZE);
> + if (ASSERT_GE(ret, 0, "read kernel logs"))
> + ASSERT_OK(kernel_logs_have_matching_kasan_report(
> + klog_buffer, test->expected_report_pattern,
> + is_write, access_size),
> + test->prog_name);
> +}
> +
> +static void run_test_with_type(struct kasan *skel, struct test_spec *test,
> + bool is_write)
> +{
> + run_test_with_type_and_size(skel, test, is_write, 1);
> + run_test_with_type_and_size(skel, test, is_write, 2);
> + run_test_with_type_and_size(skel, test, is_write, 4);
> + run_test_with_type_and_size(skel, test, is_write, 8);
> +}
> +
> +static void run_test(struct kasan *skel, struct test_spec *test)
> +{
> + run_test_with_type(skel, test, false);
> + run_test_with_type(skel, test, true);
> +}
> +
> +void test_kasan(void)
> +{
> + struct test_spec *test;
> + struct kasan *skel;
> + int i;
> +
> + if (!is_jit_enabled() || !get_kasan_jit_enabled()) {
> + test__skip();
> + return;
> + }
> +
> + skel = kasan__open_and_load();
> + if (!ASSERT_OK_PTR(skel, "open and load prog"))
> + return;
> +
> + for (i = 0; i < ARRAY_SIZE(tests); i++) {
> + test = &tests[i];
> +
> + run_test(skel, test);
> + }
> +
> + kasan__destroy(skel);
> +}
> diff --git a/tools/testing/selftests/bpf/progs/kasan.c b/tools/testing/selftests/bpf/progs/kasan.c
> new file mode 100644
> index 000000000000..f713c9b7c9ce
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/progs/kasan.c
> @@ -0,0 +1,146 @@
> +// SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
> +
> +#include <linux/bpf.h>
> +#include <bpf/bpf_helpers.h>
> +#include <bpf/bpf_tracing.h>
> +
> +#define KASAN_SLAB_FREE 0xFB
> +#define KASAN_GLOBAL_REDZONE 0xF9
> +
> +extern __u8 *bpf_kfunc_kasan_uaf_1(void) __ksym;
> +extern __u16 *bpf_kfunc_kasan_uaf_2(void) __ksym;
> +extern __u32 *bpf_kfunc_kasan_uaf_4(void) __ksym;
> +extern __u64 *bpf_kfunc_kasan_uaf_8(void) __ksym;
> +extern __u8 *bpf_kfunc_kasan_oob_1(void) __ksym;
> +extern __u16 *bpf_kfunc_kasan_oob_2(void) __ksym;
> +extern __u32 *bpf_kfunc_kasan_oob_4(void) __ksym;
> +extern __u64 *bpf_kfunc_kasan_oob_8(void) __ksym;
> +extern void bpf_kfunc_kasan_poison(void *mem, __u32 mem__sz, __u8 byte) __ksym;
> +
> +int access_size;
> +int is_write;
> +
> +struct kasan_write_val {
> + __u8 data_1;
> + __u16 data_2;
> + __u32 data_4;
> + __u64 data_8;
> +};
> +
> +struct {
> + __uint(type, BPF_MAP_TYPE_ARRAY);
> + __uint(max_entries, 1);
> + __type(key, __u32);
> + __type(value, struct kasan_write_val);
> +} test_map SEC(".maps");
> +
> +static void bpf_kasan_faulty_write(int size, __u8 poison_byte)
> +{
> + struct kasan_write_val *val;
> + __u32 key = 0;
> +
> + val = bpf_map_lookup_elem(&test_map, &key);
> + if (!val)
> + return;
> +
> + bpf_kfunc_kasan_poison(val, sizeof(struct kasan_write_val),
> + poison_byte);
> + switch (size) {
> + case 1:
> + val->data_1 = 0xAA;
> + break;
> + case 2:
> + val->data_2 = 0xAA;
> + break;
> + case 4:
> + val->data_4 = 0xAA;
> + break;
> + case 8:
> + val->data_8 = 0xAA;
> + break;
> + }
> + bpf_kfunc_kasan_poison(val, sizeof(struct kasan_write_val), 0x00);
> +}
> +
> +
> +static int bpf_kasan_uaf_read(int size)
> +{
> + __u8 *result_1;
> + __u16 *result_2;
> + __u32 *result_4;
> + __u64 *result_8;
> + int ret = 0;
> +
> + switch (size) {
> + case 1:
> + result_1 = bpf_kfunc_kasan_uaf_1();
> + ret = result_1[0] ? 1 : 0;
> + break;
> + case 2:
> + result_2 = bpf_kfunc_kasan_uaf_2();
> + ret = result_2[0] ? 1 : 0;
> + break;
> + case 4:
> + result_4 = bpf_kfunc_kasan_uaf_4();
> + ret = result_4[0] ? 1 : 0;
> + break;
> + case 8:
> + result_8 = bpf_kfunc_kasan_uaf_8();
> + ret = result_8[0] ? 1 : 0;
> + break;
> + }
> + return ret;
> +}
> +
> +SEC("tcx/ingress")
> +int bpf_kasan_uaf(struct __sk_buff *skb)
> +{
> + if (is_write) {
> + bpf_kasan_faulty_write(access_size, KASAN_SLAB_FREE);
> + return 0;
> + }
> +
> + return bpf_kasan_uaf_read(access_size);
> +}
> +
> +static int bpf_kasan_oob_read(int size)
> +{
> + __u8 *result_1;
> + __u16 *result_2;
> + __u32 *result_4;
> + __u64 *result_8;
> + int ret = 0;
> +
> + switch (size) {
> + case 1:
> + result_1 = bpf_kfunc_kasan_oob_1();
> + ret = result_1[0] ? 1 : 0;
> + break;
> + case 2:
> + result_2 = bpf_kfunc_kasan_oob_2();
> + ret = result_2[0] ? 1 : 0;
> + break;
> + case 4:
> + result_4 = bpf_kfunc_kasan_oob_4();
> + ret = result_4[0] ? 1 : 0;
> + break;
> + case 8:
> + result_8 = bpf_kfunc_kasan_oob_8();
> + ret = result_8[0] ? 1 : 0;
> + break;
> + }
> + return ret;
> +}
> +
> +SEC("tcx/ingress")
> +int bpf_kasan_oob(struct __sk_buff *skb)
> +{
> + if (is_write) {
> + bpf_kasan_faulty_write(access_size, KASAN_GLOBAL_REDZONE);
> + return 0;
> + }
> +
> + return bpf_kasan_oob_read(access_size);
> +}
> +
> +char LICENSE[] SEC("license") = "GPL";
> diff --git a/tools/testing/selftests/bpf/test_kmods/bpf_testmod.c b/tools/testing/selftests/bpf/test_kmods/bpf_testmod.c
> index d876314a4d67..01554bcbbbb0 100644
> --- a/tools/testing/selftests/bpf/test_kmods/bpf_testmod.c
> +++ b/tools/testing/selftests/bpf/test_kmods/bpf_testmod.c
> @@ -271,6 +271,76 @@ __bpf_kfunc void bpf_kfunc_put_default_trusted_ptr_test(struct prog_test_member
> */
> }
>
> +static void *kasan_uaf(void)
> +{
> + void *p = kmalloc(64, GFP_ATOMIC);
> +
> + if (!p)
> + return NULL;
> + memset(p, 0xAA, 64);
> + kfree(p);
> +
> + return p;
> +}
> +
> +#ifdef CONFIG_KASAN_GENERIC
> +extern void kasan_poison(const void *addr, size_t size, u8 value, bool init);
> +
> +__bpf_kfunc void bpf_kfunc_kasan_poison(void *mem, u32 mem__sz, u8 byte)
> +{
> + kasan_poison(mem, mem__sz, byte, false);
> +}
> +#else
> +__bpf_kfunc void bpf_kfunc_kasan_poison(void *mem, u32 mem__sz, u8 byte) { }
> +#endif
> +
> +__bpf_kfunc u8 *bpf_kfunc_kasan_uaf_1(void)
> +{
> + return kasan_uaf();
> +}
> +
> +__bpf_kfunc u16 *bpf_kfunc_kasan_uaf_2(void)
> +{
> + return kasan_uaf();
> +}
> +
> +__bpf_kfunc u32 *bpf_kfunc_kasan_uaf_4(void)
> +{
> + return kasan_uaf();
> +}
> +
> +__bpf_kfunc u64 *bpf_kfunc_kasan_uaf_8(void)
> +{
> + return kasan_uaf();
> +}
> +
> +static u8 test_oob_buffer[64];
> +
> +static void *bpf_kfunc_kasan_oob(void)
> +{
> + return test_oob_buffer+64;
> +}
> +
> +__bpf_kfunc u8 *bpf_kfunc_kasan_oob_1(void)
> +{
> + return bpf_kfunc_kasan_oob();
> +}
> +
> +__bpf_kfunc u16 *bpf_kfunc_kasan_oob_2(void)
> +{
> + return bpf_kfunc_kasan_oob();
> +}
> +
> +__bpf_kfunc u32 *bpf_kfunc_kasan_oob_4(void)
> +{
> + return bpf_kfunc_kasan_oob();
> +}
> +
> +__bpf_kfunc u64 *bpf_kfunc_kasan_oob_8(void)
> +{
> + return bpf_kfunc_kasan_oob();
> +}
> +
> __bpf_kfunc struct bpf_testmod_ctx *
> bpf_testmod_ctx_create(int *err)
> {
> @@ -740,6 +810,15 @@ BTF_ID_FLAGS(func, bpf_testmod_ops3_call_test_1)
> BTF_ID_FLAGS(func, bpf_testmod_ops3_call_test_2)
> BTF_ID_FLAGS(func, bpf_kfunc_get_default_trusted_ptr_test);
> BTF_ID_FLAGS(func, bpf_kfunc_put_default_trusted_ptr_test);
> +BTF_ID_FLAGS(func, bpf_kfunc_kasan_poison)
> +BTF_ID_FLAGS(func, bpf_kfunc_kasan_uaf_1)
> +BTF_ID_FLAGS(func, bpf_kfunc_kasan_uaf_2)
> +BTF_ID_FLAGS(func, bpf_kfunc_kasan_uaf_4)
> +BTF_ID_FLAGS(func, bpf_kfunc_kasan_uaf_8)
> +BTF_ID_FLAGS(func, bpf_kfunc_kasan_oob_1)
> +BTF_ID_FLAGS(func, bpf_kfunc_kasan_oob_2)
> +BTF_ID_FLAGS(func, bpf_kfunc_kasan_oob_4)
> +BTF_ID_FLAGS(func, bpf_kfunc_kasan_oob_8)
> BTF_KFUNCS_END(bpf_testmod_common_kfunc_ids)
>
> BTF_ID_LIST(bpf_testmod_dtor_ids)
>
> --
> 2.53.0
>
^ permalink raw reply
* Re: [PATCH v2 3/7] dt-bindings: soc: samsung: exynos-pmu: deprecate google,pmu-intr-gen-syscon
From: Rob Herring @ 2026-04-13 22:25 UTC (permalink / raw)
To: Alexey Klimov
Cc: Sam Protsenko, linux-samsung-soc, Krzysztof Kozlowski,
Peter Griffin, André Draszik, Conor Dooley, Alim Akhtar,
Tudor Ambarus, Krzysztof Kozlowski, linux-arm-kernel, devicetree,
linux-kernel
In-Reply-To: <20260401-exynos850-cpuhotplug-v2-3-c5a760a3e259@linaro.org>
On Wed, Apr 01, 2026 at 05:51:56AM +0100, Alexey Klimov wrote:
> The generic property samsung,pmu-intr-gen-syscon should be used
> by default for Samsung Exynos PMU hardware blocks. Update binding
> document to add deprecated flag for google,pmu-intr-gen-syscon
> property.
> While at this, also add dependency to not allow usage of both
> above mentioned properties in the same time.
>
> Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
> ---
> Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml b/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml
> index 92acdfd5d44e..1ff1a8729989 100644
> --- a/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml
> +++ b/Documentation/devicetree/bindings/soc/samsung/exynos-pmu.yaml
> @@ -119,6 +119,7 @@ properties:
> $ref: /schemas/types.yaml#/definitions/phandle
> description:
> Phandle to PMU interrupt generation interface.
> + deprecated: true
Deprecating doesn't really help. We still have to support both forever.
>
> required:
> - compatible
> @@ -207,6 +208,11 @@ allOf:
> properties:
> samsung,pmu-intr-gen-syscon: false
>
> +dependencies:
> + google,pmu-intr-gen-syscon:
> + not:
> + required: ['samsung,pmu-intr-gen-syscon']
Disallowing both means you couldn't update the DT in a compatible way
where you have both properties for some transistion period.
Rob
^ permalink raw reply
* Re: [PATCH net] net: airoha: Add missing bits in airoha_qdma_cleanup_tx_queue()
From: Jakub Kicinski @ 2026-04-13 22:57 UTC (permalink / raw)
To: lorenzo
Cc: Jakub Kicinski, andrew+netdev, davem, edumazet, pabeni,
linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260410-airoha_qdma_cleanup_tx_queue-fix-net-v1-1-b7171c8f1e78@kernel.org>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
---
net: airoha: Add missing bits in airoha_qdma_cleanup_tx_queue()
This commit resets DMA TX descriptors in airoha_qdma_cleanup_tx_queue
and synchronizes TX_DMA_IDX to TX_CPU_IDX to notify the hardware that
the ring is empty.
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index 9285a68f435fe..963ab7b8d166b 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> @@ -1044,13 +1044,17 @@ static int airoha_qdma_init_tx(struct airoha_qdma *qdma)
[ ... ]
> spin_lock_bh(&q->lock);
> for (i = 0; i < q->ndesc; i++) {
> - struct airoha_queue_entry *e = &q->entry[i];
> + struct airoha_qdma_desc *desc = &q->desc[i];
>
> + e = &q->entry[i];
Can this result in a NULL pointer dereference?
If airoha_qdma_init_tx_queue() sets q->ndesc before allocating q->entry and
q->desc, and devm_kzalloc() fails, the error path jumps to
airoha_hw_cleanup().
Because q->ndesc > 0, this cleanup loop would execute and dereference
q->entry[i] and q->desc[i], which may not have been allocated.
[ ... ]
> + /* Reset DMA descriptor */
> + WRITE_ONCE(desc->ctrl, 0);
> + WRITE_ONCE(desc->addr, 0);
> + WRITE_ONCE(desc->data, 0);
> + WRITE_ONCE(desc->msg0, 0);
> + WRITE_ONCE(desc->msg1, 0);
> + WRITE_ONCE(desc->msg2, 0);
Is it safe to modify these DMA descriptors and reset the ring indices below
without waiting for the hardware DMA engine to become idle?
In airoha_dev_stop(), the driver clears GLOBAL_CFG_TX_DMA_EN_MASK to request
the hardware DMA engine to stop, but it does not appear to poll
GLOBAL_CFG_TX_DMA_BUSY_MASK to ensure it has actually stopped.
Modifying the DMA descriptors and internal ring indices while the hardware
is still actively processing in-flight descriptors could potentially lead
to corrupted DMA fetches or IOMMU faults.
> q->queued--;
> }
> +
> + e = list_first_entry(&q->tx_list, struct airoha_queue_entry,
> + list);
> + index = e - q->entry;
> + /* Set TX_DMA_IDX to TX_CPU_IDX to notify the hw the QDMA TX ring is
> + * empty.
> + */
> + airoha_qdma_rmw(qdma, REG_TX_CPU_IDX(qid), TX_RING_CPU_IDX_MASK,
> + FIELD_PREP(TX_RING_CPU_IDX_MASK, index));
> + airoha_qdma_rmw(qdma, REG_TX_DMA_IDX(qid), TX_RING_DMA_IDX_MASK,
> + FIELD_PREP(TX_RING_DMA_IDX_MASK, index));
Could list_first_entry() be called on an empty list here?
If q->tx_list is empty (for example, if allocation failed in
airoha_qdma_init_tx_queue or if no entries had a valid dma_addr), calling
list_first_entry() returns an invalid pointer.
The subsequent pointer arithmetic would produce a garbage index value,
which is then written to the REG_TX_CPU_IDX and REG_TX_DMA_IDX registers.
--
pw-bot: cr
^ permalink raw reply
* [PATCH] iommu/mediatek-v1: add .of_xlate and defer arm_iommu_create_mapping()
From: Daniel Golle @ 2026-04-13 23:27 UTC (permalink / raw)
To: Yong Wu, Joerg Roedel, Will Deacon, Robin Murphy,
Matthias Brugger, AngeloGioacchino Del Regno, Bjorn Helgaas,
Rob Herring, Jason Gunthorpe, iommu, linux-mediatek, linux-kernel,
linux-arm-kernel
Since commit bcb81ac6ae3c ("iommu: Get DT/ACPI parsing into the proper
probe path") the iommu core populates the device's iommu_fwspec via
of_iommu_xlate() -> ops->of_xlate() before calling ops->probe_device().
mtk_iommu_v1 did not provide .of_xlate and instead parsed the "iommus"
property itself from probe_device(); with the new flow of_iommu_xlate()
returns -ENODEV, the fwspec is never populated, probe_device() is never
called, and the device_link from consumers (disp-ovl, disp-rdma, ...)
to their smi-larb supplier is never created. As a result the larb is
never runtime-resumed, its SMI clocks are gated by clk_disable_unused(),
and display and GPU DMA through the SMI bus fabric hang as soon as
unused clocks are disabled at late_initcall_sync.
Register mtk_iommu_v1_of_xlate() as .of_xlate and simplify
mtk_iommu_v1_probe_device() to just consume the already-populated
fwspec. arm_iommu_create_mapping() cannot run from the of_xlate path
because it eventually calls iommu_paging_domain_alloc() ->
dev_has_iommu(), which returns -ENODEV while the device is still in
the middle of its iommu setup and not yet attached to an iommu_group.
Move the mapping creation to probe_finalize(), which runs once the
iommu group has been set up for the device.
Fixes: bcb81ac6ae3c ("iommu: Get DT/ACPI parsing into the proper probe path")
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
---
drivers/iommu/mtk_iommu_v1.c | 58 +++++++++++++-----------------------
1 file changed, 20 insertions(+), 38 deletions(-)
diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c
index ac97dd2868d4b..e33e123fedc7b 100644
--- a/drivers/iommu/mtk_iommu_v1.c
+++ b/drivers/iommu/mtk_iommu_v1.c
@@ -413,12 +413,10 @@ static const struct iommu_ops mtk_iommu_v1_ops;
* MTK generation one iommu HW only support one iommu domain, and all the client
* sharing the same iova address space.
*/
-static int mtk_iommu_v1_create_mapping(struct device *dev,
- const struct of_phandle_args *args)
+static int mtk_iommu_v1_of_xlate(struct device *dev,
+ const struct of_phandle_args *args)
{
- struct mtk_iommu_v1_data *data;
struct platform_device *m4updev;
- struct dma_iommu_mapping *mtk_mapping;
int ret;
if (args->args_count != 1) {
@@ -442,47 +440,17 @@ static int mtk_iommu_v1_create_mapping(struct device *dev,
put_device(&m4updev->dev);
}
- ret = iommu_fwspec_add_ids(dev, args->args, 1);
- if (ret)
- return ret;
-
- data = dev_iommu_priv_get(dev);
- mtk_mapping = data->mapping;
- if (!mtk_mapping) {
- /* MTK iommu support 4GB iova address space. */
- mtk_mapping = arm_iommu_create_mapping(dev, 0, 1ULL << 32);
- if (IS_ERR(mtk_mapping))
- return PTR_ERR(mtk_mapping);
-
- data->mapping = mtk_mapping;
- }
-
- return 0;
+ return iommu_fwspec_add_ids(dev, args->args, 1);
}
static struct iommu_device *mtk_iommu_v1_probe_device(struct device *dev)
{
- struct iommu_fwspec *fwspec = NULL;
- struct of_phandle_args iommu_spec;
+ struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
struct mtk_iommu_v1_data *data;
- int err, idx = 0, larbid, larbidx;
+ int idx, larbid, larbidx;
struct device_link *link;
struct device *larbdev;
- while (!of_parse_phandle_with_args(dev->of_node, "iommus",
- "#iommu-cells",
- idx, &iommu_spec)) {
-
- err = mtk_iommu_v1_create_mapping(dev, &iommu_spec);
- of_node_put(iommu_spec.np);
- if (err)
- return ERR_PTR(err);
-
- /* dev->iommu_fwspec might have changed */
- fwspec = dev_iommu_fwspec_get(dev);
- idx++;
- }
-
if (!fwspec)
return ERR_PTR(-ENODEV);
@@ -516,9 +484,22 @@ static struct iommu_device *mtk_iommu_v1_probe_device(struct device *dev)
static void mtk_iommu_v1_probe_finalize(struct device *dev)
{
- __maybe_unused struct mtk_iommu_v1_data *data = dev_iommu_priv_get(dev);
+ struct mtk_iommu_v1_data *data = dev_iommu_priv_get(dev);
+ struct dma_iommu_mapping *mtk_mapping;
int err;
+ mtk_mapping = data->mapping;
+ if (!mtk_mapping) {
+ /* MTK iommu supports 4GB iova address space. */
+ mtk_mapping = arm_iommu_create_mapping(dev, 0, 1ULL << 32);
+ if (IS_ERR(mtk_mapping)) {
+ dev_err(dev, "Failed to create IOMMU mapping: %ld\n",
+ PTR_ERR(mtk_mapping));
+ return;
+ }
+ data->mapping = mtk_mapping;
+ }
+
err = arm_iommu_attach_device(dev, data->mapping);
if (err)
dev_err(dev, "Can't create IOMMU mapping - DMA-OPS will not work\n");
@@ -585,6 +566,7 @@ static const struct iommu_ops mtk_iommu_v1_ops = {
.probe_finalize = mtk_iommu_v1_probe_finalize,
.release_device = mtk_iommu_v1_release_device,
.device_group = generic_device_group,
+ .of_xlate = mtk_iommu_v1_of_xlate,
.owner = THIS_MODULE,
.default_domain_ops = &(const struct iommu_domain_ops) {
.attach_dev = mtk_iommu_v1_attach_device,
--
2.53.0
^ permalink raw reply related
* Re: [PATCH net-next 0/3] net: airoha: Preliminary series to support multiple net_devices connected to the same GDM port
From: patchwork-bot+netdevbpf @ 2026-04-14 0:00 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, linux-arm-kernel,
linux-mediatek, netdev, xuegang.lu
In-Reply-To: <20260412-airoha-multi-serdes-preliminary-patch-v1-0-08d5b670ca8f@kernel.org>
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Sun, 12 Apr 2026 19:13:11 +0200 you wrote:
> EN7581 or AN7583 SoCs support connecting multiple external SerDes (e.g.
> Ethernet or USB SerDes) to GDM3 or GDM4 ports via a hw arbiter that
> manages the traffic in a TDM manner.
> This series introduces some preliminary changes necessary to introduce
> support for multiple net_devices connected to the same Frame Engine (FE)
> GDM port (GDM3 or GDM4).
>
> [...]
Here is the summary with links:
- [net-next,1/3] net: airoha: Rely on net_device pointer in airoha_dev_setup_tc_block signature
https://git.kernel.org/netdev/net-next/c/360d745a5319
- [net-next,2/3] net: airoha: Rely on net_device pointer in HTB callbacks
https://git.kernel.org/netdev/net-next/c/8baf4bf72ef9
- [net-next,3/3] net: airoha: Rely on net_device pointer in ETS callbacks
https://git.kernel.org/netdev/net-next/c/ae32f80018f0
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* [PATCH v2 0/4] KVM: arm64: Handle unsupported guest translation granule sizes
From: Wei-Lin Chang @ 2026-04-14 0:03 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm, linux-kernel
Cc: Marc Zyngier, Oliver Upton, Joey Gouly, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, Will Deacon, Wei-Lin Chang
Hi,
This is v2 of fixing the granule size selection for software stage-1
and stage-2 walks. Thanks to Marc for the feedback on v1 ([1]).
* Changes from v1:
- Take the entire (v)tcr value for TGx decode helpers.
- Rename vtcr_to_walk_info() to setup_s2_walk() as preparation, also
pass vcpu as the argument instead of kvm.
- Use TCR_* instead of TCR_EL1_* definitions.
- Return unsigned int instead of u64 when returning a granule shift.
- Split unit changes in get_guest_mapping_ttl() and
compute_tlb_inval_range() into its own patch.
Thanks!
[1]: https://lore.kernel.org/kvmarm/20260406164618.3312473-1-weilin.chang@arm.com/
Wei-Lin Chang (4):
KVM: arm64: nv: Rename vtcr_to_walk_info() to setup_s2_walk()
KVM: arm64: Factor out TG0/1 decoding of VTCR and TCR
KVM: arm64: nv: Use literal granule size in TLBI range calculation
KVM: arm64: Fallback to a supported value for unsupported guest TGx
arch/arm64/kvm/at.c | 125 ++++++++++++++++++++++++++--------
arch/arm64/kvm/nested.c | 144 +++++++++++++++++++++++++++-------------
2 files changed, 196 insertions(+), 73 deletions(-)
--
2.43.0
^ permalink raw reply
* [PATCH v2 1/4] KVM: arm64: nv: Rename vtcr_to_walk_info() to setup_s2_walk()
From: Wei-Lin Chang @ 2026-04-14 0:03 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm, linux-kernel
Cc: Marc Zyngier, Oliver Upton, Joey Gouly, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, Will Deacon, Wei-Lin Chang
In-Reply-To: <20260414000334.3947257-1-weilin.chang@arm.com>
This rename aligns the stage-2 walker better with the stage-1 walker.
Also set up other non-VTCR walk info in the function.
Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>
---
arch/arm64/kvm/nested.c | 15 +++++++--------
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
index 2c43097248b2..f20402d0d7e5 100644
--- a/arch/arm64/kvm/nested.c
+++ b/arch/arm64/kvm/nested.c
@@ -378,9 +378,12 @@ static int walk_nested_s2_pgd(struct kvm_vcpu *vcpu, phys_addr_t ipa,
return 0;
}
-static void vtcr_to_walk_info(u64 vtcr, struct s2_walk_info *wi)
+static void setup_s2_walk(struct kvm_vcpu *vcpu, struct s2_walk_info *wi)
{
- wi->t0sz = vtcr & TCR_EL2_T0SZ_MASK;
+ u64 vtcr = vcpu_read_sys_reg(vcpu, VTCR_EL2);
+
+ wi->baddr = vcpu_read_sys_reg(vcpu, VTTBR_EL2);
+ wi->t0sz = vtcr & VTCR_EL2_T0SZ_MASK;
switch (FIELD_GET(VTCR_EL2_TG0_MASK, vtcr)) {
case VTCR_EL2_TG0_4K:
@@ -398,12 +401,12 @@ static void vtcr_to_walk_info(u64 vtcr, struct s2_walk_info *wi)
ps_to_output_size(FIELD_GET(VTCR_EL2_PS_MASK, vtcr), false));
wi->ha = vtcr & VTCR_EL2_HA;
+ wi->be = vcpu_read_sys_reg(vcpu, SCTLR_EL2) & SCTLR_ELx_EE;
}
int kvm_walk_nested_s2(struct kvm_vcpu *vcpu, phys_addr_t gipa,
struct kvm_s2_trans *result)
{
- u64 vtcr = vcpu_read_sys_reg(vcpu, VTCR_EL2);
struct s2_walk_info wi;
int ret;
@@ -412,11 +415,7 @@ int kvm_walk_nested_s2(struct kvm_vcpu *vcpu, phys_addr_t gipa,
if (!vcpu_has_nv(vcpu))
return 0;
- wi.baddr = vcpu_read_sys_reg(vcpu, VTTBR_EL2);
-
- vtcr_to_walk_info(vtcr, &wi);
-
- wi.be = vcpu_read_sys_reg(vcpu, SCTLR_EL2) & SCTLR_ELx_EE;
+ setup_s2_walk(vcpu, &wi);
ret = walk_nested_s2_pgd(vcpu, gipa, &wi, result);
if (ret)
--
2.43.0
^ permalink raw reply related
* [PATCH v2 3/4] KVM: arm64: nv: Use literal granule size in TLBI range calculation
From: Wei-Lin Chang @ 2026-04-14 0:03 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm, linux-kernel
Cc: Marc Zyngier, Oliver Upton, Joey Gouly, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, Will Deacon, Wei-Lin Chang
In-Reply-To: <20260414000334.3947257-1-weilin.chang@arm.com>
TLBI handling derives the invalidation range from guest VTCR_EL2.TG0 in
get_guest_mapping_ttl() and compute_tlb_inval_range(). Switch these to
use a helper that returns the decoded VTCR_EL2.TG0 granule size instead
of decoding it inline.
This keeps the granule size derivation in one place and prepares for
following changes that adjust the effective granule size.
Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>
---
arch/arm64/kvm/nested.c | 32 +++++++++++++++++++-------------
1 file changed, 19 insertions(+), 13 deletions(-)
diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
index 40d52e9100d6..a732d7b0bd5d 100644
--- a/arch/arm64/kvm/nested.c
+++ b/arch/arm64/kvm/nested.c
@@ -394,6 +394,11 @@ static unsigned int vtcr_to_tg0_pgshift(u64 vtcr)
}
}
+static size_t vtcr_to_tg0_pgsize(u64 vtcr)
+{
+ return BIT(vtcr_to_tg0_pgshift(vtcr));
+}
+
static void setup_s2_walk(struct kvm_vcpu *vcpu, struct s2_walk_info *wi)
{
u64 vtcr = vcpu_read_sys_reg(vcpu, VTCR_EL2);
@@ -516,20 +521,21 @@ static u8 pgshift_level_to_ttl(u16 shift, u8 level)
*/
static u8 get_guest_mapping_ttl(struct kvm_s2_mmu *mmu, u64 addr)
{
- u64 tmp, sz = 0, vtcr = mmu->tlb_vtcr;
+ u64 tmp, sz = 0;
kvm_pte_t pte;
u8 ttl, level;
+ size_t tg0_size = vtcr_to_tg0_pgsize(mmu->tlb_vtcr);
lockdep_assert_held_write(&kvm_s2_mmu_to_kvm(mmu)->mmu_lock);
- switch (FIELD_GET(VTCR_EL2_TG0_MASK, vtcr)) {
- case VTCR_EL2_TG0_4K:
+ switch (tg0_size) {
+ case SZ_4K:
ttl = (TLBI_TTL_TG_4K << 2);
break;
- case VTCR_EL2_TG0_16K:
+ case SZ_16K:
ttl = (TLBI_TTL_TG_16K << 2);
break;
- case VTCR_EL2_TG0_64K:
+ case SZ_64K:
default: /* IMPDEF: treat any other value as 64k */
ttl = (TLBI_TTL_TG_64K << 2);
break;
@@ -539,19 +545,19 @@ static u8 get_guest_mapping_ttl(struct kvm_s2_mmu *mmu, u64 addr)
again:
/* Iteratively compute the block sizes for a particular granule size */
- switch (FIELD_GET(VTCR_EL2_TG0_MASK, vtcr)) {
- case VTCR_EL2_TG0_4K:
+ switch (tg0_size) {
+ case SZ_4K:
if (sz < SZ_4K) sz = SZ_4K;
else if (sz < SZ_2M) sz = SZ_2M;
else if (sz < SZ_1G) sz = SZ_1G;
else sz = 0;
break;
- case VTCR_EL2_TG0_16K:
+ case SZ_16K:
if (sz < SZ_16K) sz = SZ_16K;
else if (sz < SZ_32M) sz = SZ_32M;
else sz = 0;
break;
- case VTCR_EL2_TG0_64K:
+ case SZ_64K:
default: /* IMPDEF: treat any other value as 64k */
if (sz < SZ_64K) sz = SZ_64K;
else if (sz < SZ_512M) sz = SZ_512M;
@@ -602,14 +608,14 @@ unsigned long compute_tlb_inval_range(struct kvm_s2_mmu *mmu, u64 val)
if (!max_size) {
/* Compute the maximum extent of the invalidation */
- switch (FIELD_GET(VTCR_EL2_TG0_MASK, mmu->tlb_vtcr)) {
- case VTCR_EL2_TG0_4K:
+ switch (vtcr_to_tg0_pgsize(mmu->tlb_vtcr)) {
+ case SZ_4K:
max_size = SZ_1G;
break;
- case VTCR_EL2_TG0_16K:
+ case SZ_16K:
max_size = SZ_32M;
break;
- case VTCR_EL2_TG0_64K:
+ case SZ_64K:
default: /* IMPDEF: treat any other value as 64k */
/*
* No, we do not support 52bit IPA in nested yet. Once
--
2.43.0
^ permalink raw reply related
* [PATCH v2 2/4] KVM: arm64: Factor out TG0/1 decoding of VTCR and TCR
From: Wei-Lin Chang @ 2026-04-14 0:03 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm, linux-kernel
Cc: Marc Zyngier, Oliver Upton, Joey Gouly, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, Will Deacon, Wei-Lin Chang
In-Reply-To: <20260414000334.3947257-1-weilin.chang@arm.com>
The current code decodes TCR.TG0/TG1 and VTCR.TG0 inline at several
places. Extract this logic into helpers so the granule size can be
derived in one place. This enables us to alter the effective granule
size in the same place, which we will do in a later patch.
Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>
---
arch/arm64/kvm/at.c | 77 ++++++++++++++++++++++++++---------------
arch/arm64/kvm/nested.c | 27 +++++++++------
2 files changed, 65 insertions(+), 39 deletions(-)
diff --git a/arch/arm64/kvm/at.c b/arch/arm64/kvm/at.c
index a024d9a770dc..927226266081 100644
--- a/arch/arm64/kvm/at.c
+++ b/arch/arm64/kvm/at.c
@@ -135,14 +135,58 @@ static void compute_s1poe(struct kvm_vcpu *vcpu, struct s1_walk_info *wi)
wi->e0poe = (wi->regime != TR_EL2) && (val & TCR2_EL1_E0POE);
}
+static unsigned int tcr_to_tg0_pgshift(u64 tcr)
+{
+ u64 tg0 = tcr & TCR_TG0_MASK;
+
+ switch (tg0) {
+ case TCR_TG0_4K:
+ return 12;
+ case TCR_TG0_16K:
+ return 14;
+ case TCR_TG0_64K:
+ default: /* IMPDEF: treat any other value as 64k */
+ return 16;
+ }
+}
+
+static unsigned int tcr_to_tg1_pgshift(u64 tcr)
+{
+ u64 tg1 = tcr & TCR_TG1_MASK;
+
+ switch (tg1) {
+ case TCR_TG1_4K:
+ return 12;
+ case TCR_TG1_16K:
+ return 14;
+ case TCR_TG1_64K:
+ default: /* IMPDEF: treat any other value as 64k */
+ return 16;
+ }
+}
+
+static unsigned int tcr_tg_pgshift(u64 tcr, bool upper_range)
+{
+ unsigned int shift;
+
+ /* Someone was silly enough to encode TG0/TG1 differently */
+ if (upper_range)
+ shift = tcr_to_tg1_pgshift(tcr);
+ else
+ shift = tcr_to_tg0_pgshift(tcr);
+
+ return shift;
+}
+
static int setup_s1_walk(struct kvm_vcpu *vcpu, struct s1_walk_info *wi,
struct s1_walk_result *wr, u64 va)
{
- u64 hcr, sctlr, tcr, tg, ps, ia_bits, ttbr;
+ u64 hcr, sctlr, tcr, ps, ia_bits, ttbr;
unsigned int stride, x;
- bool va55, tbi, lva;
+ bool va55, tbi, lva, upper_range;
va55 = va & BIT(55);
+ upper_range = va55 && wi->regime != TR_EL2;
if (vcpu_has_nv(vcpu)) {
hcr = __vcpu_sys_reg(vcpu, HCR_EL2);
@@ -173,35 +217,12 @@ static int setup_s1_walk(struct kvm_vcpu *vcpu, struct s1_walk_info *wi,
BUG();
}
- /* Someone was silly enough to encode TG0/TG1 differently */
- if (va55 && wi->regime != TR_EL2) {
+ if (upper_range)
wi->txsz = FIELD_GET(TCR_T1SZ_MASK, tcr);
- tg = FIELD_GET(TCR_TG1_MASK, tcr);
-
- switch (tg << TCR_TG1_SHIFT) {
- case TCR_TG1_4K:
- wi->pgshift = 12; break;
- case TCR_TG1_16K:
- wi->pgshift = 14; break;
- case TCR_TG1_64K:
- default: /* IMPDEF: treat any other value as 64k */
- wi->pgshift = 16; break;
- }
- } else {
+ else
wi->txsz = FIELD_GET(TCR_T0SZ_MASK, tcr);
- tg = FIELD_GET(TCR_TG0_MASK, tcr);
-
- switch (tg << TCR_TG0_SHIFT) {
- case TCR_TG0_4K:
- wi->pgshift = 12; break;
- case TCR_TG0_16K:
- wi->pgshift = 14; break;
- case TCR_TG0_64K:
- default: /* IMPDEF: treat any other value as 64k */
- wi->pgshift = 16; break;
- }
- }
+ wi->pgshift = tcr_tg_pgshift(tcr, upper_range);
wi->pa52bit = has_52bit_pa(vcpu, wi, tcr);
ia_bits = get_ia_size(wi);
diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
index f20402d0d7e5..40d52e9100d6 100644
--- a/arch/arm64/kvm/nested.c
+++ b/arch/arm64/kvm/nested.c
@@ -378,28 +378,33 @@ static int walk_nested_s2_pgd(struct kvm_vcpu *vcpu, phys_addr_t ipa,
return 0;
}
-static void setup_s2_walk(struct kvm_vcpu *vcpu, struct s2_walk_info *wi)
-{
- u64 vtcr = vcpu_read_sys_reg(vcpu, VTCR_EL2);
- wi->baddr = vcpu_read_sys_reg(vcpu, VTTBR_EL2);
- wi->t0sz = vtcr & VTCR_EL2_T0SZ_MASK;
+static unsigned int vtcr_to_tg0_pgshift(u64 vtcr)
+{
+ u64 tg0 = FIELD_GET(VTCR_EL2_TG0_MASK, vtcr);
- switch (FIELD_GET(VTCR_EL2_TG0_MASK, vtcr)) {
+ switch (tg0) {
case VTCR_EL2_TG0_4K:
- wi->pgshift = 12; break;
+ return 12;
case VTCR_EL2_TG0_16K:
- wi->pgshift = 14; break;
+ return 14;
case VTCR_EL2_TG0_64K:
- default: /* IMPDEF: treat any other value as 64k */
- wi->pgshift = 16; break;
+ default: /* IMPDEF: treat any other value as 64k */
+ return 16;
}
+}
+
+static void setup_s2_walk(struct kvm_vcpu *vcpu, struct s2_walk_info *wi)
+{
+ u64 vtcr = vcpu_read_sys_reg(vcpu, VTCR_EL2);
+ wi->baddr = vcpu_read_sys_reg(vcpu, VTTBR_EL2);
+ wi->t0sz = vtcr & VTCR_EL2_T0SZ_MASK;
+ wi->pgshift = vtcr_to_tg0_pgshift(vtcr);
wi->sl = FIELD_GET(VTCR_EL2_SL0_MASK, vtcr);
/* Global limit for now, should eventually be per-VM */
wi->max_oa_bits = min(get_kvm_ipa_limit(),
ps_to_output_size(FIELD_GET(VTCR_EL2_PS_MASK, vtcr), false));
-
wi->ha = vtcr & VTCR_EL2_HA;
wi->be = vcpu_read_sys_reg(vcpu, SCTLR_EL2) & SCTLR_ELx_EE;
}
--
2.43.0
^ permalink raw reply related
* [PATCH v2 4/4] KVM: arm64: Fallback to a supported value for unsupported guest TGx
From: Wei-Lin Chang @ 2026-04-14 0:03 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm, linux-kernel
Cc: Marc Zyngier, Oliver Upton, Joey Gouly, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, Will Deacon, Wei-Lin Chang
In-Reply-To: <20260414000334.3947257-1-weilin.chang@arm.com>
When KVM derives the translation granule for emulated stage-1 and
stage-2 walks, it decodes TCR/VTCR.TGx and treats the granule as-is.
This is wrong when the guest programs a granule size that is not
advertised in the guest's ID_AA64MMFR0_EL1.TGRAN* fields.
Architecturally, such a value must be treated as an implemented granule
size. Choose an available one while prioritizing PAGE_SIZE.
Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>
---
arch/arm64/kvm/at.c | 52 +++++++++++++++++++++-
arch/arm64/kvm/nested.c | 98 +++++++++++++++++++++++++++++------------
2 files changed, 121 insertions(+), 29 deletions(-)
diff --git a/arch/arm64/kvm/at.c b/arch/arm64/kvm/at.c
index 927226266081..702ce531afd5 100644
--- a/arch/arm64/kvm/at.c
+++ b/arch/arm64/kvm/at.c
@@ -135,6 +135,30 @@ static void compute_s1poe(struct kvm_vcpu *vcpu, struct s1_walk_info *wi)
wi->e0poe = (wi->regime != TR_EL2) && (val & TCR2_EL1_E0POE);
}
+#define _has_tgran(__r, __sz) \
+ ({ \
+ u64 _s1, _mmfr0 = __r; \
+ \
+ _s1 = SYS_FIELD_GET(ID_AA64MMFR0_EL1, \
+ TGRAN##__sz, _mmfr0); \
+ \
+ _s1 != ID_AA64MMFR0_EL1_TGRAN##__sz##_NI; \
+ })
+
+static bool has_tgran(u64 mmfr0, unsigned int shift)
+{
+ switch (shift) {
+ case 12:
+ return _has_tgran(mmfr0, 4);
+ case 14:
+ return _has_tgran(mmfr0, 16);
+ case 16:
+ return _has_tgran(mmfr0, 64);
+ default:
+ BUG();
+ }
+}
+
static unsigned int tcr_to_tg0_pgshift(u64 tcr)
{
u64 tg0 = tcr & TCR_TG0_MASK;
@@ -165,8 +189,23 @@ static unsigned int tcr_to_tg1_pgshift(u64 tcr)
}
}
-static unsigned int tcr_tg_pgshift(u64 tcr, bool upper_range)
+static unsigned int fallback_tgran_shift(u64 mmfr0)
+{
+ if (has_tgran(mmfr0, PAGE_SHIFT))
+ return PAGE_SHIFT;
+ else if (has_tgran(mmfr0, 12))
+ return 12;
+ else if (has_tgran(mmfr0, 14))
+ return 14;
+ else if (has_tgran(mmfr0, 16))
+ return 16;
+ else
+ return PAGE_SHIFT;
+}
+
+static unsigned int tcr_tg_pgshift(struct kvm *kvm, u64 tcr, bool upper_range)
{
+ u64 mmfr0 = kvm_read_vm_id_reg(kvm, SYS_ID_AA64MMFR0_EL1);
unsigned int shift;
/* Someone was silly enough to encode TG0/TG1 differently */
@@ -175,6 +214,15 @@ static unsigned int tcr_tg_pgshift(u64 tcr, bool upper_range)
else
shift = tcr_to_tg0_pgshift(tcr);
+ /*
+ * If TGx is programmed to an unimplemented value (not advertised in
+ * ID_AA64MMFR0_EL1), we should treat it as if an implemented value is
+ * written, as per the architecture. Choose an available one while
+ * prioritizing PAGE_SIZE.
+ */
+ if (!has_tgran(mmfr0, shift))
+ return fallback_tgran_shift(mmfr0);
+
return shift;
}
@@ -222,7 +270,7 @@ static int setup_s1_walk(struct kvm_vcpu *vcpu, struct s1_walk_info *wi,
else
wi->txsz = FIELD_GET(TCR_T0SZ_MASK, tcr);
- wi->pgshift = tcr_tg_pgshift(tcr, upper_range);
+ wi->pgshift = tcr_tg_pgshift(vcpu->kvm, tcr, upper_range);
wi->pa52bit = has_52bit_pa(vcpu, wi, tcr);
ia_bits = get_ia_size(wi);
diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
index a732d7b0bd5d..327a6aaa45db 100644
--- a/arch/arm64/kvm/nested.c
+++ b/arch/arm64/kvm/nested.c
@@ -378,25 +378,83 @@ static int walk_nested_s2_pgd(struct kvm_vcpu *vcpu, phys_addr_t ipa,
return 0;
}
+#define _has_tgran_2(__r, __sz) \
+ ({ \
+ u64 _s1, _s2, _mmfr0 = __r; \
+ \
+ _s2 = SYS_FIELD_GET(ID_AA64MMFR0_EL1, \
+ TGRAN##__sz##_2, _mmfr0); \
+ \
+ _s1 = SYS_FIELD_GET(ID_AA64MMFR0_EL1, \
+ TGRAN##__sz, _mmfr0); \
+ \
+ ((_s2 != ID_AA64MMFR0_EL1_TGRAN##__sz##_2_NI && \
+ _s2 != ID_AA64MMFR0_EL1_TGRAN##__sz##_2_TGRAN##__sz) || \
+ (_s2 == ID_AA64MMFR0_EL1_TGRAN##__sz##_2_TGRAN##__sz && \
+ _s1 != ID_AA64MMFR0_EL1_TGRAN##__sz##_NI)); \
+ })
+
+static bool has_tgran_2(u64 mmfr0, unsigned int shift)
+{
+ switch (shift) {
+ case 12:
+ return _has_tgran_2(mmfr0, 4);
+ case 14:
+ return _has_tgran_2(mmfr0, 16);
+ case 16:
+ return _has_tgran_2(mmfr0, 64);
+ default:
+ BUG();
+ }
+}
+
+static unsigned int fallback_tgran2_shift(u64 mmfr0)
+{
+ if (has_tgran_2(mmfr0, PAGE_SHIFT))
+ return PAGE_SHIFT;
+ else if (has_tgran_2(mmfr0, 12))
+ return 12;
+ else if (has_tgran_2(mmfr0, 14))
+ return 14;
+ else if (has_tgran_2(mmfr0, 16))
+ return 16;
+ else
+ return PAGE_SHIFT;
+}
-static unsigned int vtcr_to_tg0_pgshift(u64 vtcr)
+static unsigned int vtcr_to_tg0_pgshift(struct kvm *kvm, u64 vtcr)
{
u64 tg0 = FIELD_GET(VTCR_EL2_TG0_MASK, vtcr);
+ u64 mmfr0 = kvm_read_vm_id_reg(kvm, SYS_ID_AA64MMFR0_EL1);
+ unsigned int shift;
switch (tg0) {
case VTCR_EL2_TG0_4K:
- return 12;
+ shift = 12;
+ break;
case VTCR_EL2_TG0_16K:
- return 14;
+ shift = 14;
+ break;
case VTCR_EL2_TG0_64K:
default: /* IMPDEF: treat any other value as 64k */
- return 16;
+ shift = 16;
}
+
+ /*
+ * If TGx is programmed to an unimplemented value (not advertised in
+ * ID_AA64MMFR0_EL1), we should treat it as if an implemented value is
+ * written, as per the architecture. Choose an available one while
+ * prioritizing PAGE_SIZE.
+ */
+ if (!has_tgran_2(mmfr0, shift))
+ return fallback_tgran2_shift(mmfr0);
+
+ return shift;
}
-static size_t vtcr_to_tg0_pgsize(u64 vtcr)
+static size_t vtcr_to_tg0_pgsize(struct kvm *kvm, u64 vtcr)
{
- return BIT(vtcr_to_tg0_pgshift(vtcr));
+ return BIT(vtcr_to_tg0_pgshift(kvm, vtcr));
}
static void setup_s2_walk(struct kvm_vcpu *vcpu, struct s2_walk_info *wi)
@@ -405,7 +463,7 @@ static void setup_s2_walk(struct kvm_vcpu *vcpu, struct s2_walk_info *wi)
wi->baddr = vcpu_read_sys_reg(vcpu, VTTBR_EL2);
wi->t0sz = vtcr & VTCR_EL2_T0SZ_MASK;
- wi->pgshift = vtcr_to_tg0_pgshift(vtcr);
+ wi->pgshift = vtcr_to_tg0_pgshift(vcpu->kvm, vtcr);
wi->sl = FIELD_GET(VTCR_EL2_SL0_MASK, vtcr);
/* Global limit for now, should eventually be per-VM */
wi->max_oa_bits = min(get_kvm_ipa_limit(),
@@ -524,7 +582,8 @@ static u8 get_guest_mapping_ttl(struct kvm_s2_mmu *mmu, u64 addr)
u64 tmp, sz = 0;
kvm_pte_t pte;
u8 ttl, level;
- size_t tg0_size = vtcr_to_tg0_pgsize(mmu->tlb_vtcr);
+ struct kvm *kvm = kvm_s2_mmu_to_kvm(mmu);
+ size_t tg0_size = vtcr_to_tg0_pgsize(kvm, mmu->tlb_vtcr);
lockdep_assert_held_write(&kvm_s2_mmu_to_kvm(mmu)->mmu_lock);
@@ -608,7 +667,7 @@ unsigned long compute_tlb_inval_range(struct kvm_s2_mmu *mmu, u64 val)
if (!max_size) {
/* Compute the maximum extent of the invalidation */
- switch (vtcr_to_tg0_pgsize(mmu->tlb_vtcr)) {
+ switch (vtcr_to_tg0_pgsize(kvm, mmu->tlb_vtcr)) {
case SZ_4K:
max_size = SZ_1G;
break;
@@ -1504,21 +1563,6 @@ static void kvm_map_l1_vncr(struct kvm_vcpu *vcpu)
}
}
-#define has_tgran_2(__r, __sz) \
- ({ \
- u64 _s1, _s2, _mmfr0 = __r; \
- \
- _s2 = SYS_FIELD_GET(ID_AA64MMFR0_EL1, \
- TGRAN##__sz##_2, _mmfr0); \
- \
- _s1 = SYS_FIELD_GET(ID_AA64MMFR0_EL1, \
- TGRAN##__sz, _mmfr0); \
- \
- ((_s2 != ID_AA64MMFR0_EL1_TGRAN##__sz##_2_NI && \
- _s2 != ID_AA64MMFR0_EL1_TGRAN##__sz##_2_TGRAN##__sz) || \
- (_s2 == ID_AA64MMFR0_EL1_TGRAN##__sz##_2_TGRAN##__sz && \
- _s1 != ID_AA64MMFR0_EL1_TGRAN##__sz##_NI)); \
- })
/*
* Our emulated CPU doesn't support all the possible features. For the
* sake of simplicity (and probably mental sanity), wipe out a number
@@ -1600,15 +1644,15 @@ u64 limit_nv_id_reg(struct kvm *kvm, u32 reg, u64 val)
*/
switch (PAGE_SIZE) {
case SZ_4K:
- if (has_tgran_2(orig_val, 4))
+ if (_has_tgran_2(orig_val, 4))
val |= SYS_FIELD_PREP_ENUM(ID_AA64MMFR0_EL1, TGRAN4_2, IMP);
fallthrough;
case SZ_16K:
- if (has_tgran_2(orig_val, 16))
+ if (_has_tgran_2(orig_val, 16))
val |= SYS_FIELD_PREP_ENUM(ID_AA64MMFR0_EL1, TGRAN16_2, IMP);
fallthrough;
case SZ_64K:
- if (has_tgran_2(orig_val, 64))
+ if (_has_tgran_2(orig_val, 64))
val |= SYS_FIELD_PREP_ENUM(ID_AA64MMFR0_EL1, TGRAN64_2, IMP);
break;
}
--
2.43.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox