* [PATCH v4 4/8] riscv/runtime-const: Replace open-coded placeholder with RUNTIME_MAGIC
From: K Prateek Nayak @ 2026-04-30 9:47 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, Peter Zijlstra,
Sebastian Andrzej Siewior, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Guo Ren
Cc: Darren Hart, Davidlohr Bueso, André Almeida, linux-arch,
linux-kernel, linux-s390, linux-riscv, linux-arm-kernel,
K Prateek Nayak, Alexandre Ghiti, Charlie Jenkins, Jisheng Zhang,
Charles Mirabile
In-Reply-To: <20260430094730.31624-1-kprateek.nayak@amd.com>
Define the placeholder used for lui + addi[w] patching sequence as
RUNTIME_MAGIC and use that instead of open coding the constants in the
inline assembly.
No functional changes intended.
Suggested-by: Guo Ren <guoren@kernel.org>
Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com>
---
changelog v3..v4:
o New patch based on suggestions from Guo. (Thank you!)
---
arch/riscv/include/asm/runtime-const.h | 38 ++++++++++++++------------
1 file changed, 20 insertions(+), 18 deletions(-)
diff --git a/arch/riscv/include/asm/runtime-const.h b/arch/riscv/include/asm/runtime-const.h
index 900db0a103d05..1ce02605d2e43 100644
--- a/arch/riscv/include/asm/runtime-const.h
+++ b/arch/riscv/include/asm/runtime-const.h
@@ -15,21 +15,23 @@
#include <linux/uaccess.h>
+#define RUNTIME_MAGIC __ASM_STR(0x89ABCDEF)
+
#ifdef CONFIG_32BIT
-#define runtime_const_ptr(sym) \
-({ \
- typeof(sym) __ret; \
- asm_inline(".option push\n\t" \
- ".option norvc\n\t" \
- "1:\t" \
- "lui %[__ret],0x89abd\n\t" \
- "addi %[__ret],%[__ret],-0x211\n\t" \
- ".option pop\n\t" \
- ".pushsection runtime_ptr_" #sym ",\"a\"\n\t" \
- ".long 1b - .\n\t" \
- ".popsection" \
- : [__ret] "=r" (__ret)); \
- __ret; \
+#define runtime_const_ptr(sym) \
+({ \
+ typeof(sym) __ret; \
+ asm_inline(".option push\n\t" \
+ ".option norvc\n\t" \
+ "1:\t" \
+ "lui %[__ret], %%hi(" RUNTIME_MAGIC ")\n\t" \
+ "addi %[__ret],%[__ret], %%lo(" RUNTIME_MAGIC ")\n\t" \
+ ".option pop\n\t" \
+ ".pushsection runtime_ptr_" #sym ",\"a\"\n\t" \
+ ".long 1b - .\n\t" \
+ ".popsection" \
+ : [__ret] "=r" (__ret)); \
+ __ret; \
})
#else
/*
@@ -46,10 +48,10 @@
".option push\n\t" \
".option norvc\n\t" \
"1:\t" \
- "lui %[__ret],0x89abd\n\t" \
- "lui %[__tmp],0x1234\n\t" \
- "addiw %[__ret],%[__ret],-0x211\n\t" \
- "addiw %[__tmp],%[__tmp],0x567\n\t" \
+ "lui %[__ret], %%hi(" RUNTIME_MAGIC ")\n\t" \
+ "lui %[__tmp], %%hi(" RUNTIME_MAGIC ")\n\t" \
+ "addiw %[__ret],%[__ret], %%lo(" RUNTIME_MAGIC ")\n\t" \
+ "addiw %[__tmp],%[__tmp], %%lo(" RUNTIME_MAGIC ")\n\t" \
#define RISCV_RUNTIME_CONST_64_BASE \
"slli %[__tmp],%[__tmp],32\n\t" \
--
2.34.1
^ permalink raw reply related
* [PATCH v4 3/8] arm64/runtime-const: Introduce runtime_const_mask_32()
From: K Prateek Nayak @ 2026-04-30 9:47 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, Peter Zijlstra,
Sebastian Andrzej Siewior, Catalin Marinas, Will Deacon
Cc: Darren Hart, Davidlohr Bueso, André Almeida, linux-arch,
linux-kernel, linux-s390, linux-riscv, linux-arm-kernel,
K Prateek Nayak, Jisheng Zhang
In-Reply-To: <20260430094730.31624-1-kprateek.nayak@amd.com>
Futex hash computation requires a mask operation with read-only after
init data that will be converted to a runtime constant in the subsequent
commit.
Introduce runtime_const_mask_32 to further optimize the mask operation
in the futex hash computation hot path. GCC generates a:
movz w1, #lo16, lsl #0 // w1 = bits [15:0]
movk w1, #hi16, lsl #16 // w1 = full 32-bit value
and w0, w0, w1 // w0 = w0 & w1
pattern to tackle arbitrary 32-bit masks and the same was also suggested
by Claude which is implemented here. The final (__ret & mask) operation
is intentiaonally placed outside of asm block to allow compilers to
further optimize it if possible.
__runtime_fixup_ptr() already patches a "movz, + movk lsl #16" sequence
which has been reused to patch the same sequence for
__runtime_fixup_mask().
Assisted-by: Claude:claude-sonnet-4-5
Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com>
---
changelog v3..v4:
o Reverted back to using __ret as the macro variable to prevent
collision with local varaibles at callsite. (Sashiko)
o Separated out the & operation to prevent any confusion with operator
precedence id "val" is an expression. (Sashiko)
---
arch/arm64/include/asm/runtime-const.h | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/arch/arm64/include/asm/runtime-const.h b/arch/arm64/include/asm/runtime-const.h
index 838145bc289d2..1db4faac8c373 100644
--- a/arch/arm64/include/asm/runtime-const.h
+++ b/arch/arm64/include/asm/runtime-const.h
@@ -36,6 +36,18 @@
:"r" (0u+(val))); \
__ret; })
+#define runtime_const_mask_32(val, sym) ({ \
+ unsigned long __ret; \
+ asm_inline("1:\t" \
+ "movz %w0, #0xcdef\n\t" \
+ "movk %w0, #0x89ab, lsl #16\n\t" \
+ ".pushsection runtime_mask_" #sym ",\"a\"\n\t" \
+ ".long 1b - .\n\t" \
+ ".popsection" \
+ :"=r" (__ret)); \
+ __ret &= val; /* Allow compiler to optimize & op. */ \
+ __ret; })
+
#define runtime_const_init(type, sym) do { \
extern s32 __start_runtime_##type##_##sym[]; \
extern s32 __stop_runtime_##type##_##sym[]; \
@@ -73,6 +85,13 @@ static inline void __runtime_fixup_shift(void *where, unsigned long val)
aarch64_insn_patch_text_nosync(p, insn);
}
+static inline void __runtime_fixup_mask(void *where, unsigned long val)
+{
+ __le32 *p = where;
+ __runtime_fixup_16(p, val);
+ __runtime_fixup_16(p+1, val >> 16);
+}
+
static inline void runtime_const_fixup(void (*fn)(void *, unsigned long),
unsigned long val, s32 *start, s32 *end)
{
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] ima: debugging late_initcall_sync measurements
From: Yeoreum Yun @ 2026-04-30 9:48 UTC (permalink / raw)
To: Mimi Zohar
Cc: Jonathan McDowell, linux-security-module, linux-kernel,
linux-integrity, linux-arm-kernel, kvmarm, paul, jmorris, serge,
roberto.sassu, dmitry.kasatkin, eric.snowberg, jarkko, jgg,
sudeep.holla, maz, oupton, joey.gouly, suzuki.poulose, yuzenghui,
catalin.marinas, will, noodles, sebastianene
In-Reply-To: <7734099f5e7fda5480bca016a9e6707983325fbd.camel@linux.ibm.com>
Hi Mimi,
Thanks to share the testing code and please see the below:
> With this "[RFC PATCH v3 0/4] Fix IMA + TPM initialisation ordering
> issue" patch set, how many records would be missing if IMA
> initialization is deferred to late_initcall_sync [1]?
>
> [1]https://lore.kernel.org/linux-integrity/cover.1777036497.git.noodles@meta.com/
> ---
> Jonathan, Yeoreum, others -
>
> By going into TPM-bypass mode, we can see how many measurements are actually
> missing when deferring IMA initialization to late_initcall_sync. As this is
> system/TPM dependent, I'd appreciate your checking. Please use the boot command
> line option "ima_policy=tcb|critical_data".
>
> thanks, Mimi
>
> security/integrity/ima/ima.h | 1 +
> security/integrity/ima/ima_init.c | 6 ++++++
> security/integrity/ima/ima_main.c | 19 +++++++++++++++++++
> 3 files changed, 26 insertions(+)
>
> diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
> index 01aae19ed365..9a1117112fb2 100644
> --- a/security/integrity/ima/ima.h
> +++ b/security/integrity/ima/ima.h
> @@ -286,6 +286,7 @@ extern bool ima_canonical_fmt;
>
> /* Internal IMA function definitions */
> int ima_init_core(bool late);
> +int ima_init_debug(bool late);
> int ima_fs_init(void);
> int ima_add_template_entry(struct ima_template_entry *entry, int violation,
> const char *op, struct inode *inode,
> diff --git a/security/integrity/ima/ima_init.c b/security/integrity/ima/ima_init.c
> index 5f335834a9bb..edd063b99685 100644
> --- a/security/integrity/ima/ima_init.c
> +++ b/security/integrity/ima/ima_init.c
> @@ -122,6 +122,12 @@ void __init ima_load_x509(void)
> }
> #endif
>
> +int __init ima_init_debug(bool late)
> +{
> + ima_add_boot_aggregate(late); /* just add an additional record */
> + return 0;
> +}
> +
> int __init ima_init_core(bool late)
> {
> int rc;
> diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c
> index 42099bfe7e43..23e669be54fc 100644
> --- a/security/integrity/ima/ima_main.c
> +++ b/security/integrity/ima/ima_main.c
> @@ -1254,6 +1254,7 @@ static int ima_kernel_module_request(char *kmod_name)
>
> #endif /* CONFIG_INTEGRITY_ASYMMETRIC_KEYS */
>
> +#define TESTING 1
> static int __init init_ima(bool late)
> {
> int error;
> @@ -1264,6 +1265,23 @@ static int __init init_ima(bool late)
> return 0;
> }
>
> +#ifdef TESTING
> + /*
> + * Initialize early, even if it means going into TPM-bypass mode,
> + * but add an additional boot_aggregrate message for the
> + * late_initcall_sync.
> + *
> + * If measurement list records exist between the boot_aggregate
> + * and the boot_aggregate_late records, these records would be
> + * missing when IMA initializion is deferred to late_initcall_sync.
> + */
> + if (ima_tpm_chip) {
I believe this should be:
if (late) {
...
}
> + ima_init_debug(late); /* Add an additional record */
> + return 0;
> + }
> +
> + ima_tpm_chip = tpm_default_chip();
> +#elif
> /*
> * If we found the TPM during our first attempt, or we know there's no
> * TPM, nothing further to do
> @@ -1276,6 +1294,7 @@ static int __init init_ima(bool late)
> pr_debug("TPM not available, will try later\n");
> return -EPROBE_DEFER;
> }
> +#endif
>
> if (!ima_tpm_chip)
> pr_info("No TPM chip found, activating TPM-bypass!\n");
> --
> 2.53.0
With above change I confirmed there is no meaurement log
between boot_aggregate and boot_aggregate_late except "kernel_version"
But this is ignorable since this UTS measurement is done in
"ima_init_core() (old: ima_init())" and it is part of ima initialisation.
1. ima_policy=tcb
# cat /sys/kernel/security/ima/ascii_runtime_measurements
10 0adefe762c149c7cec19da62f0da1297fcfbffff ima-ng sha256:0000000000000000000000000000000000000000000000000000000000000000 boot_aggregate
10 4e5d73ebadfd8f850cb93ce4de755ba148a9a7d5 ima-ng sha256:0000000000000000000000000000000000000000000000000000000000000000 boot_aggregate_late
10 7c23cc970eceec906f7a41bc2fbde770d7092209 ima-ng sha256:72ade6ae3d35cfe5ede7a77b1c0ed1d1782a899445fdcb219c0e994a084a70d5 /bin/busybox
10 17ec669c65c401e5e85875cf2962eb7d8c47595f ima-ng sha256:dc6b013e9768d9b13bcd6678470448090138ca831f4771a43ce3988d8e54ffce /lib/ld-linux-aarch64.so.1
10 58679a66ac1de17f02595625a8fbeafa259a4c81 ima-ng sha256:494f62bcfb2fcf1b427d5092fafa62c8df39a83b4a64402620b28846724f237f /usr/lib/libtirpc.so.3.0.0
10 42f74ee200434576e33be153830b3d55bbe6d2bf ima-ng sha256:a18856b4f6927bc2b8dd4608c0768b8f98544a161b85bf4a64419131243ad300 /lib/libresolv.so.2
10 626b4f7bd4f123d18d3a3d8719ed0ae19ee5f331 ima-ng sha256:b8d442de5d31c3f9d1bbb98785f04d4a23dc53442b286d85d4b355927cbe9af4 /lib/libc.so.6
10 655a200869696207646377a58cab417fd35b09d2 ima-ng sha256:ad46146b6dd32b47213e5327f1bb2f962ef838a4b707ef7445fa2dbc9019b44f /etc/inittab
10 81353202685e022fcd0069a3b2fc4eaa6b1db537 ima-ng sha256:74d698fe0a6862050af29083aa591c960ec1f67be960047e96bb6be5fc2bc0c0 /bin/mount
10 ae64184ee607ef8f3aa08ab52cb548318534fd4b ima-ng sha256:27846b57e8234c6a9611b00351f581a54ad6f9a1920b9aa18ceb0ae28e4f7564 /lib/libmount.so.1.1.0
10 5ea01f34e7705d1bdb936fd576e2aeb5fd78dab9 ima-ng sha256:3d2a414ec0355fcf0910224fb4a3c53e13d98731a35241edfdf4fb911ed9b210 /lib/libblkid.so.1.1.0
10 22c48b4853594a08a73ad4ae6dbe6f2c2bebc6c5 ima-ng sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 /run/utmp
10 3024ea5021f8a5d9fb4bd519d599bdca43b7fb93 ima-ng sha256:71ea9ffe2b30e5a9bdceff78785cf281cc41544474db8dc4605a06a597ce1edc /etc/fstab
10 2e7530a0f56420991ac7611734cea4774b92b9ef ima-ng sha256:df4697d699442cfe73db7cc8b4c1b37e8a31e75e01f66a0d70134ac812fa683b /bin/mkdir
10 3ad117a863aa1ed7b7c09e1d106f84abf7d2ae96 ima-ng sha256:c19a710989b43222431b02399273dba409fe10ca8eefff88eaa936fa695f8324 /bin/ln
10 4141c82cb516ac3c846e0b08abcd6abeee7efa1a ima-ng sha256:b75d7f28772f71715a941c77e07e3922815391dd9cc5718ad21f2231c2da09bb /etc/hostname
10 dfcedd3c7dc3ed42e09219804504489ab264e2e3 ima-ng sha256:dc1615df9f2012b20b81ffad8e07e16293039ba7fd897854ca3646d6cfea0c0f /etc/init.d/rcS
...
2. ima_policy=critical_data
# cat /sys/kernel/security/ima/ascii_runtime_measurements
10 0adefe762c149c7cec19da62f0da1297fcfbffff ima-ng sha256:0000000000000000000000000000000000000000000000000000000000000000 boot_aggregate
10 49ab61dd97ea2f759edcb6c6a3387ac67f0aa576 ima-buf sha256:0c907aab3261194f16b0c2a422a82f145bc9b9ecb8fdb633fa43e3e5379f0af2 kernel_version 372e312e302d7263312b // Ignorable since it's generated by ima_init(_core)().
10 4e5d73ebadfd8f850cb93ce4de755ba148a9a7d5 ima-ng sha256:0000000000000000000000000000000000000000000000000000000000000000 boot_aggregate_late
Therefore, init_ima() could move into late_initcall_sync like v1 did:
- https://lore.kernel.org/all/20260417175759.3191279-2-yeoreum.yun@arm.com/
Thanks.
--
Sincerely,
Yeoreum Yun
^ permalink raw reply
* [PATCH v4 2/8] arm64/runtime-const: Use aarch64_insn_patch_text_nosync() for patching
From: K Prateek Nayak @ 2026-04-30 9:47 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, Peter Zijlstra,
Sebastian Andrzej Siewior, Catalin Marinas, Will Deacon
Cc: Darren Hart, Davidlohr Bueso, André Almeida, linux-arch,
linux-kernel, linux-s390, linux-riscv, linux-arm-kernel,
K Prateek Nayak, Jisheng Zhang
In-Reply-To: <20260430094730.31624-1-kprateek.nayak@amd.com>
The current scheme to directly patch the kernel text for runtime
constants runs into the following issue with futex adapted to using
runtime constants on arm64:
Unable to handle kernel write to read-only memory at virtual address ...
The pc points to the *p assignment in the following call chain:
futex_init()
runtime_const_init(shift, __futex_shift)
__runtime_fixup_shift()
*p = cpu_to_le32(insn);
which suggests that core_initcall() is too late to patch the kernel text
directly unlike the "d_hash_shift" which is initialized during
vfs_caches_init_early() before the protections are in place.
Use aarch64_insn_patch_text_nosync() to patch the runtime constants
instead of doing it directly to allow runtime_const_init() slightly
later into the boot.
Since aarch64_insn_patch_text_nosync() calls caches_clean_inval_pou()
internally, __runtime_fixup_caches() ends up being redundant.
runtime_const_init() are rare and the overheads of multiple calls to
caches_clean_inval_pou() instead of batching them together should be
negligible in practice.
The cpu_to_le32() conversion of instruction isn't necessary since it is
handled later in the aarch64_insn_patch_text_nosync() call-chain:
aarch64_insn_patch_text_nosync(addr, insn)
aarch64_insn_write(addr, insn)
__aarch64_insn_write(addr, cpu_to_le32(insn))
Sashiko noted that aarch64_insn_patch_text_nosync() does not expect a
lm_alias() address and Catalin suggested it is safe to drop the
lm_alias() for runtime patching since the kernel text is readable. The
address passed to fixup function is interpreted as a __le32 and
dereferenced as is to read the opcode at the patch site.
No functional changes are intended.
Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com>
---
changelog v3..v4:
o Dropped the lm_alias() and use the patch location as is for
aarch64_insn_patch_text_nosync(). (Sashiko, Catalin)
---
arch/arm64/include/asm/runtime-const.h | 17 +++++------------
1 file changed, 5 insertions(+), 12 deletions(-)
diff --git a/arch/arm64/include/asm/runtime-const.h b/arch/arm64/include/asm/runtime-const.h
index c3dbd3ae68f69..838145bc289d2 100644
--- a/arch/arm64/include/asm/runtime-const.h
+++ b/arch/arm64/include/asm/runtime-const.h
@@ -7,6 +7,7 @@
#endif
#include <asm/cacheflush.h>
+#include <asm/text-patching.h>
/* Sigh. You can still run arm64 in BE mode */
#include <asm/byteorder.h>
@@ -50,34 +51,26 @@ static inline void __runtime_fixup_16(__le32 *p, unsigned int val)
u32 insn = le32_to_cpu(*p);
insn &= 0xffe0001f;
insn |= (val & 0xffff) << 5;
- *p = cpu_to_le32(insn);
-}
-
-static inline void __runtime_fixup_caches(void *where, unsigned int insns)
-{
- unsigned long va = (unsigned long)where;
- caches_clean_inval_pou(va, va + 4*insns);
+ aarch64_insn_patch_text_nosync(p, insn);
}
static inline void __runtime_fixup_ptr(void *where, unsigned long val)
{
- __le32 *p = lm_alias(where);
+ __le32 *p = where;
__runtime_fixup_16(p, val);
__runtime_fixup_16(p+1, val >> 16);
__runtime_fixup_16(p+2, val >> 32);
__runtime_fixup_16(p+3, val >> 48);
- __runtime_fixup_caches(where, 4);
}
/* Immediate value is 6 bits starting at bit #16 */
static inline void __runtime_fixup_shift(void *where, unsigned long val)
{
- __le32 *p = lm_alias(where);
+ __le32 *p = where;
u32 insn = le32_to_cpu(*p);
insn &= 0xffc0ffff;
insn |= (val & 63) << 16;
- *p = cpu_to_le32(insn);
- __runtime_fixup_caches(where, 1);
+ aarch64_insn_patch_text_nosync(p, insn);
}
static inline void runtime_const_fixup(void (*fn)(void *, unsigned long),
--
2.34.1
^ permalink raw reply related
* [PATCH v4 1/8] x86/runtime-const: Introduce runtime_const_mask_32()
From: K Prateek Nayak @ 2026-04-30 9:47 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, Peter Zijlstra,
Sebastian Andrzej Siewior, Borislav Petkov, Dave Hansen, x86
Cc: Darren Hart, Davidlohr Bueso, André Almeida, linux-arch,
linux-kernel, linux-s390, linux-riscv, linux-arm-kernel,
K Prateek Nayak, H. Peter Anvin, Thomas Huth, Sean Christopherson
In-Reply-To: <20260430094730.31624-1-kprateek.nayak@amd.com>
From: Peter Zijlstra <peterz@infradead.org>
Futex hash computation requires a mask operation with read-only after
init data that will be converted to a runtime constant in the subsequent
commit.
Introduce runtime_const_mask_32 to further optimize the mask operation
in the futex hash computation hot path.
[ prateek: Broke off the x86 chunk, commit message. ]
Link: https://patch.msgid.link/20260227161841.GH606826@noisy.programming.kicks-ass.net
Not-yet-signed-off-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: K Prateek Nayak <kprateek.nayak@amd.com>
---
changelog v3..v4:
o No changes.
---
arch/x86/include/asm/runtime-const.h | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/x86/include/asm/runtime-const.h b/arch/x86/include/asm/runtime-const.h
index 4cd94fdcb45e2..b13f7036c1c9b 100644
--- a/arch/x86/include/asm/runtime-const.h
+++ b/arch/x86/include/asm/runtime-const.h
@@ -41,6 +41,15 @@
:"+r" (__ret)); \
__ret; })
+#define runtime_const_mask_32(val, sym) ({ \
+ typeof(0u+(val)) __ret = (val); \
+ asm_inline("and $0x12345678, %k0\n1:\n" \
+ ".pushsection runtime_mask_" #sym ",\"a\"\n\t"\
+ ".long 1b - 4 - .\n" \
+ ".popsection" \
+ : "+r" (__ret)); \
+ __ret; })
+
#define runtime_const_init(type, sym) do { \
extern s32 __start_runtime_##type##_##sym[]; \
extern s32 __stop_runtime_##type##_##sym[]; \
@@ -65,6 +74,11 @@ static inline void __runtime_fixup_shift(void *where, unsigned long val)
*(unsigned char *)where = val;
}
+static inline void __runtime_fixup_mask(void *where, unsigned long val)
+{
+ *(unsigned int *)where = val;
+}
+
static inline void runtime_const_fixup(void (*fn)(void *, unsigned long),
unsigned long val, s32 *start, s32 *end)
{
--
2.34.1
^ permalink raw reply related
* [PATCH v4 0/8] futex: Use runtime constants for futex_hash computation
From: K Prateek Nayak @ 2026-04-30 9:47 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, Peter Zijlstra,
Sebastian Andrzej Siewior, Borislav Petkov, Dave Hansen, x86,
Catalin Marinas, Will Deacon, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Heiko Carstens, Vasily Gorbik, Alexander Gordeev,
Arnd Bergmann, Guo Ren
Cc: Darren Hart, Davidlohr Bueso, André Almeida, linux-arch,
linux-kernel, linux-s390, linux-riscv, linux-arm-kernel,
K Prateek Nayak, H. Peter Anvin, Thomas Huth, Sean Christopherson,
Jisheng Zhang, Alexandre Ghiti, Charlie Jenkins, Charles Mirabile,
Christian Borntraeger, Sven Schnelle
tl;dr
This series introduces runtime_const_mask_32() and uses runtime
constants for __ro_after_init data in futex_hash() hot path. More
information can be found on v2 [1].
Comments that have *not* been addressed
=======================================
Samuel had an observation on v2 that __futex_mask is always of the form
GENMASK(N, 0) /* Only lower bits set; N > 0. */
and ARM64 and RISC-V can use a single ubfx (ARM64), or slli+srli pattern
(RISC-V) for the mask operation respectively but this had the main
limitation of runtime_const_mask_32() only working with masks of such
form and others should fail runtime_const_init() at boot.
RISC-V does generated a "addi + slli" pattern with CONFIG_BASE_SMALL=y
where the futex_hash_mask is known at compile time.
The old scheme is retained for now since it is equivalent to the
generated asm for !CONFIG_BASE_SMALL and can handle any arbitrary masks
allowing for all future use cases.
If there is enough interest, please let me know, and I can look into
further optimization to runtime_const_mask_32() based on the current use
case for __futex_hash.
Testing
=======
Apart from x86, which was build and boot tested on baremetal, all the
other architectures have been build and boot tested with cross-compile +
QEMU with some light sanity testing on each.
ARM64 build was tested with CONFIG_DEBUG_VIRTUAL enabled to catch any
potential fallouts from switching runtime constant patching to use
aarch64_insn_patch_text_nosync().
Patches are based on:
git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git master
at commit 8f1aacb683ef4 ("Merge branch into tip/master: 'x86/tdx'")
(29-04-2026)
Few comments from checkpatch.pl have been ignored to adhere to the style
of the particular file. If something needs addressing, please let me
know and I'll address it in the next iteration.
Everyone has been Cc'd on the cover-letter and the futex bits for the
context. Respective arch maintainers, reviewers, and whoever got lucky
with get_maintainer.pl have been Cc'd on their respective arch specific
changes. Futex maintainers and the lists will be receiving the whole
series (sorry in advance!)
---
changelog v3..v4:
o Dropped the lm_alias() on the patching location and send the kernel
text address directly to aarch64_insn_patch_text_nosync() since the
function does not expect a lm_alias() address. (Sashiko, Catalin)
o Added Patch 4 to convert the RISC-V magic literal to a #define and use
that in the inline assembly. (Guo)
o Reverted the naming of the macro variable to __ret to prevent any
collision with the local variables at callsite. __ret seems to be the
safe convention that is followed for all runtime constant macros.
(Sashiko)
o Sashiko commented that weakly ordered architectures may see the
placeholder value of runtime constant before their initialization
which shouldn't be true.
Since these variables are initialized at early boot, the BSP should
commit all the local accesses in order which would prevent the
placeholder value from ever leaking out for weakly ordered
architectures that do not implement runtime constants.
For the architectures that do support runtime constants,
runtime_const_init() should provide adequate barrier after patching
all the call-sites.
As such, this concern is dismissed.
v3: https://lore.kernel.org/lkml/20260402112250.2138-1-kprateek.nayak@amd.com/
changelog rfc v2..v3:
o Collected Ack from Heiko for s390 bits after folding in their
suggested changes (Thanks a ton!)
o Reordered Patch 2 and Patch 3 to allow for runtime_const_init() at
late_initcall() first before introducing runtime_const_mask_32() on
ARM64. (David)
o Moved the "&" operation outside the inline asm block on ARM64 and
RISC-V which allows the compiler to optimize it further if possible.
(David)
o Dropped the RFC tag.
v2: https://lore.kernel.org/lkml/20260316052401.18910-1-kprateek.nayak@amd.com/ [1]
changelog rfc v1..rfc v2:
o Use runtime constants to avoid the dereference overheads for
dynamically allocated futex_queues.
o arch/ side plumbings for runtime_const_mask_32()
v1: https://lore.kernel.org/all/20260128101358.20954-1-kprateek.nayak@amd.com/
---
K Prateek Nayak (5):
arm64/runtime-const: Use aarch64_insn_patch_text_nosync() for patching
arm64/runtime-const: Introduce runtime_const_mask_32()
riscv/runtime-const: Replace open-coded placeholder with RUNTIME_MAGIC
riscv/runtime-const: Introduce runtime_const_mask_32()
s390/runtime-const: Introduce runtime_const_mask_32()
Peter Zijlstra (3):
x86/runtime-const: Introduce runtime_const_mask_32()
asm-generic/runtime-const: Add dummy runtime_const_mask_32()
futex: Use runtime constants for __futex_hash() hot path
arch/arm64/include/asm/runtime-const.h | 36 ++++++++++-----
arch/riscv/include/asm/runtime-const.h | 61 ++++++++++++++++++--------
arch/s390/include/asm/runtime-const.h | 22 +++++++++-
arch/x86/include/asm/runtime-const.h | 14 ++++++
include/asm-generic/runtime-const.h | 1 +
include/asm-generic/vmlinux.lds.h | 5 ++-
kernel/futex/core.c | 42 ++++++++++--------
7 files changed, 130 insertions(+), 51 deletions(-)
base-commit: 8f1aacb683ef4a49b83dcc40bfce022aaa4aa597
--
2.34.1
^ permalink raw reply
* [PATCH] arm64/hw_breakpoint: reject unaligned watchpoints that would truncate BAS
From: Breno Leitao @ 2026-04-30 9:40 UTC (permalink / raw)
To: Will Deacon, Mark Rutland, Catalin Marinas, Pratyush Anand
Cc: linux-arm-kernel, linux-perf-users, linux-kernel, clm, leo.bras,
kernel-team, Breno Leitao
hw_breakpoint_arch_parse() positions the BAS bit pattern in
hw->ctrl.len with
offset = hw->address & alignment_mask; /* 0..7 */
hw->ctrl.len <<= offset;
ctrl.len is an 8-bit bitfield (struct arch_hw_breakpoint_ctrl::len is
u32 :8), so the shift silently drops any bits past bit 7. For
non-compat AArch64 watchpoints the offset is unbounded relative to
ctrl.len: a perf_event_open(PERF_TYPE_BREAKPOINT) caller asking for
HW_BREAKPOINT_W with bp_addr=page+1 and bp_len=HW_BREAKPOINT_LEN_8
ends up with 0xff << 1 = 0x1fe, stored as 0xfe. The kernel programs
WCR.BAS=0xfe and the hardware watches bytes [1..7] instead of the
requested [1..8] -- the eighth byte is silently dropped. The
syscall still returns success, leaving userspace to discover the
gap by empirical probing.
The same class affects HW_BREAKPOINT_LEN_{2,4} when offset pushes the
high BAS bit past bit 7 (e.g. LEN_4 with offset=5 yields 0xe0
instead of 0x1e0). No memory-safety impact -- the value is masked
into 8 bits before encoding -- but debuggers and perf users observe
missed events on bytes they thought they were watching.
The AArch32 branch immediately above already rejects unrepresentable
(offset, len) combinations via an explicit switch. Mirror that for
the non-compat branch by checking that the shifted pattern fits in
the BAS field, returning -EINVAL when it does not.
Reproducer:
struct perf_event_attr a = {
.type = PERF_TYPE_BREAKPOINT, .size = sizeof(a),
.bp_type = HW_BREAKPOINT_W,
.bp_addr = (uintptr_t)(buf + 1),
.bp_len = HW_BREAKPOINT_LEN_8,
.exclude_kernel = 1, .exclude_hv = 1,
};
int fd = perf_event_open(&a, 0, -1, -1, 0);
/* before this fix: succeeds, watches 7 bytes (buf+1..buf+7) */
/* after this fix: fails with EINVAL */
Signed-off-by: Breno Leitao <leitao@debian.org>
Fixes: b08fb180bb88 ("arm64: Allow hw watchpoint at varied offset from base address")
---
arch/arm64/kernel/hw_breakpoint.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/kernel/hw_breakpoint.c b/arch/arm64/kernel/hw_breakpoint.c
index ab76b36dce820..b8a1402119f3a 100644
--- a/arch/arm64/kernel/hw_breakpoint.c
+++ b/arch/arm64/kernel/hw_breakpoint.c
@@ -559,6 +559,15 @@ int hw_breakpoint_arch_parse(struct perf_event *bp,
else
alignment_mask = 0x7;
offset = hw->address & alignment_mask;
+
+ /*
+ * BAS is an 8-bit field in WCR/BCR; the shift below would
+ * silently drop the high bits of ctrl.len when offset + len
+ * exceeds 8, programming hardware to watch fewer bytes than
+ * the user requested.
+ */
+ if (((u32)hw->ctrl.len << offset) > 0xff)
+ return -EINVAL;
}
hw->address &= ~alignment_mask;
---
base-commit: 0787c45ea08a13b5482e701fabc741877cf681f6
change-id: 20260430-arm64_bas-77e37d830226
Best regards,
--
Breno Leitao <leitao@debian.org>
^ permalink raw reply related
* Re: [PATCH 11/43] KVM: arm64: gic-v5: Make VPEs valid in vgic_v5_reset()
From: Marc Zyngier @ 2026-04-30 9:37 UTC (permalink / raw)
To: Sascha Bischoff
Cc: linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
kvm@vger.kernel.org, nd, oliver.upton@linux.dev, Joey Gouly,
Suzuki Poulose, yuzenghui@huawei.com, peter.maydell@linaro.org,
lpieralisi@kernel.org, Timothy Hayes
In-Reply-To: <20260427160547.3129448-12-sascha.bischoff@arm.com>
On Mon, 27 Apr 2026 17:09:47 +0100,
Sascha Bischoff <Sascha.Bischoff@arm.com> wrote:
>
> When resetting VPEs, also mark them as valid in the VM VPE Table. This
> is required as it informs the IRS that a specific VPE may be made
> resident, and without this the IRS will treat the VPE as invalid.
>
> As part of this change, we also introduce a wrapper around the VPE
> doorbells - vgic_v5_send_command(). This takes a struct kvm_vcpu
> pointer, and the command to run, and triggers the function bound to
> the command via that vcpu's doorbell. This is a convenience function
> to simplify the code.
>
> Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com>
> ---
> arch/arm64/kvm/vgic/vgic-v5.c | 22 ++++++++++++++++++++++
> 1 file changed, 22 insertions(+)
>
> diff --git a/arch/arm64/kvm/vgic/vgic-v5.c b/arch/arm64/kvm/vgic/vgic-v5.c
> index 0649729f6b834..92bb63b6dd6bb 100644
> --- a/arch/arm64/kvm/vgic/vgic-v5.c
> +++ b/arch/arm64/kvm/vgic/vgic-v5.c
> @@ -518,6 +518,18 @@ static int vgic_v5_irs_vpe_cr0_update(int vm_id, int vpe_id, u32 cr0)
> return 0;
> }
>
> +static int vgic_v5_send_command(struct kvm_vcpu *vcpu,
> + enum gicv5_vcpu_info_cmd_type type)
> +{
> + struct gicv5_cmd_info cmd_info;
> +
> + if (!vcpu)
> + return -EINVAL;
Drop this. If we must crash, let's crash early, in the most
spectacular way, and leaving a backtrace. Trying to gracefully handle
this stuff is making it harder to track and debug such problems.
Also, if we made it that far, it is very likely that vcpu isn't NULL.
> +
> + cmd_info.cmd_type = type;
> + return irq_set_vcpu_affinity(vgic_v5_vpe_db(vcpu), &cmd_info);
> +}
> +
> static int vgic_v5_db_set_vcpu_affinity(struct irq_data *data, void *vcpu_info)
> {
> struct vgic_v5_vm *vm = data->domain->host_data;
> @@ -691,6 +703,8 @@ static void vgic_v5_teardown_per_vm_domain(struct vgic_v5_vm *vm)
>
> void vgic_v5_reset(struct kvm_vcpu *vcpu)
> {
> + int rc;
> +
> /*
> * We always present 16-bits of ID space to the guest, irrespective of
> * the host allowing more.
> @@ -702,6 +716,14 @@ void vgic_v5_reset(struct kvm_vcpu *vcpu)
> * CPUIF (but potentially fewer in the IRS).
> */
> vcpu->arch.vgic_cpu.num_pri_bits = 5;
> +
> + /* Make the VPE valid in the VPET */
> + rc = vgic_v5_send_command(vcpu, VPE_MAKE_VALID);
> + if (rc) {
nit: rc serves no purpose here. Just write it as:
if (vgic_v5_send_command(...))
> + /* We can't continue, so mark the VM as dead */
> + kvm_vm_dead(vcpu->kvm);
> + return;
But we probably should dump some traces here, rather than silently
mark the VM as fsck'd. THis is the sign that something has gone very
wrong.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: pinctl: amlogic,pinctrl-a4: Add compatible string for A9
From: Krzysztof Kozlowski @ 2026-04-30 9:36 UTC (permalink / raw)
To: Xianwei Zhao
Cc: Linus Walleij, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
linux-amlogic, linux-gpio, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <20260428-a9-pinctrl-v1-1-cd611bb5f52d@amlogic.com>
On Tue, Apr 28, 2026 at 08:22:48AM +0000, Xianwei Zhao wrote:
> Update dt-binding document for pinctrl of Amlogic A9.
And why it is not compatible with a4 or a5? You have entire commit msg
for this.
>
> Signed-off-by: Xianwei Zhao <xianwei.zhao@amlogic.com>
> ---
> Documentation/devicetree/bindings/pinctrl/amlogic,pinctrl-a4.yaml | 1 +
> 1 file changed, 1 insertion(+)
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2] arm64: smp: Do not mark secondary CPUs possible under nosmp
From: zhangpengjie (A) @ 2026-04-30 9:34 UTC (permalink / raw)
To: Catalin Marinas
Cc: will, maz, timothy.hayes, lpieralisi, mrigendra.chaubey, arnd,
linux-arm-kernel, linux-kernel, zhanjie9, zhenglifeng1, lihuisong,
yubowen8, linhongye, linuxarm, wangzhi12
In-Reply-To: <ae9iqdt_qdJRjVZs@arm.com>
On 4/27/2026 9:20 PM, Catalin Marinas wrote:
> On Thu, Apr 23, 2026 at 09:46:54PM +0800, Pengjie Zhang wrote:
>> Under nosmp (maxcpus=0), arm64 never brings up secondary CPUs.
>>
>> However, arm64 still enumerates firmware-described CPUs during SMP
>> initialization, which can leave secondary CPUs visible to
>> for_each_possible_cpu() users even though they never reach the
>> bringup path in this configuration.
>>
>> This is not just a cosmetic mask mismatch: code iterating over
>> possible CPUs may observe secondary CPU per-CPU state that is never
>> fully initialized under nosmp.
> I'm fine with the patch in principle but I fail to see why it is not
> mostly cosmetic. If we have possible & !present CPUs (there's another
> thread around cpuhp_smt_enable() to allow this combination on arm64),
> get_cpu_device() would return NULL and the core code is supposed to
> handle this. What other per-CPU state should be initialised for a
> possible CPU but it is not without this patch?
Yes, possible-but-not-present CPUs are valid in the general hotplug
model. The nosmp/maxcpus=0 case is different though: on arm64,
smp_prepare_cpus() treats this as a UP-mandated boot and returns before
marking secondary CPUs present, so these CPUs are deliberately kept out
of the bringup path for this boot. The kind of issue I had in mind was
subsystem-owned per-CPU state where iteration follows cpu_possible_mask
but the state is populated only from CPU online/probe paths. The CPPC
nosmp issue fixed by commit 15eece6c5b05 ("ACPI: CPPC: Fix NULL pointer
dereference when nosmp is used") was the kind of mismatch I was thinking
of, although CPPC itself has already been fixed to use online CPUs where
appropriate. I agree the changelog overstates this. I can respin with a
toned-down changelog if you prefer.
^ permalink raw reply
* Re: [PATCH v4 1/3 net-next] dt-bindings: net: add st,stlc4560/p54spi binding
From: Rob Herring (Arm) @ 2026-04-30 9:25 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Christian Lamparter, Andreas Kemnade, Benoît Cousson,
Eric Dumazet, Bartosz Golaszewski, Krzysztof Kozlowski,
Johannes Berg, Jakub Kicinski, Kevin Hilman, Arnd Bergmann,
linux-kernel, linux-wireless, linux-omap, Felipe Balbi,
Rob Herring, linux-gpio, Paolo Abeni, devicetree, netdev,
David S. Miller, Roger Quadros, linux-arm-kernel, Dmitry Torokhov,
Aaro Koskinen, Tony Lindgren, Linus Walleij
In-Reply-To: <20260430081242.3686993-2-arnd@kernel.org>
On Thu, 30 Apr 2026 10:12:40 +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> The SPI version of Prism54 was sold under a couple of different
> names and supported by the Linux p54spi driver, but there was
> never a DT binding for it.
>
> Document the four known names of this device and the properties
> that are sufficient for its use on the Nokia N8x0 tablet.
>
> As I don't have this hardware or documentation for it, this is
> purely based on existing usage in the driver.
>
> Link: https://lore.kernel.org/all/e8dc9acb-6f85-e0a9-a145-d101ca6da201@gmail.com/
> Acked-by: Christian Lamparter <chunkeey@gmail.com>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> v4: renamed file to st,stlc4560, matching the primary compatible string
> require st,stlc4560 string
> ---
> .../bindings/net/wireless/st,stlc4560.yaml | 61 +++++++++++++++++++
> MAINTAINERS | 1 +
> 2 files changed, 62 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/wireless/st,stlc4560.yaml
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/net/wireless/st,stlc4560.yaml: $id: Cannot determine base path from $id, relative path/filename doesn't match actual path or filename
$id: http://devicetree.org/schemas/net/wireless/st,stlc45xx.yaml
file: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/net/wireless/st,stlc4560.yaml
doc reference errors (make refcheckdocs):
Warning: MAINTAINERS references a file that doesn't exist: Documentation/devicetree/bindings/net/wireless/st,stlc45xx.yaml
MAINTAINERS: Documentation/devicetree/bindings/net/wireless/st,stlc45xx.yaml
See https://patchwork.kernel.org/project/devicetree/patch/20260430081242.3686993-2-arnd@kernel.org
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* Re: [PATCH 5/5] arm_mpam: detect and enable MPAM-Fb PCC support
From: Andre Przywara @ 2026-04-30 9:20 UTC (permalink / raw)
To: Sudeep Holla
Cc: Lorenzo Pieralisi, Hanjun Guo, Catalin Marinas, Will Deacon,
Rafael J . Wysocki, Len Brown, James Morse, Ben Horgan,
Reinette Chatre, Fenghua Yu, Jonathan Cameron, linux-acpi,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260430-brave-hoatzin-of-fascination-e7d4ad@sudeepholla>
Hi Sudeep,
thanks for having a look!
On 4/30/26 10:35, Sudeep Holla wrote:
> On Wed, Apr 29, 2026 at 04:13:39PM +0200, Andre Przywara wrote:
>> The Arm MPAM-Fb specification [1] describes a protocol to access MSC
>> registers through a firmware interface. This requires a shared memory
>> region to hold the message, and a mailbox to trigger the access.
>> For ACPI this is wrapped as a PCC channel, described using existing
>> ACPI abstractions.
>>
>> Add code to parse those PCC table descriptions associated with an MSC,
>> and store the parsed information in the MSC struct.
>> This will be used by the MPAM-Fb access wrapper code.
>>
>> [1] https://developer.arm.com/documentation/den0144/latest
>>
>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>> ---
>> drivers/acpi/arm64/mpam.c | 2 ++
>> drivers/resctrl/mpam_devices.c | 46 +++++++++++++++++++++++++++++++---
>> 2 files changed, 45 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/acpi/arm64/mpam.c b/drivers/acpi/arm64/mpam.c
>> index 99c2bdbb3314..edb4d10e8dc3 100644
>> --- a/drivers/acpi/arm64/mpam.c
>> +++ b/drivers/acpi/arm64/mpam.c
>> @@ -341,6 +341,8 @@ static struct platform_device * __init acpi_mpam_parse_msc(struct acpi_mpam_msc_
>> } else if (iface == MPAM_IFACE_PCC) {
>> props[next_prop++] = PROPERTY_ENTRY_U32("pcc-channel",
>> tbl_msc->base_address);
>> + props[next_prop++] = PROPERTY_ENTRY_U32("msc-id",
>> + tbl_msc->identifier);
>
> I may be looking at the wrong documents, but neither DEN0065 nor DEN0144 carry
> any definitions of pcc-channel and msc-id for the device with HID
> "“ARMHAA5C". Since "pcc-channel" is already merged, I think I am looking at
> wrong documents, please point me to the right one.
Please excuse my ignorance, but I was under the assumption that the
strings used here are just unique identifiers that need to match the
property_get calls in the MPAM code. Is there any requirement to match
those property_entry.name fields with the names given in some spec? And
those strings are kernel-internal only, right? But for DT would match
exactly the property names?
Those properties correspond to fields in table 4 in DEN0065, as also
described in struct acpi_mpam_msc_node in include/acpi/actbl2.h:
- There is "Identifier", that uses distinct IDs for PCC and native MSCs.
I named it msc-id, because I'd assume that to be a good name for any
(yet to be defined) DT property.
- Then there is "Base address", which doubles as the "subspace ID of the
PCC channel", when MPAM-Fb is used. As you mentioned, this is already
in, and the original spec name would be very misleading, I think.
So shall those strings be renamed to match the struct names? Or shall I
keep the more readable names as of now, and add comments linking them to
the spec/struct?
Cheers,
Andre
^ permalink raw reply
* Re: [PATCH 1/2] firmware: arm_scmi: imx: Support getting reset reason of MISC protocol
From: Sudeep Holla @ 2026-04-30 9:13 UTC (permalink / raw)
To: Peng Fan (OSS)
Cc: Cristian Marussi, Frank Li, Sascha Hauer, Sudeep Holla,
Pengutronix Kernel Team, Fabio Estevam, arm-scmi, imx,
linux-arm-kernel, linux-kernel, Peng Fan
In-Reply-To: <20260318-savvy-courageous-mule-b3f9ae@sudeepholla>
On Wed, Mar 18, 2026 at 03:25:03PM +0000, Sudeep Holla wrote:
> On Thu, Mar 05, 2026 at 09:56:44AM +0800, Peng Fan (OSS) wrote:
> > From: Peng Fan <peng.fan@nxp.com>
> >
> > MISC protocol supports getting reset reason per Logical Machine or
> > System. Add the API for user to retrieve the information from System
> > Manager.
> >
>
> Sorry for missing this earlier. It looks good though my usual rant is that
> this MISC protocol is becoming never ending dumping ground for all sorts of
> info you want kernel to dump in dmesg. Anyways, I am not too bothered as it
> is not any user ABI.
>
> If, you plan to ask i.MX maintainers to pick this up,
>
> Reviewed-by: Sudeep Holla <sudeep.holla@kernel.org>
>
> If not, I need their ack for 2/2/
>
I have left it in my -next queue assuming I would get ack if I need to take
it. But I haven't received any, so not sure if I need to take it or drop it
assuming it will go via i.MX tree ?
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH 1/8] KVM: arm64: Make EL2 exception entry and exit context-synchronization events
From: Will Deacon @ 2026-04-30 9:07 UTC (permalink / raw)
To: Fuad Tabba
Cc: maz, oliver.upton, james.morse, suzuki.poulose, yuzenghui,
qperret, vdonnefort, catalin.marinas, linux-arm-kernel, kvmarm,
linux-kernel, stable
In-Reply-To: <20260428103008.696141-2-tabba@google.com>
On Tue, Apr 28, 2026 at 11:30:01AM +0100, Fuad Tabba wrote:
> SCTLR_EL2.EIS and SCTLR_EL2.EOS control whether exception entry and
> exit at EL2 are Context Synchronisation Events (CSEs). Per ARM DDI
> 0487 M.b, EIS is governed by D1.4.2 rule RBBSRF (p. D1-7205) and EOS
> by D1.4.4.1 rule RBWCFK (p. D1-7209). D24.2.175 (p. D24-9754):
>
> - !FEAT_ExS: the bit is RES1, so the entry/exit is unconditionally
> a CSE.
> - FEAT_ExS: the reset value is architecturally UNKNOWN; software
> must set the bit to make the entry/exit a CSE.
>
> INIT_SCTLR_EL2_MMU_ON in arch/arm64/include/asm/sysreg.h sets neither
> bit. KVM/arm64 hot paths rely on ERET from EL2 being a CSE, and on
> synchronous EL1->EL2 entry being a CSE, to elide explicit ISBs after
> MSRs to context-switching system registers (HCR_EL2, HFGxTR_EL2,
> HCRX_EL2, ZCR_EL2, CPACR_EL1, CPTR_EL2, SCTLR_EL1, ptrauth keys,
> etc.); examples include the activate-traps path,
> ptrauth_switch_to_guest, and the FPSIMD trap re-enable in
> kvm_hyp_handle_fpsimd. On FEAT_ExS hardware those reliances are not
> architecturally backed unless EOS=1 (and, for entry, EIS=1), and
> whether they hold today depends on firmware initialisation outside
> the kernel's control.
>
> Make the guarantee explicit: include SCTLR_ELx_EIS | SCTLR_ELx_EOS in
> INIT_SCTLR_EL2_MMU_ON so that EL2 exception entry and exit are
> unconditionally CSEs regardless of whether FEAT_ExS is implemented.
> This matches the pairing in arch/arm64/kvm/config.c which treats EIS
> and EOS together as RES1 under !FEAT_ExS.
>
> INIT_SCTLR_EL2_MMU_OFF is left unchanged: that path is used during
> very early EL2 init and the EL2 MMU-off transition, neither of which
> relies on these bits in the same way.
>
> Fixes: fe2c8d19189e ("KVM: arm64: Turn SCTLR_ELx_FLAGS into INIT_SCTLR_EL2_MMU_ON")
I don't think this Fixes: tag is accurate:
1. That commit doesn't do anything with EIS/EOS afaict.
2. Back in 5.12 (when that thing landed), SCTLR_EL2_RES1 did actually
include EIS and EOS
so I think the issue here might be that the auto-generated sysreg file
quietly changes the RES1 definitions as bits get allocated, but the
macros using the RES1 definition don't get updated. That's a pretty
horrible pit that it feels like we might keep falling into :/
Looking at 0a35bd285f43 ("arm64: Convert SCTLR_EL2 to sysreg
infrastructure"), I think we ended up dropping a whole bunch of fields
from the RES1 mask (which became 0!). Have you checked all of those?
Will
^ permalink raw reply
* [PATCHv3] arch: arm64: fix KERNEL_SEGMENT_COUNT error
From: zhaoyang.huang @ 2026-04-30 8:58 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Ard Biesheuvel, linux-arm-kernel,
linux-kernel, Zhaoyang Huang, steve.kang
From: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
During debug of a kernel panic, we find that the pte_t of the final
part of [data, end] segment got overflow to the next page of
init_pg_end[1] which is the gap page before early_init_stack[2].
This should be introduced by the KERNEL_SEGMENT_COUNT's value is 5
which should be 6 as map_segment are called 6 times for the segments
of (text, stext, rodata, inittext, initdata, data+bss)
[1]
crash_arm64_v9.0.1> vtop ffffffed00601000
VIRTUAL PHYSICAL
ffffffed00601000 83401000
PAGE DIRECTORY: ffffffecffd62000
PGD: ffffffecffd62da0 => 10000000833fb003
PMD: ffffff80033fb018 => 10000000833fe003
PTE: ffffff80033fe008 => 68000083401f03
PAGE: 83401000
PTE PHYSICAL FLAGS
68000083401f03 83401000 (VALID|SHARED|AF|NG|PXN|UXN)
PAGE PHYSICAL MAPPING INDEX CNT FLAGS
fffffffec00d0040 83401000 0 0 1 4000 reserved
[2]
ffffffed002c8000 (r) __pi__data
ffffffed0054e000 (d) __pi___bss_start
ffffffed005f5000 (b) __pi_init_pg_dir
ffffffed005fe000 (b) __pi_init_pg_end
ffffffed005ff000 (B) early_init_stack
ffffffed00608000 (b) __pi__end
Fixes: 5973a62efa34 ("arm64: map [_text, _stext) virtual address range non-executable+read-only")
Assisted-by: TRAE: GLM-5.1
Suggested-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
---
Patchv2: make the size of vmlinux_reg[] more reasonable
Patchv3: use extra value of 2 to meet the final segments count
---
---
arch/arm64/include/asm/kernel-pgtable.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/kernel-pgtable.h b/arch/arm64/include/asm/kernel-pgtable.h
index 74a4f738c5f5..f6aed326e1ce 100644
--- a/arch/arm64/include/asm/kernel-pgtable.h
+++ b/arch/arm64/include/asm/kernel-pgtable.h
@@ -68,7 +68,9 @@
#define KERNEL_SEGMENT_COUNT 5
#if SWAPPER_BLOCK_SIZE > SEGMENT_ALIGN
-#define EARLY_SEGMENT_EXTRA_PAGES (KERNEL_SEGMENT_COUNT + 1)
+
+/* [_text, _stext) is mapped separately which consume 1 extra page */
+#define EARLY_SEGMENT_EXTRA_PAGES (KERNEL_SEGMENT_COUNT + 2)
/*
* The initial ID map consists of the kernel image, mapped as two separate
* segments, and may appear misaligned wrt the swapper block size. This means
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v2 3/6] regulator: dt-bindings: mt6359: Deprecate bogus vcn33_[12]_* split regulators
From: Krzysztof Kozlowski @ 2026-04-30 8:58 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Mark Brown, Liam Girdwood, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
linux-arm-kernel, linux-mediatek, devicetree
In-Reply-To: <20260429074113.3720271-4-wenst@chromium.org>
On Wed, Apr 29, 2026 at 03:41:09PM +0800, Chen-Yu Tsai wrote:
> vcn33_[12]_bt and vcn33_[12]_wifi refer to the same output. There are
> two enable bits in the registers so that BT and WiFi drivers can toggle
> them separately without any coordination. If either bit is set, then the
> regulator output is enabled.
>
> Deprecate the existing regulators, and add proper regulators matching
> the outputs: vcn33_1 and vcn33_2.
>
> Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
> ---
> Changes since v1:
> - deprecate the bogus regulators and add proper ones, instead of
> removing one and keeping the other
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 43/43] Documentation: KVM: Add the VGICv5 IRS save/restore sequences
From: Peter Maydell @ 2026-04-30 8:57 UTC (permalink / raw)
To: Sascha Bischoff
Cc: linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
kvm@vger.kernel.org, nd, maz@kernel.org, oliver.upton@linux.dev,
Joey Gouly, Suzuki Poulose, yuzenghui@huawei.com,
lpieralisi@kernel.org, Timothy Hayes
In-Reply-To: <20260427160547.3129448-44-sascha.bischoff@arm.com>
On Mon, 27 Apr 2026 at 17:22, Sascha Bischoff <Sascha.Bischoff@arm.com> wrote:
>
> When saving/restoring the state of the GICv5 IRS, it is important that
> it happens in the correct order. Failure to do so will almost
> certainly result in failing to restore a guest that is capable of
> handling interrupts correctly.
>
> On a save, the ISTs must be saved prior to saving the guest's memory
> as the guest's LPI IST is written to guest memory. Conversely, on
> restore the guest's memory must be restored prior to restoring the
> ISTs.
>
> It is important to restore the IRS MMIO registers by first restoring
> the IRS_IDx registers as they define the capabilities of the IRS, and
> are used as part of creating and managing ISTs and SPIs.
>
> In order to restore the ISTs themselves, the IRS_IST_CFGR must be
> restored prior to the IRS_IST_BASER. This is because KVM extracts
> fields from the CFGR to determine the size and structure of the IRS
> created by the guest. The IST itself is created as part of the write
> to the IRS_IST_BASER. At this stage the remaining MMIO registers can
> be restored.
>
> Once the LPI IST has been created (by the aforementioned write to the
> IRS_IST_BASER), the IST state can be restored using
> KVM_DEV_ARM_VGIC_GRP_IST. The SPI IST gets extracted from a userspace
> provided buffer, and is transferred to the host-allocated SPI IST. The
> LPI IST is extracted from guest memory, and is written to the
> host-allocated LPI IST.
>
> As a general rule, the IRS_*_STATUSR registers can be ignored on
> restore. They are not userspace writable.
>
> Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com>
> ---
> .../virt/kvm/devices/arm-vgic-v5.rst | 63 +++++++++++++++++++
> 1 file changed, 63 insertions(+)
>
> diff --git a/Documentation/virt/kvm/devices/arm-vgic-v5.rst b/Documentation/virt/kvm/devices/arm-vgic-v5.rst
> index 38eef7cc63e3e..1c55f5040757d 100644
> --- a/Documentation/virt/kvm/devices/arm-vgic-v5.rst
> +++ b/Documentation/virt/kvm/devices/arm-vgic-v5.rst
> @@ -201,3 +201,66 @@ Groups:
> -ENOMEM Restoring IST state failed while tracking pending interrupts
> -ETIMEDOUT An IRS save/VM operation timed out
> =========== ============================================================
> +
> +IRS Save Sequence:
> +------------------
> +
> +The following ordering should be followed when saving the virtual GICv5 and
> +IRS:
> +
> +a) Save the ISTs by issuing KVM_GET_DEVICE_ATTR on KVM_DEV_ARM_VGIC_GRP_IST.
> + This MUST happen before the guest's memory is serialised as the LPI IST is
> + stored directly to guest memory.
> +
> +b) Save the IRS MMIO register state in the following order by issuing
> + KVM_GET_DEVICE_ATTR on KVM_DEV_ARM_VGIC_GRP_IRS_REGS:
> +
> + 1. Save IRS_IDR0-2 and IRS_IDR5-7 registers.
> + 2. Save IRS_IST_CFGR.
> + 3. Save IRS_IST_BASER.
> + 4. Save the remaining global IRS MMIO registers.
> + 5. For each PE:
> + - write IRS_PE_SELR
> + - save IRS_PE_CR0
> + 6. For each SPI:
> + - write IRS_SPI_SELR
> + - save IRS_SPI_CFGR
> +
> +IRS Restore Sequence:
> +---------------------
> +
> +The following ordering must be followed when restoring the virtual GICv5 and
> +IRS:
> +
> +a) restore all guest memory and create vcpus
> +b) provide the IRS base address by issuing KVM_SET_DEVICE_ATTR on
> + KVM_DEV_ARM_VGIC_GRP_ADDR
> +c) initialise the GIC - this sets up the default state and creates the SPI
> + IST - by issuing KVM_SET_DEVICE_ATTR on KVM_DEV_ARM_VGIC_GRP_CTRL with
> + KVM_DEV_ARM_VGIC_CTRL_INIT
This isn't going to work for QEMU, if I understand it correctly.
QEMU always creates the whole VM first, including creating the
VCPUs and GIC, telling KVM what its base address is, initializing it,
etc, before it starts an inbound migration. So the memory read
is going to come in after step (c), not right at the start.
> +d) restore the IRS MMIO register state in the following order by issuing
> + KVM_SET_DEVICE_ATTR on KVM_DEV_ARM_VGIC_GRP_IRS_REGS:
> +
> + 1. Restore IRS_IDR0-2 and IRS_IDR5-7 registers.
> + 2. Restore IRS_IST_CFGR.
> + 3. Restore IRS_IST_BASER - this triggers KVM to create the LPI IST.
> +
> +e) restore the ISTs by issuing KVM_SET_DEVICE_ATTR on
> + KVM_DEV_ARM_VGIC_GRP_IST.
> +f) restore the remaining IRS MMIO register state in the following order by
> + issuing KVM_SET_DEVICE_ATTR on KVM_DEV_ARM_VGIC_GRP_IRS_REGS:
> +
> + 1. Restore the remaining global IRS MMIO registers.
> + 2. For each PE:
> + - write IRS_PE_SELR
> + - restore IRS_PE_CR0
> + 3. For each SPI:
> + - write IRS_SPI_SELR
> + - restore IRS_SPI_CFGR
More generally, if your API involves this much in the way
of complicated ordering dependencies, it's going to be
very bug prone. From userspace's perspective, this is
not a very helpful way to design the interface :-)
thanks
-- PMM
^ permalink raw reply
* [PATCH net-next] net: airoha: configure QoS channel for HW accelerated flowtable traffic
From: Lorenzo Bianconi @ 2026-04-30 8:47 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Lorenzo Bianconi
Cc: Simon Horman, linux-arm-kernel, linux-mediatek, netdev
As done for the SW path, configure the QoS channel for HW accelerated
traffic according to the user port index when forwarding to a DSA port,
or rely on the GDM port identifier otherwise. This allows HTB shaping
to be applied to HW accelerated traffic.
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/ethernet/airoha/airoha_ppe.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/airoha/airoha_ppe.c b/drivers/net/ethernet/airoha/airoha_ppe.c
index 5c9dff6bccd1..e833c50ac35f 100644
--- a/drivers/net/ethernet/airoha/airoha_ppe.c
+++ b/drivers/net/ethernet/airoha/airoha_ppe.c
@@ -334,7 +334,7 @@ static int airoha_ppe_foe_entry_prepare(struct airoha_eth *eth,
info.wcid);
} else {
struct airoha_gdm_port *port = netdev_priv(dev);
- u8 pse_port;
+ u8 pse_port, channel;
if (!airoha_is_valid_gdm_port(eth, port))
return -EINVAL;
@@ -347,6 +347,14 @@ static int airoha_ppe_foe_entry_prepare(struct airoha_eth *eth,
* loopback
*/
+ /* For traffic forwarded to DSA devices select QoS
+ * channel according to the DSA user port index, rely
+ * on port id otherwise.
+ */
+ channel = dsa_port >= 0 ? dsa_port : port->id;
+ channel = channel % AIROHA_NUM_QOS_CHANNELS;
+ qdata |= FIELD_PREP(AIROHA_FOE_CHANNEL, channel);
+
val |= FIELD_PREP(AIROHA_FOE_IB2_PSE_PORT, pse_port) |
AIROHA_FOE_IB2_PSE_QOS;
/* For downlink traffic consume SRAM memory for hw
---
base-commit: 28df22acc2751abf6e6316a9f1f9cd422741bd03
change-id: 20260430-airoha-ppe-qos-channel-23a4132a80aa
Best regards,
--
Lorenzo Bianconi <lorenzo@kernel.org>
^ permalink raw reply related
* [PATCH] arm64: Fix garbled logs caused by race between multiple stack traces
From: David Sauerwein @ 2026-04-30 8:47 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Mark Rutland
Cc: linux-kernel, linux-arm-kernel, nh-open-source, David Sauerwein
When multiple stack traces are printed at the same time, the lines that
contain register values may get split into multiple separate lines.
Some stray empty lines may appear as well.
[ 2013.814455] ------------[ cut here ]------------
[ 2013.814455] ------------[ cut here ]------------
[ 2013.814459] WARNING: CPU: 12 PID: 626 at src/arch/arm64/kvm/../../../virt/kvm/kvm_main.c:3860 mark_page_dirty_in_slot+0x5c/0xd8
[ 2013.814457] WARNING: CPU: 3 PID: 620 at src/arch/arm64/kvm/../../../virt/kvm/kvm_main.c:3860 mark_page_dirty_in_slot+0x5c/0xd8
[...]
[ 2013.814483] x29: ffff8000873b3b10
[ 2013.814484] x29: ffff800083fd3b10
[ 2013.814484] x28: ffff00001d71e300 x27: 0000000000000001
[ 2013.814486] x26: ffff800080c63b80 x25: ffff800080c63000
[ 2013.814487] x28: ffff00001d71a100 x27: 0000000000000001
[ 2013.814488] x24: 0000000000401b14
[ 2013.814489]
[ 2013.814489] x26: ffff800080f5bb80 x25: ffff800080f5b000
[ 2013.814491]
[ 2013.814491] x23: ffff0000117b2000 x22: ffff00001e22bd88 x21: 0000ff9cc1b14000
[ 2013.814493] x24: 0000000000402230
[ 2013.814494]
[ 2013.814495] x20: ffff800080c63000
[ 2013.814495] x23: ffff00001d916f00
[ 2013.814496] x19: 0000000000000000 x18: ffff8000808c1660
[ 2013.814497] x17: 0000000000000000
[...]
(Example observed on v6.6 based kernel)
This happens because __show_regs uses pr_cont. The two threads printing
the traces race when printing partial register lines.
While the lines of the stack traces may still interleave, the individual
lines printing up to 3 register values should not be split. To fix this,
buffer the output and print all registers in a single printk instead of
using pr_cont.
Assisted-by: Kiro:claude-opus-4.6
Signed-off-by: David Sauerwein <dssauerw@amazon.de>
---
arch/arm64/kernel/process.c | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index 033643cd4e5ed..27779539e3b4f 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -235,12 +235,22 @@ void __show_regs(struct pt_regs *regs)
i = top_reg;
while (i >= 0) {
- printk("x%-2d: %016llx", i, regs->regs[i]);
+ /*
+ * Buffer is big enough to hold the output for 3 register
+ * plus some extra.
+ */
+ char buf[80];
+ int len;
+
+ len = scnprintf(buf, sizeof(buf), "x%-2d: %016llx",
+ i, regs->regs[i]);
while (i-- % 3)
- pr_cont(" x%-2d: %016llx", i, regs->regs[i]);
+ len += scnprintf(buf + len, sizeof(buf) - len,
+ " x%-2d: %016llx",
+ i, regs->regs[i]);
- pr_cont("\n");
+ printk("%s\n", buf);
}
}
--
2.47.3
Amazon Web Services Development Center Germany GmbH
Tamara-Danz-Str. 13
10243 Berlin
Geschaeftsfuehrung: Christof Hellmis, Andreas Stieger
Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
Sitz: Berlin
Ust-ID: DE 365 538 597
^ permalink raw reply related
* Re: [PATCH 10/43] KVM: arm64: gic-v5: Implement VPE IRS MMIO Ops
From: Marc Zyngier @ 2026-04-30 8:46 UTC (permalink / raw)
To: Sascha Bischoff
Cc: linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
kvm@vger.kernel.org, nd, oliver.upton@linux.dev, Joey Gouly,
Suzuki Poulose, yuzenghui@huawei.com, peter.maydell@linaro.org,
lpieralisi@kernel.org, Timothy Hayes
In-Reply-To: <20260427160547.3129448-11-sascha.bischoff@arm.com>
On Mon, 27 Apr 2026 17:09:27 +0100,
Sascha Bischoff <Sascha.Bischoff@arm.com> wrote:
>
> Introduce interfaces to make VPEs valid, and to configure them, via
> the host's IRS. As with the other valid bits in the GICv5 VM tables,
> VPEs cannot be made valid directly, and instead are made valid via an
> IRS MMIO Op.
>
> Additionally, some of the VPE configuration takes place via the IRS
> MMIO interface too (via the IRS_VPE_CR0, IRS_VPE_DBR). VPE doorbells
> are, for example, configured via this interface.
>
> The existing VPE-doorbell-based commands are extended with:
>
> VPE_MAKE_VALID - Make the VPE valid in the VPET
> VPE_CR0_READ - Handle a guest read from IRS_PE_CR0
> VPE_CR0_WRITE - Handle a guest write to IRS_PE_CR0
>
> Note: There is no VPE_MAKE_INVALID as VPEs are only made invalid on
> teardown, at which point the whole VMTE is marked as invalid. Hence,
> it is not required.
>
> Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com>
> ---
> arch/arm64/kvm/vgic/vgic-v5.c | 164 +++++++++++++++++++++++++++++
> include/linux/irqchip/arm-gic-v5.h | 27 +++++
> 2 files changed, 191 insertions(+)
>
> diff --git a/arch/arm64/kvm/vgic/vgic-v5.c b/arch/arm64/kvm/vgic/vgic-v5.c
> index 49eb01ca07961..0649729f6b834 100644
> --- a/arch/arm64/kvm/vgic/vgic-v5.c
> +++ b/arch/arm64/kvm/vgic/vgic-v5.c
> @@ -253,6 +253,25 @@ static int vgic_v5_irs_wait_for_vm_op(void)
> return 0;
> }
>
> +/* Wait for completion of an VPE_STATUSR change */
> +static int vgic_v5_irs_wait_for_vpe_op(void)
> +{
> + int ret;
> + u32 statusr;
> +
> + ret = readl_relaxed_poll_timeout_atomic(
> + irs_base + GICV5_IRS_VPE_STATUSR, statusr,
> + FIELD_GET(GICV5_IRS_VPE_STATUSR_IDLE, statusr), 1,
> + USEC_PER_SEC);
Formatting.
> +
> + if (ret == -ETIMEDOUT) {
> + pr_err_ratelimited("Time out waiting for IRS VPE Op\n");
> + return ret;
> + }
> +
> + return 0;
You seem to have a number of these primitives. Consider having a
generic helper that takes the required parameters, including a partial
string in case of error.
> +}
> +
> static int vgic_v5_irs_assign_vmt(bool two_level, u8 vm_id_bits, phys_addr_t vmt_base)
> {
> u64 vmt_baser;
> @@ -369,10 +388,142 @@ static int vgic_v5_irs_set_vist_invalid(int vm_id, bool spi_ist)
> return __vgic_v5_irs_update_vist_validity(vm_id, spi_ist, true);
> }
>
> +static int vgic_v5_irs_set_up_vpe(int vm_id, int vpe_id, irq_hw_number_t db_hwirq)
> +{
> + u64 vmap_vper, dbr, selr;
> + u32 statusr, cr0;
> + int ret;
> +
> + guard(raw_spinlock)(&vm_config_lock);
> +
> + /* Make sure that we are idle to begin with */
> + ret = vgic_v5_irs_wait_for_vm_op();
> + if (ret)
> + return ret;
> +
> + /* Mark the VPE as valid */
> + vmap_vper = FIELD_PREP(GICV5_IRS_VMAP_VPER_VPE_ID, vpe_id) |
> + FIELD_PREP(GICV5_IRS_VMAP_VPER_VM_ID, vm_id) |
> + FIELD_PREP(GICV5_IRS_VMAP_VPER_M, true);
That's another of these single bit mask used with FIELD_PREP. Consider
rewriting it as:
vmap_vper = FIELD_PREP(GICV5_IRS_VMAP_VPER_VPE_ID, vpe_id) |
FIELD_PREP(GICV5_IRS_VMAP_VPER_VM_ID, vm_id) |
GICV5_IRS_VMAP_VPER_M;
> + irs_writeq_relaxed(vmap_vper, GICV5_IRS_VMAP_VPER);
> +
> + /* Wait for the VPE to be marked valid in the VPET */
> + ret = vgic_v5_irs_wait_for_vm_op();
> + if (ret)
> + return ret;
> +
> + selr = FIELD_PREP(GICV5_IRS_VPE_SELR_VPE_ID, vpe_id) |
> + FIELD_PREP(GICV5_IRS_VPE_SELR_VM_ID, vm_id) |
> + FIELD_PREP(GICV5_IRS_VPE_SELR_S, true);
> + irs_writeq_relaxed(selr, GICV5_IRS_VPE_SELR);
> +
> + ret = vgic_v5_irs_wait_for_vpe_op();
> + if (ret)
> + return ret;
> +
> + statusr = irs_readl_relaxed(GICV5_IRS_VPE_STATUSR);
> + if (!FIELD_GET(GICV5_IRS_VPE_STATUSR_V, statusr))
> + return -EINVAL;
> +
> + /* Set targeted only routing (disable 1ofN vPE selection) */
> + cr0 = FIELD_PREP(GICV5_IRS_VPE_CR0_DPS, true);
> + irs_writel_relaxed(cr0, GICV5_IRS_VPE_CR0);
> +
> + ret = vgic_v5_irs_wait_for_vpe_op();
> + if (ret)
> + return ret;
> +
> + statusr = irs_readl_relaxed(GICV5_IRS_VPE_STATUSR);
> + if (FIELD_GET(GICV5_IRS_VPE_STATUSR_F, statusr))
> + ret = -EINVAL;
> +
> + /*
> + * The VPE has not yet run. Therefore, make sure that all interrupts
> + * will generate a doorbell.
> + */
> + dbr = FIELD_PREP(GICV5_IRS_VPE_DBR_LPI_ID, db_hwirq) |
> + FIELD_PREP(GICV5_IRS_VPE_DBR_DBPM, 0b11111) |
> + FIELD_PREP(GICV5_IRS_VPE_DBR_REQ_DB, false) |
And anything that set to false can be removed altogether.
> + FIELD_PREP(GICV5_IRS_VPE_DBR_DBV, true);
> + irs_writeq_relaxed(dbr, GICV5_IRS_VPE_DBR);
> +
> + ret = vgic_v5_irs_wait_for_vpe_op();
> + if (ret)
> + return ret;
> +
> + statusr = irs_readl_relaxed(GICV5_IRS_VPE_STATUSR);
> + if (FIELD_GET(GICV5_IRS_VPE_STATUSR_F, statusr))
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> +static int vgic_v5_irs_vpe_cr0_read(int vm_id, int vpe_id, u64 *cr0)
> +{
> + u32 statusr;
> + u64 selr;
> + int ret;
> +
> + guard(raw_spinlock)(&vm_config_lock);
> +
> + selr = FIELD_PREP(GICV5_IRS_VPE_SELR_VPE_ID, vpe_id) |
> + FIELD_PREP(GICV5_IRS_VPE_SELR_VM_ID, vm_id) |
> + FIELD_PREP(GICV5_IRS_VPE_SELR_S, true);
> + irs_writeq_relaxed(selr, GICV5_IRS_VPE_SELR);
> +
> + ret = vgic_v5_irs_wait_for_vpe_op();
> + if (ret)
> + return ret;
> +
> + statusr = irs_readl_relaxed(GICV5_IRS_VPE_STATUSR);
> + if (!FIELD_GET(GICV5_IRS_VPE_STATUSR_V, statusr))
> + return -EINVAL;
> +
> + *cr0 = irs_readl_relaxed(GICV5_IRS_VPE_CR0);
> +
> + return 0;
I'd rather this function returned the CR0 value directly, even if the
IDLE bit isn't set. You can have a WARN_ONCE() if you want.
> +}
> +
> +static int vgic_v5_irs_vpe_cr0_update(int vm_id, int vpe_id, u32 cr0)
*_write() would be better than *_update() when you already have
*_read(). Specially as a consequence of VPE_CR0_WRITE.
> +{
> + u32 statusr;
> + u64 selr;
> + int ret;
> +
> + guard(raw_spinlock)(&vm_config_lock);
> +
> + selr = FIELD_PREP(GICV5_IRS_VPE_SELR_VPE_ID, vpe_id) |
> + FIELD_PREP(GICV5_IRS_VPE_SELR_VM_ID, vm_id) |
> + FIELD_PREP(GICV5_IRS_VPE_SELR_S, true);
> + irs_writeq_relaxed(selr, GICV5_IRS_VPE_SELR);
> +
> + ret = vgic_v5_irs_wait_for_vpe_op();
> + if (ret)
> + return ret;
> +
> + statusr = irs_readl_relaxed(GICV5_IRS_VPE_STATUSR);
> + if (!FIELD_GET(GICV5_IRS_VPE_STATUSR_V, statusr))
> + return ret;
return 0? But you have set SELR to something. Surely reading V==0
here is an indication of a bug. So should you report the error? Warn?
> +
> + irs_writel_relaxed(cr0, GICV5_IRS_VPE_CR0);
> +
> + ret = vgic_v5_irs_wait_for_vpe_op();
> + if (ret)
> + return ret;
> +
> + statusr = irs_readl_relaxed(GICV5_IRS_VPE_STATUSR);
> + if (FIELD_GET(GICV5_IRS_VPE_STATUSR_F, statusr))
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> static int vgic_v5_db_set_vcpu_affinity(struct irq_data *data, void *vcpu_info)
> {
> struct vgic_v5_vm *vm = data->domain->host_data;
> struct gicv5_cmd_info *cmd_info = vcpu_info;
> + /* Our VPE ID is the index within the doorbell domain */
> + u16 vpe_id = data->hwirq;
>
> switch (cmd_info->cmd_type) {
> case VMT_L2_MAP:
> @@ -381,6 +532,19 @@ static int vgic_v5_db_set_vcpu_affinity(struct irq_data *data, void *vcpu_info)
> return vgic_v5_irs_set_vm_valid(vm->vm_id);
> case VMTE_MAKE_INVALID:
> return vgic_v5_irs_set_vm_invalid(vm->vm_id);
> + case VPE_MAKE_VALID:
> + /*
> + * We need the actual LPI ID which lives in the top-most parent
> + * domain. This hwirq won't include the type (LPI) but that's
> + * not required for the IRS_VPE_DBR.
> + */
> + while (data->parent_data != NULL)
> + data = data->parent_data;
> + return vgic_v5_irs_set_up_vpe(vm->vm_id, vpe_id, data->hwirq);
> + case VPE_CR0_READ:
> + return vgic_v5_irs_vpe_cr0_read(vm->vm_id, vpe_id, &cmd_info->data);
> + case VPE_CR0_WRITE:
> + return vgic_v5_irs_vpe_cr0_update(vm->vm_id, vpe_id, cmd_info->data);
> case SPI_VIST_MAKE_VALID:
> return vgic_v5_irs_set_vist_valid(vm->vm_id, true);
> case LPI_VIST_MAKE_VALID:
> diff --git a/include/linux/irqchip/arm-gic-v5.h b/include/linux/irqchip/arm-gic-v5.h
> index ff5ad653252d2..54b573783cd75 100644
> --- a/include/linux/irqchip/arm-gic-v5.h
> +++ b/include/linux/irqchip/arm-gic-v5.h
> @@ -90,9 +90,14 @@
> #define GICV5_IRS_VMT_BASER 0x0200
> #define GICV5_IRS_VMT_CFGR 0x0210
> #define GICV5_IRS_VMT_STATUSR 0x0214
> +#define GICV5_IRS_VPE_SELR 0x0240
> +#define GICV5_IRS_VPE_DBR 0x0248
> +#define GICV5_IRS_VPE_CR0 0x0258
> +#define GICV5_IRS_VPE_STATUSR 0x025c
> #define GICV5_IRS_VMAP_L2_VMTR 0x02c0
> #define GICV5_IRS_VMAP_VMR 0x02c8
> #define GICV5_IRS_VMAP_VISTR 0x02d0
> +#define GICV5_IRS_VMAP_VPER 0x02e0
>
> #define GICV5_IRS_IDR0_VIRT BIT(6)
>
> @@ -199,6 +204,21 @@
>
> #define GICV5_IRS_VMT_STATUSR_IDLE BIT(0)
>
> +#define GICV5_IRS_VPE_SELR_S BIT_ULL(63)
> +#define GICV5_IRS_VPE_SELR_VPE_ID GENMASK_ULL(47, 32)
> +#define GICV5_IRS_VPE_SELR_VM_ID GENMASK_ULL(15, 0)
> +
> +#define GICV5_IRS_VPE_DBR_DBV BIT_ULL(63)
> +#define GICV5_IRS_VPE_DBR_REQ_DB BIT_ULL(62)
> +#define GICV5_IRS_VPE_DBR_DBPM GENMASK_ULL(36, 32)
> +#define GICV5_IRS_VPE_DBR_LPI_ID GENMASK_ULL(23, 0)
> +
> +#define GICV5_IRS_VPE_CR0_DPS BIT(0)
> +
> +#define GICV5_IRS_VPE_STATUSR_F BIT(2)
> +#define GICV5_IRS_VPE_STATUSR_V BIT(1)
> +#define GICV5_IRS_VPE_STATUSR_IDLE BIT(0)
> +
> #define GICV5_IRS_VMAP_L2_VMTR_M BIT_ULL(63)
> #define GICV5_IRS_VMAP_L2_VMTR_VM_ID GENMASK_ULL(15, 0)
>
> @@ -211,6 +231,10 @@
> #define GICV5_IRS_VMAP_VISTR_VM_ID GENMASK_ULL(47, 32)
> #define GICV5_IRS_VMAP_VISTR_TYPE GENMASK_ULL(31, 29)
>
> +#define GICV5_IRS_VMAP_VPER_M BIT_ULL(63)
> +#define GICV5_IRS_VMAP_VPER_VM_ID GENMASK_ULL(47, 32)
> +#define GICV5_IRS_VMAP_VPER_VPE_ID GENMASK_ULL(15, 0)
> +
> #define GICV5_ISTL1E_VALID BIT_ULL(0)
> #define GICV5_IRS_ISTL1E_SIZE 8UL
>
> @@ -480,6 +504,9 @@ enum gicv5_vcpu_info_cmd_type {
> VMT_L2_MAP, /* Map in a L2 VMT - *may* happen on VM init */
> VMTE_MAKE_VALID, /* Make the VMTE valid */
> VMTE_MAKE_INVALID, /* Make the VMTE (et al.) invalid */
> + VPE_MAKE_VALID, /* No corresponding invalid */
> + VPE_CR0_READ, /* Read of VPE_CR0 (guest read from PE_CR0) */
> + VPE_CR0_WRITE, /* Write to VPE_CR0 (guest write to PE_CR0) */
> SPI_VIST_MAKE_VALID, /* No corresponding invalid */
> LPI_VIST_MAKE_VALID, /* Triggered by a guest */
> LPI_VIST_MAKE_INVALID, /* Triggered by a guest */
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [RFC PATCH] arm64: mm: support set_memory_encrypted/decrypted for vmalloc addresses
From: Mike Rapoport @ 2026-04-30 8:45 UTC (permalink / raw)
To: Catalin Marinas
Cc: Kameron Carr, will, suzuki.poulose, steven.price, ryan.roberts,
dev.jain, yang, shijie, kevin.brodsky, linux-arm-kernel,
linux-kernel
In-Reply-To: <ad5vTmfDWSAVrLab@arm.com>
Hi Catalin,
On Tue, Apr 14, 2026 at 05:46:06PM +0100, Catalin Marinas wrote:
> On Fri, Apr 10, 2026 at 02:36:42PM -0700, Kameron Carr wrote:
> > On Friday, April 10, 2026 4:06 AM, Catalin Marinas wrote:
> > > Could you give more details about the user of set_memory_decrypted() on
> > > vmalloc()'ed addresses? I think this came up in the past and I wondered
> > > whether something like GFP_DECRYPTED would be simpler to implement (even
> > > posted a hack but without vmalloc() support). If it is known upfront
> > > that the memory will be decrypted, it's easier/cheaper to do this on the
> > > page allocation time to change the linear map and just use
> > > pgprot_decrypted() for vmap(). No need to rewrite the page table after
> > > mapping the pages.
> [...]
> > In this use case, whether to decrypt the memory can always be known at
> > time of allocation, so a solution like GFP_DECRYPTED is an option.
> >
> > I think I found the hack you mentioned
> > (https://lore.kernel.org/linux-arm-kernel/ZmNJdSxSz-sYpVgI@arm.com/). The
> > feedback in Michael Kelley's reply covers the key considerations well.
>
> Yes, that's the thread. It started originally as a GICv3 need
> (eventually we went for genpool).
>
> > He likely had netvsc's use of vmalloc in mind when he made the point
> > "GFP_DECRYPTED should work for the three memory allocation interfaces and
> > their variants: alloc_pages(), kmalloc(), and vmalloc()." His other
> > points already cover the concerns I had in mind around handling errors
> > from set_memory_decrypted()/encrypted(), etc.
> >
> > What is the current status of your proposed GFP_DECRYPTED implementation?
> > Is this something you are actively working on?
>
> Not really. But I've been looking at it again and I think it adds more
> problems than it solves. A GFP flag would be passed down to
> kmem_cache_alloc() and confuse the slab management if some pages are
> encrypted, others not for the same kmem_cache (SLAB_NO_MERGE wouldn't
> help). I wonder whether something like SLAB_DECRYPTED would work better
> for this if we really need it (not aware of any user though).
>
> Anyway, let's ignore slab for now and look at vmalloc(). I can see
> hv_ringbuffer_init() using an explicit vmap(pgprot_decrypted()). While
> you could do this, it might be better to just add a VM_DECRYPTED flag
> and a few wrappers like vmalloc_decrypted(). It would call
> set_memory_decrypted() for the allocated pages and use
> pgprot_decrypted() for vmap. On vfree(), it will have to set the pages
> back to encrypted. It should be fairly mechanical to do (or a 5 min job
> for an LLM ;)).
A GFP + SLAB flag is semantically better than only implementing decrypted
allocations only in vmalloc, but it's surely way more complex and intrusive
and we are running low on gfp flags on 32 bits :)
But I think we can push the _decrypted to kvmalloc() that would do either
kmalloc() + set_memory_decrypted() or vmalloc_decrypted() and it seems that
x86 and drivers could use that instead of alloc_pages() +
set_memory_decrypted().
We also would want also to make x86::set_memory_decrypted() to only accept
linear^w direct map addresses to ensure consistency between architectures.
> --
> Catalin
>
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [EXT] Re: [PATCH 4/5] arm64: dts: imx93: Cortex-A Core remoteproc device node
From: Daniel Baluta @ 2026-04-30 8:45 UTC (permalink / raw)
To: Jiafei Pan, Krzysztof Kozlowski, andersson@kernel.org,
mathieu.poirier@linaro.org, Peng Fan, Frank Li,
s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Cc: Z.Q. Hou, Mingkai Hu
In-Reply-To: <AM9PR04MB8196E13EA80CA4319EA17E828A352@AM9PR04MB8196.eurprd04.prod.outlook.com>
On 4/30/26 09:51, Jiafei Pan wrote:
>> On 28/04/2026 11:08, Jiafei Pan wrote:
>>> + init-on-array = <IMX93_CLK_LPUART2_GATE>; };
>>> diff --git a/arch/arm64/boot/dts/freescale/imx93-rproc-ca55.dtsi
>>> b/arch/arm64/boot/dts/freescale/imx93-rproc-ca55.dtsi
>>> new file mode 100644
>>> index 000000000000..9d9a60404d2b
>>> --- /dev/null
>>> +++ b/arch/arm64/boot/dts/freescale/imx93-rproc-ca55.dtsi
>>
>> Heh? A DTSI file for one device node?
>>
>> This looks a lot like downstream approach.
> Use a dtsi file which could be leveraged by multiple boards, otherwise what's your suggestion? Thanks.
>
It is just one simple dts node, put it everywhere you need it don't bother including a dtsi file for it.
^ permalink raw reply
* RE: [PATCH v3 2/3] arm64: dts: imx95: Add dma, intr, aer and pme interrupters for pcie{0,1}
From: Hongxing Zhu @ 2026-04-30 8:37 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
bhelgaas@google.com, Frank Li, l.stach@pengutronix.de,
lpieralisi@kernel.org, kwilczynski@kernel.org, mani@kernel.org,
s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com,
linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org, imx@lists.linux.dev,
linux-kernel@vger.kernel.org
In-Reply-To: <20260430-adaptable-wonderful-hoatzin-e1056f@quoll>
> -----Original Message-----
> From: Krzysztof Kozlowski <krzk@kernel.org>
> Sent: Thursday, April 30, 2026 4:05 PM
> To: Hongxing Zhu <hongxing.zhu@nxp.com>
> Cc: robh@kernel.org; krzk+dt@kernel.org; conor+dt@kernel.org;
> bhelgaas@google.com; Frank Li <frank.li@nxp.com>; l.stach@pengutronix.de;
> lpieralisi@kernel.org; kwilczynski@kernel.org; mani@kernel.org;
> s.hauer@pengutronix.de; kernel@pengutronix.de; festevam@gmail.com; linux-
> pci@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> devicetree@vger.kernel.org; imx@lists.linux.dev; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v3 2/3] arm64: dts: imx95: Add dma, intr, aer and pme
> interrupters for pcie{0,1}
>
> On Thu, Apr 30, 2026 at 01:09:53PM +0800, Richard Zhu wrote:
> > Add dma, intr, aer and pme interrupters for pcie{0,1}.
> >
> > Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> > ---
> > arch/arm64/boot/dts/freescale/imx95.dtsi | 16 ++++++++++++----
> > 1 file changed, 12 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/imx95.dtsi
> > b/arch/arm64/boot/dts/freescale/imx95.dtsi
> > index 71394871d8dd0..6896d9c15bf53 100644
> > --- a/arch/arm64/boot/dts/freescale/imx95.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/imx95.dtsi
> > @@ -1861,8 +1861,12 @@ pcie0: pcie@4c300000 {
> > bus-range = <0x00 0xff>;
> > num-lanes = <1>;
> > num-viewport = <8>;
> > - interrupts = <GIC_SPI 310 IRQ_TYPE_LEVEL_HIGH>;
> > - interrupt-names = "msi";
>
> Why there is no fixes tag if this is here for two years and you claim that IT
> CANNOT work without these interrupts?
Regarding the Fixes tag: I think that it is not needed here because this is not
a bug fix.
The driver has been functional for two years using only the MSI interrupt. The
current implementation works correctly for basic PCIe operation. This patch
adds support for additional interrupt lines (dma, intr, aer, pme) to enable
enhanced features and capabilities that were previously not utilized.
This is a feature enhancement, not a correction of broken functionality. The
hardware supports these additional interrupts, and we're now exposing them in
the device tree to allow the driver to take advantage of enhanced features.
I hope this clarifies your concern.
Best Regards
Richard Zhu
>
> Best regards,
> Krzysztof
^ permalink raw reply
* RE: [PATCH v3 1/3] dt-bindings: PCI: imx6q-pcie: Add intr, aer and pme interrupts
From: Hongxing Zhu @ 2026-04-30 8:37 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
bhelgaas@google.com, Frank Li, l.stach@pengutronix.de,
lpieralisi@kernel.org, kwilczynski@kernel.org, mani@kernel.org,
s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com,
linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org, imx@lists.linux.dev,
linux-kernel@vger.kernel.org
In-Reply-To: <20260430-proud-ammonite-of-gaiety-abaafc@quoll>
> -----Original Message-----
> From: Krzysztof Kozlowski <krzk@kernel.org>
> Sent: Thursday, April 30, 2026 4:04 PM
> To: Hongxing Zhu <hongxing.zhu@nxp.com>
> Cc: robh@kernel.org; krzk+dt@kernel.org; conor+dt@kernel.org;
> bhelgaas@google.com; Frank Li <frank.li@nxp.com>; l.stach@pengutronix.de;
> lpieralisi@kernel.org; kwilczynski@kernel.org; mani@kernel.org;
> s.hauer@pengutronix.de; kernel@pengutronix.de; festevam@gmail.com; linux-
> pci@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> devicetree@vger.kernel.org; imx@lists.linux.dev; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v3 1/3] dt-bindings: PCI: imx6q-pcie: Add intr, aer and pme
> interrupts
>
> On Thu, Apr 30, 2026 at 01:09:52PM +0800, Richard Zhu wrote:
> > Add 'intr', 'aer', and 'pme' interrupt entries to the i.MX6Q PCIe
> > binding to support PCIe event-based interrupts for general controller
> > events, Advanced Error Reporting, and Power Management Events respectively.
> >
> > These interrupts are optional for existing variants (imx6q, imx6sx,
> > imx6qp, imx7d, imx8mq, imx8mm, imx8mp) to maintain backward
> > compatibility with existing device trees.
> >
> > For fsl,imx95-pcie, all 5 interrupts (msi, dma, intr, aer, pme) are
> > mandatory due to hardware requirements.
> >
> > This introduces an ABI requirement for fsl,imx95-pcie. The i.MX95
> > hardware requires dedicated interrupt lines for AER, PME, and general
> > controller events due to its redesigned interrupt architecture. i.MX95
> > cannot function correctly without explicit interrupt routing for error
> > handling, power management and link event detection.
>
> fsl,imx95-pcie was added more than two years ago, so how it cannot function
> correctly? Are you saying that for two years you had here completely broken
> code?
>
> If this wasn't tested for two years, how can we believe anything is tested now?
The basic PCIe functionality has been working since the initial fsl,imx95-pcie
support. However, AER (Advanced Error Reporting) and link up/down detection
were not previously enabled. This patch-set adds and verifies support for
these advanced features.
Best Regards
Richard Zhu
>
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: [PATCH 5/5] arm_mpam: detect and enable MPAM-Fb PCC support
From: Sudeep Holla @ 2026-04-30 8:35 UTC (permalink / raw)
To: Andre Przywara
Cc: Lorenzo Pieralisi, Hanjun Guo, Sudeep Holla, Catalin Marinas,
Will Deacon, Rafael J . Wysocki, Len Brown, James Morse,
Ben Horgan, Reinette Chatre, Fenghua Yu, Jonathan Cameron,
linux-acpi, linux-arm-kernel, linux-kernel
In-Reply-To: <20260429141339.3171205-6-andre.przywara@arm.com>
On Wed, Apr 29, 2026 at 04:13:39PM +0200, Andre Przywara wrote:
> The Arm MPAM-Fb specification [1] describes a protocol to access MSC
> registers through a firmware interface. This requires a shared memory
> region to hold the message, and a mailbox to trigger the access.
> For ACPI this is wrapped as a PCC channel, described using existing
> ACPI abstractions.
>
> Add code to parse those PCC table descriptions associated with an MSC,
> and store the parsed information in the MSC struct.
> This will be used by the MPAM-Fb access wrapper code.
>
> [1] https://developer.arm.com/documentation/den0144/latest
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
> drivers/acpi/arm64/mpam.c | 2 ++
> drivers/resctrl/mpam_devices.c | 46 +++++++++++++++++++++++++++++++---
> 2 files changed, 45 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/acpi/arm64/mpam.c b/drivers/acpi/arm64/mpam.c
> index 99c2bdbb3314..edb4d10e8dc3 100644
> --- a/drivers/acpi/arm64/mpam.c
> +++ b/drivers/acpi/arm64/mpam.c
> @@ -341,6 +341,8 @@ static struct platform_device * __init acpi_mpam_parse_msc(struct acpi_mpam_msc_
> } else if (iface == MPAM_IFACE_PCC) {
> props[next_prop++] = PROPERTY_ENTRY_U32("pcc-channel",
> tbl_msc->base_address);
> + props[next_prop++] = PROPERTY_ENTRY_U32("msc-id",
> + tbl_msc->identifier);
I may be looking at the wrong documents, but neither DEN0065 nor DEN0144 carry
any definitions of pcc-channel and msc-id for the device with HID
"“ARMHAA5C". Since "pcc-channel" is already merged, I think I am looking at
wrong documents, please point me to the right one.
--
Regards,
Sudeep
^ 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