* [PATCH 3/3] KVM: arm64: selftests: Enable stage-2 in NV preparation functions
From: Wei-Lin Chang @ 2026-03-25 0:36 UTC (permalink / raw)
To: kvm, linux-kselftest, linux-arm-kernel, kvmarm, linux-kernel
Cc: Paolo Bonzini, Shuah Khan, Marc Zyngier, Oliver Upton, Joey Gouly,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon
In-Reply-To: <20260325003620.2214766-1-weilin.chang@arm.com>
Introduce library functions for setting up guest stage-2 page tables,
then use that to give L2 an identity mapped stage-2 and enable it.
The translation and stage-2 page table built is simple, start level 0,
4 levels, 4KB granules, normal cachable, 48-bit IA, 40-bit OA.
The nested page table code is adapted from lib/x86/vmx.c.
Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>
---
.../selftests/kvm/include/arm64/nested.h | 7 ++
.../selftests/kvm/include/arm64/processor.h | 9 ++
.../testing/selftests/kvm/lib/arm64/nested.c | 97 ++++++++++++++++++-
3 files changed, 111 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/kvm/include/arm64/nested.h b/tools/testing/selftests/kvm/include/arm64/nested.h
index 739ff2ee0161..0be10a775e48 100644
--- a/tools/testing/selftests/kvm/include/arm64/nested.h
+++ b/tools/testing/selftests/kvm/include/arm64/nested.h
@@ -6,6 +6,13 @@
#ifndef SELFTEST_KVM_NESTED_H
#define SELFTEST_KVM_NESTED_H
+uint64_t get_l1_vtcr(void);
+
+void nested_map(struct kvm_vm *vm, vm_paddr_t guest_pgd,
+ uint64_t nested_paddr, uint64_t paddr, uint64_t size);
+void nested_map_memslot(struct kvm_vm *vm, vm_paddr_t guest_pgd,
+ uint32_t memslot);
+
void prepare_l2_stack(struct kvm_vm *vm, struct kvm_vcpu *vcpu);
void prepare_hyp_state(struct kvm_vm *vm, struct kvm_vcpu *vcpu);
void prepare_eret_destination(struct kvm_vm *vm, struct kvm_vcpu *vcpu, void *l2_pc);
diff --git a/tools/testing/selftests/kvm/include/arm64/processor.h b/tools/testing/selftests/kvm/include/arm64/processor.h
index ac97a1c436fc..5de2e932d95a 100644
--- a/tools/testing/selftests/kvm/include/arm64/processor.h
+++ b/tools/testing/selftests/kvm/include/arm64/processor.h
@@ -104,6 +104,15 @@
#define TCR_HA (UL(1) << 39)
#define TCR_DS (UL(1) << 59)
+/* VTCR_EL2 specific flags */
+#define VTCR_EL2_T0SZ_BITS(x) ((UL(64) - (x)) << VTCR_EL2_T0SZ_SHIFT)
+
+#define VTCR_EL2_SL0_LV0_4K (UL(2) << VTCR_EL2_SL0_SHIFT)
+#define VTCR_EL2_SL0_LV1_4K (UL(1) << VTCR_EL2_SL0_SHIFT)
+#define VTCR_EL2_SL0_LV2_4K (UL(0) << VTCR_EL2_SL0_SHIFT)
+
+#define VTCR_EL2_PS_40_BITS (UL(2) << VTCR_EL2_PS_SHIFT)
+
/*
* AttrIndx[2:0] encoding (mapping attributes defined in the MAIR* registers).
*/
diff --git a/tools/testing/selftests/kvm/lib/arm64/nested.c b/tools/testing/selftests/kvm/lib/arm64/nested.c
index 111d02f44cfe..910f8cd30f96 100644
--- a/tools/testing/selftests/kvm/lib/arm64/nested.c
+++ b/tools/testing/selftests/kvm/lib/arm64/nested.c
@@ -1,8 +1,11 @@
// SPDX-License-Identifier: GPL-2.0
/*
- * ARM64 Nested virtualization helpers
+ * ARM64 Nested virtualization helpers, nested page table code adapted from
+ * ../x86/vmx.c.
*/
+#include <linux/sizes.h>
+
#include "kvm_util.h"
#include "nested.h"
#include "processor.h"
@@ -18,6 +21,87 @@ static void hvc_handler(struct ex_regs *regs)
regs->pc = (u64)after_hvc;
}
+uint64_t get_l1_vtcr(void)
+{
+ return VTCR_EL2_PS_40_BITS | VTCR_EL2_TG0_4K | VTCR_EL2_ORGN0_WBWA |
+ VTCR_EL2_IRGN0_WBWA | VTCR_EL2_SL0_LV0_4K | VTCR_EL2_T0SZ_BITS(48);
+}
+
+static void __nested_pg_map(struct kvm_vm *vm, uint64_t guest_pgd,
+ uint64_t nested_paddr, uint64_t paddr, uint64_t flags)
+{
+ uint8_t attr_idx = flags & (PTE_ATTRINDX_MASK >> PTE_ATTRINDX_SHIFT);
+ uint64_t pg_attr;
+ uint64_t *ptep;
+
+ TEST_ASSERT((nested_paddr % vm->page_size) == 0,
+ "L2 IPA not on page boundary,\n"
+ " nested_paddr: 0x%lx vm->page_size: 0x%x", nested_paddr, vm->page_size);
+ TEST_ASSERT((paddr % vm->page_size) == 0,
+ "Guest physical address not on page boundary,\n"
+ " paddr: 0x%lx vm->page_size: 0x%x", paddr, vm->page_size);
+ TEST_ASSERT((paddr >> vm->page_shift) <= vm->max_gfn,
+ "Physical address beyond maximum supported,\n"
+ " paddr: 0x%lx vm->max_gfn: 0x%lx vm->page_size: 0x%x",
+ paddr, vm->max_gfn, vm->page_size);
+
+ ptep = addr_gpa2hva(vm, guest_pgd) + ((nested_paddr >> 39) & 0x1ffu) * 8;
+ if (!*ptep)
+ *ptep = (vm_alloc_page_table(vm) & GENMASK(47, 12)) | PGD_TYPE_TABLE | PTE_VALID;
+ ptep = addr_gpa2hva(vm, *ptep & GENMASK(47, 12)) + ((nested_paddr >> 30) & 0x1ffu) * 8;
+ if (!*ptep)
+ *ptep = (vm_alloc_page_table(vm) & GENMASK(47, 12)) | PUD_TYPE_TABLE | PTE_VALID;
+ ptep = addr_gpa2hva(vm, *ptep & GENMASK(47, 12)) + ((nested_paddr >> 21) & 0x1ffu) * 8;
+ if (!*ptep)
+ *ptep = (vm_alloc_page_table(vm) & GENMASK(47, 12)) | PMD_TYPE_TABLE | PTE_VALID;
+ ptep = addr_gpa2hva(vm, *ptep & GENMASK(47, 12)) + ((nested_paddr >> 12) & 0x1ffu) * 8;
+
+ pg_attr = PTE_AF | PTE_ATTRINDX(attr_idx) | PTE_TYPE_PAGE | PTE_VALID;
+ pg_attr |= PTE_SHARED;
+
+ *ptep = (paddr & GENMASK(47, 12)) | pg_attr;
+}
+
+void nested_map(struct kvm_vm *vm, vm_paddr_t guest_pgd,
+ uint64_t nested_paddr, uint64_t paddr, uint64_t size)
+{
+ size_t npages = size / SZ_4K;
+
+ TEST_ASSERT(nested_paddr + size > nested_paddr, "Vaddr overflow");
+ TEST_ASSERT(paddr + size > paddr, "Paddr overflow");
+
+ while (npages--) {
+ __nested_pg_map(vm, guest_pgd, nested_paddr, paddr, MT_NORMAL);
+ nested_paddr += SZ_4K;
+ paddr += SZ_4K;
+ }
+}
+
+/*
+ * Prepare an identity shadow page table that maps all the
+ * physical pages in VM.
+ */
+void nested_map_memslot(struct kvm_vm *vm, vm_paddr_t guest_pgd,
+ uint32_t memslot)
+{
+ sparsebit_idx_t i, last;
+ struct userspace_mem_region *region =
+ memslot2region(vm, memslot);
+
+ i = (region->region.guest_phys_addr >> vm->page_shift) - 1;
+ last = i + (region->region.memory_size >> vm->page_shift);
+ for (;;) {
+ i = sparsebit_next_clear(region->unused_phy_pages, i);
+ if (i > last)
+ break;
+
+ nested_map(vm, guest_pgd,
+ (uint64_t)i << vm->page_shift,
+ (uint64_t)i << vm->page_shift,
+ 1 << vm->page_shift);
+ }
+}
+
void prepare_l2_stack(struct kvm_vm *vm, struct kvm_vcpu *vcpu)
{
size_t l2_stack_size;
@@ -32,7 +116,16 @@ void prepare_l2_stack(struct kvm_vm *vm, struct kvm_vcpu *vcpu)
void prepare_hyp_state(struct kvm_vm *vm, struct kvm_vcpu *vcpu)
{
- vcpu_set_reg(vcpu, KVM_ARM64_SYS_REG(SYS_HCR_EL2), HCR_EL2_RW);
+ vm_paddr_t guest_pgd;
+
+ guest_pgd = vm_phy_pages_alloc(vm, 1,
+ KVM_GUEST_PAGE_TABLE_MIN_PADDR,
+ vm->memslots[MEM_REGION_PT]);
+ nested_map_memslot(vm, guest_pgd, 0);
+
+ vcpu_set_reg(vcpu, KVM_ARM64_SYS_REG(SYS_HCR_EL2), HCR_EL2_RW | HCR_EL2_VM);
+ vcpu_set_reg(vcpu, KVM_ARM64_SYS_REG(SYS_VTTBR_EL2), guest_pgd);
+ vcpu_set_reg(vcpu, KVM_ARM64_SYS_REG(SYS_VTCR_EL2), get_l1_vtcr());
}
void prepare_eret_destination(struct kvm_vm *vm, struct kvm_vcpu *vcpu, void *l2_pc)
--
2.43.0
^ permalink raw reply related
* [PATCH 2/3] KVM: arm64: sefltests: Add basic NV selftest
From: Wei-Lin Chang @ 2026-03-25 0:36 UTC (permalink / raw)
To: kvm, linux-kselftest, linux-arm-kernel, kvmarm, linux-kernel
Cc: Paolo Bonzini, Shuah Khan, Marc Zyngier, Oliver Upton, Joey Gouly,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon
In-Reply-To: <20260325003620.2214766-1-weilin.chang@arm.com>
Add a simple NV selftest that uses the NV library functions to eret from
vEL2 to EL1, then call an hvc to jump back to vEL2.
Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>
---
tools/testing/selftests/kvm/Makefile.kvm | 1 +
.../selftests/kvm/arm64/hello_nested.c | 65 +++++++++++++++++++
2 files changed, 66 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 5e681e8e0cd7..d7499609cd0c 100644
--- a/tools/testing/selftests/kvm/Makefile.kvm
+++ b/tools/testing/selftests/kvm/Makefile.kvm
@@ -167,6 +167,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..16c600539810
--- /dev/null
+++ b/tools/testing/selftests/kvm/arm64/hello_nested.c
@@ -0,0 +1,65 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * hello_nested - Go from vEL2 to EL1 then back
+ */
+#include "kvm_util.h"
+#include "nested.h"
+#include "processor.h"
+#include "test_util.h"
+#include "ucall.h"
+
+static void l2_guest_code(void)
+{
+ /* nothing */
+}
+
+static void guest_code(void)
+{
+ GUEST_ASSERT_EQ(get_current_el(), 2);
+ GUEST_PRINTF("vEL2 entry\n");
+ run_l2();
+ GUEST_DONE();
+}
+
+int main(void)
+{
+ struct kvm_vcpu_init init;
+ struct kvm_vcpu *vcpu;
+ struct kvm_vm *vm;
+ struct ucall uc;
+
+ 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);
+
+ prepare_l2_stack(vm, vcpu);
+ prepare_hyp_state(vm, vcpu);
+ prepare_eret_destination(vm, vcpu, l2_guest_code);
+ prepare_nested_sync_handler(vm, vcpu);
+
+ while (true) {
+ vcpu_run(vcpu);
+
+ switch (get_ucall(vcpu, &uc)) {
+ 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 related
* [PATCH 1/3] KVM: arm64: selftests: Add library functions for NV
From: Wei-Lin Chang @ 2026-03-25 0:36 UTC (permalink / raw)
To: kvm, linux-kselftest, linux-arm-kernel, kvmarm, linux-kernel
Cc: Paolo Bonzini, Shuah Khan, Marc Zyngier, Oliver Upton, Joey Gouly,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon
In-Reply-To: <20260325003620.2214766-1-weilin.chang@arm.com>
The API is designed for userspace to first call prepare_{l2_stack,
hyp_state, eret_destination, nested_sync_handler}, with a function
supplied to prepare_eret_destination() to be run in L2. Then run_l2()
can be called in L1 to run the given function in L2.
Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>
---
tools/testing/selftests/kvm/Makefile.kvm | 2 +
.../selftests/kvm/include/arm64/nested.h | 18 ++++++
.../testing/selftests/kvm/lib/arm64/nested.c | 61 +++++++++++++++++++
.../selftests/kvm/lib/arm64/nested_asm.S | 35 +++++++++++
4 files changed, 116 insertions(+)
create mode 100644 tools/testing/selftests/kvm/include/arm64/nested.h
create mode 100644 tools/testing/selftests/kvm/lib/arm64/nested.c
create mode 100644 tools/testing/selftests/kvm/lib/arm64/nested_asm.S
diff --git a/tools/testing/selftests/kvm/Makefile.kvm b/tools/testing/selftests/kvm/Makefile.kvm
index 98da9fa4b8b7..5e681e8e0cd7 100644
--- a/tools/testing/selftests/kvm/Makefile.kvm
+++ b/tools/testing/selftests/kvm/Makefile.kvm
@@ -34,6 +34,8 @@ LIBKVM_arm64 += lib/arm64/gic.c
LIBKVM_arm64 += lib/arm64/gic_v3.c
LIBKVM_arm64 += lib/arm64/gic_v3_its.c
LIBKVM_arm64 += lib/arm64/handlers.S
+LIBKVM_arm64 += lib/arm64/nested.c
+LIBKVM_arm64 += lib/arm64/nested_asm.S
LIBKVM_arm64 += lib/arm64/processor.c
LIBKVM_arm64 += lib/arm64/spinlock.c
LIBKVM_arm64 += lib/arm64/ucall.c
diff --git a/tools/testing/selftests/kvm/include/arm64/nested.h b/tools/testing/selftests/kvm/include/arm64/nested.h
new file mode 100644
index 000000000000..739ff2ee0161
--- /dev/null
+++ b/tools/testing/selftests/kvm/include/arm64/nested.h
@@ -0,0 +1,18 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * ARM64 Nested virtualization defines
+ */
+
+#ifndef SELFTEST_KVM_NESTED_H
+#define SELFTEST_KVM_NESTED_H
+
+void prepare_l2_stack(struct kvm_vm *vm, struct kvm_vcpu *vcpu);
+void prepare_hyp_state(struct kvm_vm *vm, struct kvm_vcpu *vcpu);
+void prepare_eret_destination(struct kvm_vm *vm, struct kvm_vcpu *vcpu, void *l2_pc);
+void prepare_nested_sync_handler(struct kvm_vm *vm, struct kvm_vcpu *vcpu);
+
+void run_l2(void);
+void after_hvc(void);
+void do_hvc(void);
+
+#endif /* SELFTEST_KVM_NESTED_H */
diff --git a/tools/testing/selftests/kvm/lib/arm64/nested.c b/tools/testing/selftests/kvm/lib/arm64/nested.c
new file mode 100644
index 000000000000..111d02f44cfe
--- /dev/null
+++ b/tools/testing/selftests/kvm/lib/arm64/nested.c
@@ -0,0 +1,61 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * ARM64 Nested virtualization helpers
+ */
+
+#include "kvm_util.h"
+#include "nested.h"
+#include "processor.h"
+#include "test_util.h"
+
+#include <asm/sysreg.h>
+
+static void hvc_handler(struct ex_regs *regs)
+{
+ GUEST_ASSERT_EQ(get_current_el(), 2);
+ GUEST_PRINTF("hvc handler\n");
+ regs->pstate = PSR_MODE_EL2h | PSR_D_BIT | PSR_A_BIT | PSR_I_BIT | PSR_F_BIT;
+ regs->pc = (u64)after_hvc;
+}
+
+void prepare_l2_stack(struct kvm_vm *vm, struct kvm_vcpu *vcpu)
+{
+ size_t l2_stack_size;
+ uint64_t l2_stack_paddr;
+
+ l2_stack_size = vm->page_size == 4096 ? DEFAULT_STACK_PGS * vm->page_size :
+ vm->page_size;
+ l2_stack_paddr = __vm_phy_pages_alloc(vm, l2_stack_size / vm->page_size,
+ 0, 0, false);
+ vcpu_set_reg(vcpu, ARM64_CORE_REG(sp_el1), l2_stack_paddr + l2_stack_size);
+}
+
+void prepare_hyp_state(struct kvm_vm *vm, struct kvm_vcpu *vcpu)
+{
+ vcpu_set_reg(vcpu, KVM_ARM64_SYS_REG(SYS_HCR_EL2), HCR_EL2_RW);
+}
+
+void prepare_eret_destination(struct kvm_vm *vm, struct kvm_vcpu *vcpu, void *l2_pc)
+{
+ vm_paddr_t do_hvc_paddr = addr_gva2gpa(vm, (vm_vaddr_t)do_hvc);
+ vm_paddr_t l2_pc_paddr = addr_gva2gpa(vm, (vm_vaddr_t)l2_pc);
+
+ vcpu_set_reg(vcpu, KVM_ARM64_SYS_REG(SYS_SPSR_EL2), PSR_MODE_EL1h |
+ PSR_D_BIT |
+ PSR_A_BIT |
+ PSR_I_BIT |
+ PSR_F_BIT);
+ vcpu_set_reg(vcpu, KVM_ARM64_SYS_REG(SYS_ELR_EL2), l2_pc_paddr);
+ /* HACK: use TPIDR_EL2 to pass address, see run_l2() in nested_asm.S */
+ vcpu_set_reg(vcpu, KVM_ARM64_SYS_REG(SYS_TPIDR_EL2), do_hvc_paddr);
+}
+
+void prepare_nested_sync_handler(struct kvm_vm *vm, struct kvm_vcpu *vcpu)
+{
+ if (!vm->handlers) {
+ vm_init_descriptor_tables(vm);
+ vcpu_init_descriptor_tables(vcpu);
+ }
+ vm_install_sync_handler(vm, VECTOR_SYNC_LOWER_64,
+ ESR_ELx_EC_HVC64, hvc_handler);
+}
diff --git a/tools/testing/selftests/kvm/lib/arm64/nested_asm.S b/tools/testing/selftests/kvm/lib/arm64/nested_asm.S
new file mode 100644
index 000000000000..4ecf2d510a6f
--- /dev/null
+++ b/tools/testing/selftests/kvm/lib/arm64/nested_asm.S
@@ -0,0 +1,35 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * ARM64 Nested virtualization assembly helpers
+ */
+
+.globl run_l2
+.globl after_hvc
+.globl do_hvc
+run_l2:
+ /*
+ * At this point TPIDR_EL2 will contain the gpa of do_hvc from
+ * prepare_eret_destination(). gpa of do_hvc have to be passed in
+ * because we want L2 to issue an hvc after it returns from the user
+ * passed function. In order for that to happen the lr must be
+ * controlled, which at this point holds the value of the address of
+ * the next instruction after this run_l2() call, which is not useful
+ * for L2. Additionally, L1 can't translate gva into gpa, so we can't
+ * calculate it here.
+ *
+ * So first save lr, then move TPIDR_EL2 to lr so when the user supplied
+ * L2 function returns, L2 jumps to do_hvc and let the L1 hvc handler
+ * take control. This implies we expect the L2 code to preserve lr and
+ * calls a regular ret in the end, which is true for normal C functions.
+ * The hvc handler will jump back to after_hvc when finished, and lr
+ * will be restored and we can return run_l2().
+ */
+ stp x29, lr, [sp, #-16]!
+ mrs x0, tpidr_el2
+ mov lr, x0
+ eret
+after_hvc:
+ ldp x29, lr, [sp], #16
+ ret
+do_hvc:
+ hvc #0
--
2.43.0
^ permalink raw reply related
* [PATCH 0/3] KVM: arm64: selftests: Basic nested guest support
From: Wei-Lin Chang @ 2026-03-25 0:36 UTC (permalink / raw)
To: kvm, linux-kselftest, linux-arm-kernel, kvmarm, linux-kernel
Cc: Paolo Bonzini, Shuah Khan, Marc Zyngier, Oliver Upton, Joey Gouly,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon
Hi,
This series adds basic support for running nested guests (L2) in
kselftest. The first patch adds library functions. While designing the
APIs for userspace, I referenced Joey's approach for kvm-unit-tests [1].
In summary, four preparatory functions are provided for userspace to
set up state to run an L2 in EL1:
- prepare_l2_stack() <- sets up stack for L2
- prepare_hyp_state() <- sets up vEL2 registers
- prepare_eret_destination() <- userspace passes a function pointer
for L2 to run
- prepare_nested_sync_handler() <- sets up hvc handler in order to
regain control after L2's hvc
After calling those functions, userspace can vcpu_run(), and when
run_l2() is called within the guest, the supplied function will be run
in L2, with the control flow managed by the library code in nested.c and
nested_asm.S. After running the L2 function, run_l2() will automatically
return. Note that the L2 function supplied by the user does not have to
call hvc.
Patch 2 demonstrates usage of the APIs introduced above, with a simple
L1 -> L2 -> L1 sequence, with an empty L2 function.
Patch 3 enhances the library functions by setting up L2 -> L1 stage-2
translation. Currently the translation is simple, with start level 0, 4
levels, 4KB granules, normal cachable, 48-bit IA, 40-bit OA.
[1]: https://lore.kernel.org/kvmarm/20260306142656.2775185-1-joey.gouly@arm.com/
Wei-Lin Chang (3):
KVM: arm64: selftests: Add library functions for NV
KVM: arm64: sefltests: Add basic NV selftest
KVM: arm64: selftests: Enable stage-2 in NV preparation functions
tools/testing/selftests/kvm/Makefile.kvm | 3 +
.../selftests/kvm/arm64/hello_nested.c | 65 ++++++++
.../selftests/kvm/include/arm64/nested.h | 25 +++
.../selftests/kvm/include/arm64/processor.h | 9 +
.../testing/selftests/kvm/lib/arm64/nested.c | 154 ++++++++++++++++++
.../selftests/kvm/lib/arm64/nested_asm.S | 35 ++++
6 files changed, 291 insertions(+)
create mode 100644 tools/testing/selftests/kvm/arm64/hello_nested.c
create mode 100644 tools/testing/selftests/kvm/include/arm64/nested.h
create mode 100644 tools/testing/selftests/kvm/lib/arm64/nested.c
create mode 100644 tools/testing/selftests/kvm/lib/arm64/nested_asm.S
--
2.43.0
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: allwinner: sun50i-h6: add UART DMA channels
From: Jernej Škrabec @ 2026-03-25 0:31 UTC (permalink / raw)
To: Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Chen-Yu Tsai
Cc: linux-sunxi, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20260324161930.1602083-2-wens@kernel.org>
Dne torek, 24. marec 2026 ob 17:19:29 Srednjeevropski standardni čas je Chen-Yu Tsai napisal(a):
> All the UARTs support DMA and are hooked up to the DMA controller.
>
> Add the DMA channels for the UARTs
>
> Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Best regards,
Jernej
^ permalink raw reply
* Re: [PATCH 1/2] arm64: dts: allwinner: sun50i-a64: add UART DMA channels
From: Jernej Škrabec @ 2026-03-25 0:31 UTC (permalink / raw)
To: Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Chen-Yu Tsai
Cc: linux-sunxi, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20260324161930.1602083-1-wens@kernel.org>
Dne torek, 24. marec 2026 ob 17:19:28 Srednjeevropski standardni čas je Chen-Yu Tsai napisal(a):
> All the UARTs support DMA and are hooked up to the DMA controller.
>
> Add the DMA channels for the UARTs
>
> Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Best regards,
Jernej
^ permalink raw reply
* Re: [PATCH 7/7] arm64: dts: allwinner: sun50i-h616: Add SRAM nodes
From: Jernej Škrabec @ 2026-03-25 0:30 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Chen-Yu Tsai
Cc: devicetree, linux-sunxi, linux-arm-kernel, linux-kernel
In-Reply-To: <20260324164357.1607247-8-wens@kernel.org>
Dne torek, 24. marec 2026 ob 17:43:55 Srednjeevropski standardni čas je Chen-Yu Tsai napisal(a):
> From: Jernej Skrabec <jernej.skrabec@gmail.com>
>
> The H616 SoC has a video engine, and two SRAM regions needed by it.
>
> Add the SRAM regions to the dtsi file. The video engine will be added
> in a separate change.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
> [wens@kernel.org: Add VE SRAM region, commit message, and split into two]
> Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Best regards,
Jernej
^ permalink raw reply
* Re: [PATCH 6/7] soc: sunxi: sram: Add H616 SRAM regions
From: Jernej Škrabec @ 2026-03-25 0:29 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Chen-Yu Tsai
Cc: devicetree, linux-sunxi, linux-arm-kernel, linux-kernel
In-Reply-To: <20260324164357.1607247-7-wens@kernel.org>
Dne torek, 24. marec 2026 ob 17:43:54 Srednjeevropski standardni čas je Chen-Yu Tsai napisal(a):
> The Allwinner H616 has two switchable peripheral SRAM regions:
>
> - The VE SRAM is a 2 MB dedicated SRAM for the Video Engine. CPU access
> to this region is enabled by default. CPU access can be disabled,
> after which reads will show the same stale value for all addresses,
> while writes are ignored.
>
> The mux value for this region is different from previous generations.
>
> - The SRAM C region is an alias of the first 128 KB of VE SRAM, plus 64
> KB of DE SRAM. The latter is otherwise unaccessible from the CPU. When
> CPU access is disabled, the whole region reads as zero, while writes
> are ignored.
>
> The mux value for this region is the same as on the A64 and H6.
>
> Add data for the VE SRAM. The register values were taken from the BSP
> vendor kernel.
>
> Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Best regards,
Jernej
^ permalink raw reply
* Re: [PATCH 5/7] soc: sunxi: sram: Support claiming multiple regions per device
From: Jernej Škrabec @ 2026-03-25 0:28 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Chen-Yu Tsai
Cc: devicetree, linux-sunxi, linux-arm-kernel, linux-kernel
In-Reply-To: <20260324164357.1607247-6-wens@kernel.org>
Dne torek, 24. marec 2026 ob 17:43:53 Srednjeevropski standardni čas je Chen-Yu Tsai napisal(a):
> On the H616, the video engine needs to claim two SRAM regions.
>
> Support claiming multiple regions per device.
>
> Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Best regards,
Jernej
^ permalink raw reply
* [PATCH] arm64: dts: exynos850: Add syscon-poweroff node
From: Alexey Klimov @ 2026-03-25 0:26 UTC (permalink / raw)
To: Sam Protsenko, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Alim Akhtar
Cc: linux-samsung-soc, linux-arm-kernel, devicetree, linux-kernel
Without poweroff node Exynos850-based board continue to draw current
(around ~60 mA with my test setup) after poweroff. Kernel also reports
different lockup problems and RCU stalls warnings continuosly after
last kernel messages about hardware being switched off.
Turns out we missed a write to PMU's PS_HOLD_CONTROL (PMU + 0x30c)
register that actually switches the SoC off.
Add poweroff node that implements this.
With this change the current draw after power off is in range of few
milliampers and lockup messages are no more.
Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
---
arch/arm64/boot/dts/exynos/exynos850.dtsi | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos850.dtsi b/arch/arm64/boot/dts/exynos/exynos850.dtsi
index cb55015c8dce..3881f573ec08 100644
--- a/arch/arm64/boot/dts/exynos/exynos850.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos850.dtsi
@@ -215,6 +215,13 @@ pmu_system_controller: system-controller@11860000 {
compatible = "samsung,exynos850-pmu", "syscon";
reg = <0x11860000 0x10000>;
+ poweroff: syscon-poweroff {
+ compatible = "syscon-poweroff";
+ offset = <0x30c>; /* PS_HOLD_CONTROL */
+ mask = <0x00000100>;
+ value = <0x0>;
+ };
+
reboot: syscon-reboot {
compatible = "syscon-reboot";
regmap = <&pmu_system_controller>;
---
base-commit: 85964cdcad0fac9a0eb7b87a0f9d88cc074b854c
change-id: 20260325-exynos850-poweroff-a6515334888a
Best regards,
--
Alexey Klimov <alexey.klimov@linaro.org>
^ permalink raw reply related
* Re: [PATCH 4/7] soc: sunxi: sram: Allow SRAM to be claimed multiple times
From: Jernej Škrabec @ 2026-03-25 0:25 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Chen-Yu Tsai
Cc: devicetree, linux-sunxi, linux-arm-kernel, linux-kernel
In-Reply-To: <20260324164357.1607247-5-wens@kernel.org>
Dne torek, 24. marec 2026 ob 17:43:52 Srednjeevropski standardni čas je Chen-Yu Tsai napisal(a):
> On the H616, the SRAM C region is an alias mapping to part of the VE
> SRAM (accessible in whole at a different address) and part of the DE
> SRAM (otherwise unaccessible). As such both the VE and DE need to claim
> this SRAM region to prevent access from the CPU.
>
> The SRAM claim API is designed so that a "claim" routes the SRAM to the
> peripheral device, disabling access from the CPU. So long as the written
> register value is the same for all the claimants involved, allowing
> multiple or repeated claims is trivial. This is indeed the case for all
> supported SRAM regions. The only known SRAM region to have multiple
> different settings is the SRAM C2 region; this can be claimed by the AE,
> CE, or ACE (assumed to be AE + CE). This region is not supported, and
> likely will never be needed nor supported, as there is no documentation
> for the peripherals involved.
>
> Change the SRAM region "claimed" field from a boolean to a reference
> count. A claim will increment the count, while a release decreases it.
> The first claim will trigger the register value write. The driver
> otherwise behaves as before.
>
> Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Best regards,
Jernej
^ permalink raw reply
* Re: [PATCH 3/7] soc: sunxi: sram: Const-ify sunxi_sram_func data and references
From: Jernej Škrabec @ 2026-03-25 0:24 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Chen-Yu Tsai
Cc: devicetree, linux-sunxi, linux-arm-kernel, linux-kernel
In-Reply-To: <20260324164357.1607247-4-wens@kernel.org>
Dne torek, 24. marec 2026 ob 17:43:51 Srednjeevropski standardni čas je Chen-Yu Tsai napisal(a):
> sunxi_sram_func contains value mapping that do not change at runtime.
>
> Const-ify them.
>
> Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Best regards,
Jernej
^ permalink raw reply
* Re: [PATCH 2/7] dt-bindings: sram: sunxi-sram: Add H616 SRAM regions
From: Jernej Škrabec @ 2026-03-25 0:23 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Chen-Yu Tsai
Cc: devicetree, linux-sunxi, linux-arm-kernel, linux-kernel
In-Reply-To: <20260324164357.1607247-3-wens@kernel.org>
Dne torek, 24. marec 2026 ob 17:43:50 Srednjeevropski standardni čas je Chen-Yu Tsai napisal(a):
> The Allwinner H616 has two switchable peripheral SRAM regions:
>
> - The VE SRAM is a 2 MB dedicated SRAM for the Video Engine. CPU access
> to this region is enabled by default. CPU access can be disabled,
> after which reads will show the same stale value for all addresses,
> while writes are ignored.
>
> The mux value for this region is different from previous generations.
>
> - The SRAM C region is an alias of the first 128 KB of VE SRAM, plus 64
> KB of DE SRAM. The latter is otherwise unaccessible from the CPU. When
> CPU access is disabled, the whole region reads as zero, while writes
> are ignored.
>
> The mux value for this region is the same as on the A64 and H6.
>
> Add compatible strings for both of them.
>
> Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Best regards,
Jernej
^ permalink raw reply
* Re: [PATCH 1/7] dt-bindings: sram: Document Allwinner H616 VE SRAM
From: Jernej Škrabec @ 2026-03-25 0:22 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Chen-Yu Tsai
Cc: devicetree, linux-sunxi, linux-arm-kernel, linux-kernel
In-Reply-To: <20260324164357.1607247-2-wens@kernel.org>
Dne torek, 24. marec 2026 ob 17:43:49 Srednjeevropski standardni čas je Chen-Yu Tsai napisal(a):
> The Allwinner H616 has two switchable peripheral SRAM regions:
>
> - The VE SRAM is a 2 MB dedicated SRAM for the Video Engine. CPU access
> to this region is enabled by default. CPU access can be disabled,
> after which reads will show the same stale value for all addresses,
> while writes are ignored.
>
> The mux value for this region is different from previous generations,
> and thus needs a completely new compatible.
>
> - The SRAM C region is an alias of the first 128 KB of VE SRAM, plus 64
> KB of DE SRAM. The latter is otherwise unaccessible from the CPU. When
> CPU access is disabled, the whole region reads as zero, while writes
> are ignored.
>
> The mux value for this region is the same as on the A64 and H6. The
> existing compatible for the A64 already covers this.
>
> Add the compatible for the VE SRAM to the list of covered compatibles in
> the generic SRAM region binding.
>
> Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Best regards,
Jernej
^ permalink raw reply
* Re: [PATCH] nvme: Move nvme_setup_cmd before hot_pathing
From: Justin Tee @ 2026-03-24 23:55 UTC (permalink / raw)
To: hmi.jeon, kbusch@kernel.org, axboe@kernel.dk
Cc: sven@kernel.org, j@jannau.net, neal@gompa.dev, hch@lst.de,
sagi@grimberg.me, justin.tee@broadcom.com,
nareshgottumukkala83@gmail.com, paul.ely@broadcom.com,
kch@nvidia.com, linux-arm-kernel@lists.infradead.org,
linux-nvme@lists.infradead.org, asahi@lists.linux.dev,
linux-kernel@vger.kernel.org
In-Reply-To: <20260320052101epcms2p42ae135da60b36685e9b7fca6849b57a6@epcms2p4>
Hi Minsik,
> diff --git a/drivers/nvme/host/fc.c b/drivers/nvme/host/fc.c
> index e1bb4707183c..8ea37102a836 100644
> --- a/drivers/nvme/host/fc.c
> +++ b/drivers/nvme/host/fc.c
> @@ -2762,14 +2762,14 @@ nvme_fc_queue_rq(struct blk_mq_hw_ctx *hctx,
> u32 data_len;
> blk_status_t ret;
>
> - if (ctrl->rport->remoteport.port_state != FC_OBJSTATE_ONLINE ||
> - !nvme_check_ready(&queue->ctrl->ctrl, rq, queue_ready))
> - return nvme_fail_nonready_command(&queue->ctrl->ctrl,
rq);
> -
> ret = nvme_setup_cmd(ns, rq);
> if (ret)
> return ret;
>
> + if (ctrl->rport->remoteport.port_state != FC_OBJSTATE_ONLINE ||
> + !nvme_check_ready(&queue->ctrl->ctrl, rq, queue_ready))
> + return nvme_fail_nonready_command(&queue->ctrl->ctrl,
rq);
> +
__nvme_check_ready() checks for (nvme_req(req)->flags &
NVME_REQ_USERCMD). In nvme_setup_cmd(), nvme_clear_nvme_request()
clears the nvme_req(req)->flags when RQF_DONTPREP is not set.
Is it possible that this patch would have nvme_setup_cmd() erase a
nvme_req(req)’s NVME_REQ_USERCMD flag before __nvme_check_ready() is
called for each respective .queue_rq?
Regards,
Justin Tee
^ permalink raw reply
* Re: [PATCH 00/12] SM3 library
From: Eric Biggers @ 2026-03-24 23:27 UTC (permalink / raw)
To: linux-crypto
Cc: linux-kernel, Ard Biesheuvel, Jason A . Donenfeld, Herbert Xu,
Tianjia Zhang, linux-arm-kernel, linux-riscv, x86
In-Reply-To: <20260321040935.410034-1-ebiggers@kernel.org>
On Fri, Mar 20, 2026 at 09:09:23PM -0700, Eric Biggers wrote:
> This series is targeting libcrypto-next. It can also be retrieved from:
>
> git fetch https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git sm3-lib-v1
>
> This series cleans up the kernel's existing SM3 hashing code:
>
> - First, it updates lib/crypto/sm3.c to implement the full SM3 instead
> of just SM3's compression function.
>
> - Next, it adds a KUnit test suite for the new library API.
>
> - Next, it replaces the "sm3-generic" crypto_shash with a wrapper around
> the new library API.
>
> - Finally, it accelerates the API using the existing SM3 assembly code
> for arm64, riscv, and x86. The architecture-specific crypto_shash
> glue code for SM3 is no longer needed and is removed.
>
> This should look quite boring. It's the same cleanup that I've already
> done for the other hash functions.
>
> Note: I don't recommend using SM3. There also don't appear to be any
> immediate candidate users of the SM3 library other than crypto_shash.
>
> Still, this seems like the clear way to go. It's simpler, and it gets
> the hash algorithms integrated in a consistent way. We won't have to
> keep track of two quite different ways of doing things. With KUnit the
> code becomes much easier to test and benchmark, as well.
Applied to https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git/log/?h=libcrypto-next
- Eric
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: power: Add power-domains-child-ids property
From: Rob Herring @ 2026-03-24 23:25 UTC (permalink / raw)
To: Kevin Hilman (TI)
Cc: Ulf Hansson, Geert Uytterhoeven, linux-pm, devicetree,
linux-kernel, arm-scmi, linux-arm-kernel
In-Reply-To: <20260310-topic-lpm-pmdomain-child-ids-v1-1-5361687a18ff@baylibre.com>
On Tue, Mar 10, 2026 at 05:19:23PM -0700, Kevin Hilman (TI) wrote:
> Add binding documentation for the new power-domains-child-ids property,
> which works in conjunction with the existing power-domains property to
> establish parent-child relationships between a multi-domain power domain
> provider and external parent domains.
>
> Each element in the uint32 array identifies the child domain
> ID (index) within the provider that should be made a child domain of
> the corresponding phandle entry in power-domains. The two arrays must
> have the same number of elements.
>
> Signed-off-by: Kevin Hilman (TI) <khilman@baylibre.com>
> ---
> Documentation/devicetree/bindings/power/power-domain.yaml | 35 +++++++++++++++++++++++++++++++++++
> 1 file changed, 35 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/power/power-domain.yaml b/Documentation/devicetree/bindings/power/power-domain.yaml
> index b1147dbf2e73..a3d2af124d37 100644
> --- a/Documentation/devicetree/bindings/power/power-domain.yaml
> +++ b/Documentation/devicetree/bindings/power/power-domain.yaml
> @@ -68,6 +68,21 @@ properties:
> by the given provider should be subdomains of the domain specified
> by this binding.
>
> + power-domains-child-ids:
> + $ref: /schemas/types.yaml#/definitions/uint32-array
> + description:
> + An array of child domain IDs that correspond to the power-domains
> + property. This property is only applicable to power domain providers
> + with "#power-domain-cells" > 0 (i.e., providers that supply multiple
> + power domains). It specifies which of the provider's child domains
> + should be associated with each parent domain listed in the power-domains
> + property. The number of elements in this array must match the number of
> + phandles in the power-domains property. Each element specifies the child
> + domain ID (index) that should be made a child domain of the corresponding
> + parent domain. This enables hierarchical power domain structures where
> + different child domains from the same provider can have different
> + parent domains.
Okay, I guess we stick with this. Sorry for the detour.
With the example fixed,
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Rob
^ permalink raw reply
* Re: [PATCH] arm64: dts: imx8mp: Add DT overlays for DH i.MX8M Plus DHCOM SoM and boards
From: Marek Vasut @ 2026-03-24 21:43 UTC (permalink / raw)
To: Frank Li
Cc: linux-arm-kernel, Christoph Niedermaier, Conor Dooley,
Fabio Estevam, Krzysztof Kozlowski, Pengutronix Kernel Team,
Rob Herring, Sascha Hauer, devicetree, imx, kernel, linux-kernel
In-Reply-To: <acLtV4Vwpbj9vpE3@lizhi-Precision-Tower-5810>
On 3/24/26 9:00 PM, Frank Li wrote:
> On Tue, Mar 24, 2026 at 06:39:10PM +0100, Marek Vasut wrote:
>> On 3/24/26 5:01 PM, Frank Li wrote:
>>> On Fri, Mar 13, 2026 at 12:24:04AM +0100, Marek Vasut wrote:
>>> ...
>>>
>>>> diff --git a/arch/arm64/boot/dts/freescale/imx8mp-dhcom-overlay-panel-ch101olhlwh.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-overlay-panel-ch101olhlwh.dtsi
>>>> new file mode 100644
>>>> index 0000000000000..534737363c9f0
>>>> --- /dev/null
>>>> +++ b/arch/arm64/boot/dts/freescale/imx8mp-dhcom-overlay-panel-ch101olhlwh.dtsi
>>>> @@ -0,0 +1,42 @@
>>>> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>>>> +/*
>>>> + * Copyright (C) 2022 Marek Vasut
>>>
>>> 2026?
>>
>> That was the original copyright year when this was implemented, but I can
>> update it to 2022-2026 ?
>
> Okay, you upstream this year.
Right, V2 does extend the copyrights until this year.
>>>> + */
>>>> +
>>>> +&display_bl {
>>>> + pwms = <&pwm1 0 5000000 0>;
>>>> +};
>>>> +
>>>> +&DH_OVERLAY_PANEL_I2C_BUS {
>>>
>>> why upcase for label, generally it should be lower case
>>
>> Because this label is really a macro , please read on.
>>
>>>> + #address-cells = <1>;
>>>> + #size-cells = <0>;
>>>> +
>>>> + touchscreen@41 {
>>>> + compatible = "ilitek,ili251x";
>>>> + pinctrl-0 = <DH_OVERLAY_PANEL_I2C_TOUCHSCREEN_PINCTRL>;
>>>> + pinctrl-names = "default";
>>>> + reg = <0x41>;
>>>
>>> reg should second property, please dt-format for new dts files.
>>> check others
>> What is "dt-format" ? Linux kernel source tree, even current next, does not
>> mention such a tool . I did run schema check and checkpatch on these
>> patches. obv.
>
> I send out at many place, https://github.com/lznuaa/dt-format
> I write small tools to detect and fix node and property order problem,
> it may be buggy.
>
> These node order problem is easy to detected and fix by tools to save
> review cycle and focus on the important stuff.
Maybe "make dtbs_check" target could include this tool , to make people
aware of it ?
^ permalink raw reply
* Re: [PATCH v5 09/10] clk: realtek: Add RTD1625-CRT clock controller driver
From: kernel test robot @ 2026-03-24 23:06 UTC (permalink / raw)
To: Yu-Chun Lin, mturquette, sboyd, robh, krzk+dt, conor+dt, p.zabel,
cylee12, afaerber, jyanchou
Cc: oe-kbuild-all, devicetree, linux-clk, linux-kernel,
linux-arm-kernel, linux-realtek-soc, james.tai, cy.huang,
stanley_chang, eleanor.lin
In-Reply-To: <20260324025332.3416977-10-eleanor.lin@realtek.com>
Hi Yu-Chun,
kernel test robot noticed the following build errors:
[auto build test ERROR on clk/clk-next]
[also build test ERROR on robh/for-next linus/master v7.0-rc5 next-20260324]
[cannot apply to pza/reset/next pza/imx-drm/next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Yu-Chun-Lin/dt-bindings-clock-Add-Realtek-RTD1625-Clock-Reset-Controller/20260324-171912
base: https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git clk-next
patch link: https://lore.kernel.org/r/20260324025332.3416977-10-eleanor.lin%40realtek.com
patch subject: [PATCH v5 09/10] clk: realtek: Add RTD1625-CRT clock controller driver
config: nios2-randconfig-001-20260325 (https://download.01.org/0day-ci/archive/20260325/202603250636.b3J5aCGL-lkp@intel.com/config)
compiler: nios2-linux-gcc (GCC) 8.5.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260325/202603250636.b3J5aCGL-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202603250636.b3J5aCGL-lkp@intel.com/
All errors (new ones prefixed by >>):
nios2-linux-ld: drivers/clk/realtek/common.o: in function `rtk_clk_probe':
>> drivers/clk/realtek/common.c:54: undefined reference to `rtk_reset_controller_add'
>> drivers/clk/realtek/common.c:54:(.text+0x134): relocation truncated to fit: R_NIOS2_CALL26 against `rtk_reset_controller_add'
Kconfig warnings: (for reference only)
WARNING: unmet direct dependencies detected for RTK_CLK_COMMON
Depends on [n]: COMMON_CLK [=y] && COMMON_CLK_REALTEK [=y] && RESET_CONTROLLER [=n]
Selected by [y]:
- COMMON_CLK_RTD1625 [=y] && COMMON_CLK [=y] && COMMON_CLK_REALTEK [=y]
vim +54 drivers/clk/realtek/common.c
105a817ead5cd3 Cheng-Yu Lee 2026-03-24 12
105a817ead5cd3 Cheng-Yu Lee 2026-03-24 13 int rtk_clk_probe(struct platform_device *pdev, const struct rtk_clk_desc *desc)
105a817ead5cd3 Cheng-Yu Lee 2026-03-24 14 {
105a817ead5cd3 Cheng-Yu Lee 2026-03-24 15 int i, ret;
105a817ead5cd3 Cheng-Yu Lee 2026-03-24 16 struct regmap *regmap;
105a817ead5cd3 Cheng-Yu Lee 2026-03-24 17 struct device *dev = &pdev->dev;
105a817ead5cd3 Cheng-Yu Lee 2026-03-24 18 struct rtk_reset_initdata reset_initdata = {0};
105a817ead5cd3 Cheng-Yu Lee 2026-03-24 19
105a817ead5cd3 Cheng-Yu Lee 2026-03-24 20 regmap = device_node_to_regmap(pdev->dev.of_node);
105a817ead5cd3 Cheng-Yu Lee 2026-03-24 21 if (IS_ERR(regmap))
105a817ead5cd3 Cheng-Yu Lee 2026-03-24 22 return dev_err_probe(dev, PTR_ERR(regmap), "failed to get regmap\n");
105a817ead5cd3 Cheng-Yu Lee 2026-03-24 23
105a817ead5cd3 Cheng-Yu Lee 2026-03-24 24 for (i = 0; i < desc->num_clks; i++)
105a817ead5cd3 Cheng-Yu Lee 2026-03-24 25 desc->clks[i]->regmap = regmap;
105a817ead5cd3 Cheng-Yu Lee 2026-03-24 26
105a817ead5cd3 Cheng-Yu Lee 2026-03-24 27 for (i = 0; i < desc->clk_data->num; i++) {
105a817ead5cd3 Cheng-Yu Lee 2026-03-24 28 struct clk_hw *hw = desc->clk_data->hws[i];
105a817ead5cd3 Cheng-Yu Lee 2026-03-24 29
105a817ead5cd3 Cheng-Yu Lee 2026-03-24 30 if (!hw)
105a817ead5cd3 Cheng-Yu Lee 2026-03-24 31 continue;
105a817ead5cd3 Cheng-Yu Lee 2026-03-24 32
105a817ead5cd3 Cheng-Yu Lee 2026-03-24 33 ret = devm_clk_hw_register(dev, hw);
105a817ead5cd3 Cheng-Yu Lee 2026-03-24 34
105a817ead5cd3 Cheng-Yu Lee 2026-03-24 35 if (ret) {
105a817ead5cd3 Cheng-Yu Lee 2026-03-24 36 dev_warn(dev, "failed to register hw of clk%d: %d\n", i,
105a817ead5cd3 Cheng-Yu Lee 2026-03-24 37 ret);
105a817ead5cd3 Cheng-Yu Lee 2026-03-24 38 desc->clk_data->hws[i] = NULL;
105a817ead5cd3 Cheng-Yu Lee 2026-03-24 39 }
105a817ead5cd3 Cheng-Yu Lee 2026-03-24 40 }
105a817ead5cd3 Cheng-Yu Lee 2026-03-24 41
105a817ead5cd3 Cheng-Yu Lee 2026-03-24 42 ret = devm_of_clk_add_hw_provider(dev, of_clk_hw_onecell_get,
105a817ead5cd3 Cheng-Yu Lee 2026-03-24 43 desc->clk_data);
105a817ead5cd3 Cheng-Yu Lee 2026-03-24 44 if (ret)
105a817ead5cd3 Cheng-Yu Lee 2026-03-24 45 return dev_err_probe(dev, ret, "failed to add clock provider\n");
105a817ead5cd3 Cheng-Yu Lee 2026-03-24 46
105a817ead5cd3 Cheng-Yu Lee 2026-03-24 47 if (!desc->num_reset_descs)
105a817ead5cd3 Cheng-Yu Lee 2026-03-24 48 return 0;
105a817ead5cd3 Cheng-Yu Lee 2026-03-24 49
105a817ead5cd3 Cheng-Yu Lee 2026-03-24 50 reset_initdata.regmap = regmap;
105a817ead5cd3 Cheng-Yu Lee 2026-03-24 51 reset_initdata.num_descs = desc->num_reset_descs;
105a817ead5cd3 Cheng-Yu Lee 2026-03-24 52 reset_initdata.descs = desc->reset_descs;
105a817ead5cd3 Cheng-Yu Lee 2026-03-24 53
105a817ead5cd3 Cheng-Yu Lee 2026-03-24 @54 return rtk_reset_controller_add(dev, &reset_initdata);
105a817ead5cd3 Cheng-Yu Lee 2026-03-24 55 }
105a817ead5cd3 Cheng-Yu Lee 2026-03-24 56 EXPORT_SYMBOL_GPL(rtk_clk_probe);
105a817ead5cd3 Cheng-Yu Lee 2026-03-24 57
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH] soc: fsl: qe_ports_ic: switch to irq_domain_create_linear()
From: Christophe Leroy (CS GROUP) @ 2026-03-24 22:34 UTC (permalink / raw)
To: Jiri Slaby, Qiang Zhao, Christophe Leroy (CS GROUP)
Cc: linuxppc-dev, linux-arm-kernel, linux-kernel
irq_domain_add_linear() is about to be removed, replace by the
more generic irq_domain_create_linear(),
see commit 42b8b16fe56c ("irqdomain: Drop irq_domain_add_*()
functions") for details.
Signed-off-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
---
drivers/soc/fsl/qe/qe_ports_ic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/soc/fsl/qe/qe_ports_ic.c b/drivers/soc/fsl/qe/qe_ports_ic.c
index 5e3fae19f314..9b0bba64e91e 100644
--- a/drivers/soc/fsl/qe/qe_ports_ic.c
+++ b/drivers/soc/fsl/qe/qe_ports_ic.c
@@ -118,7 +118,7 @@ static int qepic_probe(struct platform_device *pdev)
if (data->irq < 0)
return data->irq;
- data->host = irq_domain_add_linear(dev->of_node, 32, &qepic_host_ops, data);
+ data->host = irq_domain_create_linear(dev_fwnode(dev), 32, &qepic_host_ops, data);
if (!data->host)
return -ENODEV;
--
2.49.0
^ permalink raw reply related
* Re: [PATCH v5] arm64: dts: rockchip: rock-3b: Model PI6C20100 as gated-fixed-clock
From: Heiko Stuebner @ 2026-03-24 22:27 UTC (permalink / raw)
To: MidG971, Jonas Karlman
Cc: linux-rockchip, shawn.lin, jonas, linux-arm-kernel, devicetree
In-Reply-To: <533f27c9-e970-449b-a431-4ba41a566aaf@kwiboo.xyz>
Hi Jonas,
Am Dienstag, 24. März 2026, 18:15:38 Mitteleuropäische Normalzeit schrieb Jonas Karlman:
> Hi Heiko,
>
> On 3/24/2026 6:04 PM, Heiko Stuebner wrote:
> >
> > On Fri, 20 Mar 2026 10:44:41 +0100, MidG971 wrote:
> >> The Radxa ROCK 3B uses a PI6C20100 PCIe reference clock buffer to
> >> provide a 100MHz reference clock to the PCIe 3.0 PHY and controllers.
> >> This chip is currently modeled only as a fixed regulator
> >> (vcc3v3_pi6c_03), with no clock output representation.
> >>
> >> The PI6C20100 is a clock generator, not a power supply. Model it
> >> properly as a gated-fixed-clock, following the pattern established
> >> for the Rock 5 ITX and other boards with similar PCIe clock buffer
> >> chips.
> >>
> >> [...]
> >
> > Applied, thanks!
>
> My comments from v3 [1] was not addressed in v4 och v5. E.g.
> regulator-always-on/boot-on not being removed and redundant comments.
>
> [1] https://lore.kernel.org/all/fec0f25d-733a-4b6c-aef1-2ac51bd15798@kwiboo.se/
thank you so much for noticing. Looks like that AI thing is
working "well" ;-) .
I've droped the patch and recreated the for-next branch now.
@Midgy, please honor feedback in future revisions.
Thanks
Heiko
^ permalink raw reply
* Re: [PATCH 1/4] exec: inherit HWCAPs from the parent process
From: Andrei Vagin @ 2026-03-24 22:19 UTC (permalink / raw)
To: Will Deacon, Mark Rutland
Cc: Kees Cook, Andrew Morton, Marek Szyprowski, Cyrill Gorcunov,
Mike Rapoport, Alexander Mikhalitsyn, linux-kernel, linux-fsdevel,
linux-mm, criu, Catalin Marinas, linux-arm-kernel, Chen Ridong,
Christian Brauner, David Hildenbrand, Eric Biederman,
Lorenzo Stoakes, Michal Koutny, Alexander Mikhalitsyn
In-Reply-To: <acJnOB-rlyt-3jU4@willie-the-truck>
Hi Mark and Will,
Thanks for the feedback. Please read the inline comments.
On Tue, Mar 24, 2026 at 3:28 AM Will Deacon <will@kernel.org> wrote:
>
> On Mon, Mar 23, 2026 at 06:21:22PM +0000, Mark Rutland wrote:
> > On Mon, Mar 23, 2026 at 05:53:37PM +0000, Andrei Vagin wrote:
> > > Introduces a mechanism to inherit hardware capabilities (AT_HWCAP,
> > > AT_HWCAP2, etc.) from a parent process when they have been modified via
> > > prctl.
> > >
> > > To support C/R operations (snapshots, live migration) in heterogeneous
> > > clusters, we must ensure that processes utilize CPU features available
> > > on all potential target nodes. To solve this, we need to advertise a
> > > common feature set across the cluster.
> > >
> > > This patch adds a new mm flag MMF_USER_HWCAP, which is set when the
> > > auxiliary vector is modified via prctl(PR_SET_MM, PR_SET_MM_AUXV). When
> > > execve() is called, if the current process has MMF_USER_HWCAP set, the
> > > HWCAP values are extracted from the current auxiliary vector and stored
> > > in the linux_binprm structure. These values are then used to populate
> > > the auxiliary vector of the new process, effectively inheriting the
> > > hardware capabilities.
> > >
> > > The inherited HWCAPs are masked with the hardware capabilities supported
> > > by the current kernel to ensure that we don't report more features than
> > > actually supported. This is important to avoid unexpected behavior,
> > > especially for processes with additional privileges.
> >
> > At a high level, I don't think that's going to be sufficient:
> >
> > * On an architecture with other userspace accessible feature
> > identification mechanism registers (e.g. ID registers), userspace
> > might read those. So you might need to hide stuff there too, and
> > that's going to require architecture-specific interfaces to manage.
> >
> > It's possible that some code checks HWCAPs and others check ID
> > registers, and mismatch between the two could be problematic.
> >
> > * If the HWCAPs can be inherited by a more privileged task, then a
> > malicious user could use this to hide security features (e.g. shadow
> > stack or pointer authentication on arm64), and make it easier to
> > attack that task. While not a direct attack, it would undermine those
> > features.
I agree with Mark that only a privileged process have to be able to mask
certain hardware features. Currently, PR_SET_MM_AUXV is guarded by
CAP_SYS_RESOURCE, but PR_SET_MM_MAP allows changing the auxiliary vector
without specific capabilities. This is definitely the issue. To address
this, I think we can consider to introduce a new prctl command to enable
HWCAP inheritance explicitly.
>
> Yeah, this looks like a non-starter to me on arm64. Even if it was
> extended to apply the same treatment to the idregs, many of the hwcap
> features can't actually be disabled by the kernel and so you still run
> the risk of a task that probes for the presence of a feature using
> something like a SIGILL handler or, perhaps more likely, assumes that
> the presence of one hwcap implies the presence of another. And then
> there are the applications that just base everything off the MIDR...
The goal of this mechanism is not to provide strict architectural
enforcement or to trap the use of hardware features; rather, it is to
provide a consistent discovery interface for applications. I chose the
HWCAP vector because it mirrors the existing behavior of running an
older kernel on newer hardware: while ID registers might report a
feature as physically present, the HWCAPs will omit it if the kernel
lacks support. Applications are generally expected to treat HWCAPs as
the source of truth for which features are safe to use, even if the
underlying hardware is technically capable of more.
Another significant advantage of using HWCAPs is that many
applications already rely on them for feature detection. This interface
allows these applications to work correctly "out-of-the-box" in a
migrated environment without requiring any userspace modifications. I
understand that some apps may use other detection methods; however, there
it no gurantee that these applications will work correctly after
migration to another machine.
>
> There's also kvm, which provides a roundabout way to query some features
> of the underlying hardware.
>
> You're probably better off using/extending the idreg overrides we have
> in arch/arm64/kernel/pi/idreg-override.c so that you can make your
> cluster of heterogeneous machines look alike.
IIRC, idreg-override/cpuid-masking usually works for an entire machine.
We actually need to have a mechanism that will work on a per-container
basis. Workloads inside one cluster can have different
migration/snapshot requirements. Some are pinned to a specific node,
others are never migrated, while others need to be migratable across a
cluster or even between clusters. We need a mechanism that can be
tunable on a per-container/per-process basis.
>
> On the other hand, if munging the hwcaps happens to be sufficient for
> this particular use-case, can't it be handled entirely in userspace (e.g.
> by hacking libc?)
CRIU often handles workloads with a mix of runtimes: some linked against
glibc, some against musl, and others like Go that bypass libc entirely.
CRIU is mostly used to handle containers that can run multiple processes
possible based on different runtimes. It means available cpu features
should not be only specified for one runtime, they have to be passed
across different runtimes. I think the pure userspace solution is near
infeasible in this case.
Thanks,
Andrei
^ permalink raw reply
* Re: [RESEND v2 1/1] dt-bindings: arm: lpc: add missed lpc43xx board
From: Frank Li @ 2026-03-24 22:18 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Vladimir Zapolskiy, Piotr Wojtaszczyk, devicetree,
linux-arm-kernel, linux-kernel, Frank Li
Cc: imx
In-Reply-To: <20251015184846.2509016-1-Frank.Li@nxp.com>
On Wed, 15 Oct 2025 14:48:45 -0400, Frank Li wrote:
> Add missed legancy lpc43xx board compatible string to fix below CHECK_DTB
> warnings:
> arch/arm/boot/dts/nxp/lpc/lpc4337-ciaa.dtb: /: failed to match any schema with compatible: ['ciaa,lpc4337', 'nxp,lpc4337', 'nxp,lpc4350']
>
>
Applied, thanks!
[1/1] dt-bindings: arm: lpc: add missed lpc43xx board
commit: 2fa7edb7e9d5a704880eba7bb7eab796f2411263
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* [PATCH v3 3/3] dt-bindings: mtd: mxc-nand: add missing compatible string and ref to nand-controller-legacy.yaml
From: Frank Li @ 2026-03-24 22:16 UTC (permalink / raw)
To: Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Uwe Kleine-König, open list:MEMORY TECHNOLOGY DEVICES (MTD),
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
open list
Cc: imx
In-Reply-To: <20260324221624.2424092-1-Frank.Li@nxp.com>
Add compatible string fsl,imx51-nand, fsl,imx53-nand and fsl,imx35-nand.
Add missinge properties dmas and dma-names.
Change reg's maxItems to 2 because i.MX53 have addition NAND flash internal
buffer space.
Change ref to nand-controller-legacy.yaml allow legacy DT layout.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
changes in v3
- collect Rob's review by tags
Changes in v2:
- use items for regs.
---
.../devicetree/bindings/mtd/mxc-nand.yaml | 20 +++++++++++++++++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/mtd/mxc-nand.yaml b/Documentation/devicetree/bindings/mtd/mxc-nand.yaml
index 433ae5727ad85..fbaff7d3eda85 100644
--- a/Documentation/devicetree/bindings/mtd/mxc-nand.yaml
+++ b/Documentation/devicetree/bindings/mtd/mxc-nand.yaml
@@ -10,7 +10,7 @@ maintainers:
- Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
allOf:
- - $ref: nand-controller.yaml
+ - $ref: nand-controller-legacy.yaml
properties:
compatible:
@@ -18,12 +18,21 @@ properties:
- enum:
- fsl,imx25-nand
- fsl,imx27-nand
+ - fsl,imx51-nand
+ - fsl,imx53-nand
+ - items:
+ - enum:
+ - fsl,imx35-nand
+ - const: fsl,imx25-nand
- items:
- enum:
- fsl,imx31-nand
- const: fsl,imx27-nand
reg:
- maxItems: 1
+ minItems: 1
+ items:
+ - description: IP register space
+ - description: Nand flash internal buffer space
interrupts:
maxItems: 1
@@ -31,6 +40,13 @@ properties:
clocks:
maxItems: 1
+ dmas:
+ maxItems: 1
+
+ dma-names:
+ items:
+ - const: rx-tx
+
required:
- compatible
- reg
--
2.43.0
^ permalink raw reply related
* Re: [RESEND v2 1/1] dt-bindings: arm: lpc: add missed lpc43xx board
From: Vladimir Zapolskiy @ 2026-03-24 21:44 UTC (permalink / raw)
To: Frank Li, Krzysztof Kozlowski
Cc: Rob Herring, Conor Dooley, Piotr Wojtaszczyk,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:ARM/LPC32XX SOC SUPPORT, open list, imx
In-Reply-To: <acL_cAQ99B2VliJU@lizhi-Precision-Tower-5810>
Hi Frank,
On 3/24/26 23:17, Frank Li wrote:
> On Wed, Jan 28, 2026 at 10:24:50PM +0200, Vladimir Zapolskiy wrote:
>> Hi Frank,
>>
>> On 1/28/26 21:54, Frank Li wrote:
>>> On Wed, Oct 15, 2025 at 10:48:47PM +0300, Vladimir Zapolskiy wrote:
>>>> Hi Frank,
>>>>
>>>> On 10/15/25 21:48, Frank Li wrote:
>>>>> Add missed legancy lpc43xx board compatible string to fix below CHECK_DTB
>>>>> warnings:
>>>>> arch/arm/boot/dts/nxp/lpc/lpc4337-ciaa.dtb: /: failed to match any schema with compatible: ['ciaa,lpc4337', 'nxp,lpc4337', 'nxp,lpc4350']
>>>>>
>>>>> Reviewed-by: Vladimir Zapolskiy <vz@mleia.com>
>>>>> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>>>>> Signed-off-by: Frank Li <Frank.Li@nxp.com>
>>>>
>>>> I'll take it for v6.19, thank you.
>>>>
>>>> If you have any other changes in the queue, please feel free to send them also.
>>>
>>> Vladimir Zapolskiy:
>>>
>>> look like you missed this patch.
>>>
>>
>> You are right about it. I consider it's pretty late to send another PR
>> including this change, and thus it will be postponed, I'm sorry for it.
>
> Can I include this patch my imx's PR?
>
you've already got my RB, and there is no objections from my side, if
the change goes through imx dt PR, otherwise I have to postpone pushing
it upwards, there is no plan to send an ARM LPCxxxx dt PR for v7.1.
--
Best wishes,
Vladimir
^ permalink raw reply
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