* [PATCH 7/7] KVM: arm64: Set IL in fake ESR for pKVM memory sharing exit
From: Fuad Tabba @ 2026-06-14 16:33 UTC (permalink / raw)
To: Marc Zyngier, Oliver Upton, linux-arm-kernel, kvmarm,
linux-kernel
Cc: Catalin Marinas, Will Deacon, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Vincent Donnefort, Sascha Bischoff,
tabba
In-Reply-To: <20260614163336.3490925-1-tabba@google.com>
__pkvm_memshare_page_req() constructs a fake DABT ESR_EL2 to exit to
the host without setting IL. The ESR has ISV=0, so IL must be 1 per the
architecture. The host does not read IL on this path, but the
constructed syndrome should still be architecturally valid.
Set ESR_ELx_IL.
Fixes: 03313efed5e2 ("KVM: arm64: Implement the MEM_SHARE hypercall for protected VMs")
Signed-off-by: Fuad Tabba <tabba@google.com>
---
arch/arm64/kvm/hyp/nvhe/pkvm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kvm/hyp/nvhe/pkvm.c b/arch/arm64/kvm/hyp/nvhe/pkvm.c
index eb1c10120f9f..c982a3a04c37 100644
--- a/arch/arm64/kvm/hyp/nvhe/pkvm.c
+++ b/arch/arm64/kvm/hyp/nvhe/pkvm.c
@@ -1054,7 +1054,8 @@ static u64 __pkvm_memshare_page_req(struct kvm_vcpu *vcpu, u64 ipa)
/* Fake up a data abort (level 3 translation fault on write) */
vcpu->arch.fault.esr_el2 = (ESR_ELx_EC_DABT_LOW << ESR_ELx_EC_SHIFT) |
- ESR_ELx_WNR | ESR_ELx_FSC_FAULT |
+ ESR_ELx_IL | ESR_ELx_WNR |
+ ESR_ELx_FSC_FAULT |
FIELD_PREP(ESR_ELx_FSC_LEVEL, 3);
/* Shuffle the IPA around into the HPFAR */
--
2.54.0.1136.gdb2ca164c4-goog
^ permalink raw reply related
* [PATCH 5/7] KVM: arm64: Set IL for emulated SError injection
From: Fuad Tabba @ 2026-06-14 16:33 UTC (permalink / raw)
To: Marc Zyngier, Oliver Upton, linux-arm-kernel, kvmarm,
linux-kernel
Cc: Catalin Marinas, Will Deacon, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Vincent Donnefort, Sascha Bischoff,
tabba
In-Reply-To: <20260614163336.3490925-1-tabba@google.com>
kvm_inject_serror_esr() constructs an SError syndrome without IL. The
architecture mandates IL=1 for SError unconditionally.
Fixes: f6e2262dfa1a ("KVM: arm64: Populate ESR_ELx.EC for emulated SError injection")
Signed-off-by: Fuad Tabba <tabba@google.com>
---
arch/arm64/kvm/inject_fault.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/kvm/inject_fault.c b/arch/arm64/kvm/inject_fault.c
index 444d219b0217..d6c4fc16f879 100644
--- a/arch/arm64/kvm/inject_fault.c
+++ b/arch/arm64/kvm/inject_fault.c
@@ -381,7 +381,7 @@ int kvm_inject_serror_esr(struct kvm_vcpu *vcpu, u64 esr)
*/
if (!serror_is_masked(vcpu)) {
pend_serror_exception(vcpu);
- esr |= FIELD_PREP(ESR_ELx_EC_MASK, ESR_ELx_EC_SERROR);
+ esr |= FIELD_PREP(ESR_ELx_EC_MASK, ESR_ELx_EC_SERROR) | ESR_ELx_IL;
vcpu_write_sys_reg(vcpu, esr, exception_esr_elx(vcpu));
return 1;
}
--
2.54.0.1136.gdb2ca164c4-goog
^ permalink raw reply related
* [PATCH 6/7] KVM: arm64: Set IL for nested SError injection
From: Fuad Tabba @ 2026-06-14 16:33 UTC (permalink / raw)
To: Marc Zyngier, Oliver Upton, linux-arm-kernel, kvmarm,
linux-kernel
Cc: Catalin Marinas, Will Deacon, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Vincent Donnefort, Sascha Bischoff,
tabba
In-Reply-To: <20260614163336.3490925-1-tabba@google.com>
kvm_inject_nested_serror() constructs an SError syndrome without IL.
The architecture mandates IL=1 for SError unconditionally.
Fixes: 77ee70a07357 ("KVM: arm64: nv: Honor SError exception routing / masking")
Signed-off-by: Fuad Tabba <tabba@google.com>
---
arch/arm64/kvm/emulate-nested.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/kvm/emulate-nested.c b/arch/arm64/kvm/emulate-nested.c
index 4b39363cf891..4262d4c17a87 100644
--- a/arch/arm64/kvm/emulate-nested.c
+++ b/arch/arm64/kvm/emulate-nested.c
@@ -2938,6 +2938,6 @@ int kvm_inject_nested_serror(struct kvm_vcpu *vcpu, u64 esr)
* vSError injection. Manually populate EC for an emulated SError
* exception.
*/
- esr |= FIELD_PREP(ESR_ELx_EC_MASK, ESR_ELx_EC_SERROR);
+ esr |= FIELD_PREP(ESR_ELx_EC_MASK, ESR_ELx_EC_SERROR) | ESR_ELx_IL;
return kvm_inject_nested(vcpu, esr, except_type_serror);
}
--
2.54.0.1136.gdb2ca164c4-goog
^ permalink raw reply related
* [PATCH 4/7] KVM: arm64: Set IL for injected FPAC exceptions during ERET emulation
From: Fuad Tabba @ 2026-06-14 16:33 UTC (permalink / raw)
To: Marc Zyngier, Oliver Upton, linux-arm-kernel, kvmarm,
linux-kernel
Cc: Catalin Marinas, Will Deacon, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Vincent Donnefort, Sascha Bischoff,
tabba
In-Reply-To: <20260614163336.3490925-1-tabba@google.com>
The FPAC syndrome constructed during nested ERET emulation does not set
IL. For FPAC (EC=0x1C), IL reflects the instruction length. ERET and
its authenticated variants are always A64 32-bit instructions, so IL
must be 1.
Fixes: 213b3d1ea161 ("KVM: arm64: nv: Handle ERETA[AB] instructions")
Signed-off-by: Fuad Tabba <tabba@google.com>
---
arch/arm64/kvm/emulate-nested.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/kvm/emulate-nested.c b/arch/arm64/kvm/emulate-nested.c
index dba7ced74ca5..4b39363cf891 100644
--- a/arch/arm64/kvm/emulate-nested.c
+++ b/arch/arm64/kvm/emulate-nested.c
@@ -2777,7 +2777,7 @@ void kvm_emulate_nested_eret(struct kvm_vcpu *vcpu)
*/
if (kvm_has_pauth(vcpu->kvm, FPACCOMBINE) && !(spsr & PSR_IL_BIT)) {
esr &= ESR_ELx_ERET_ISS_ERETA;
- esr |= FIELD_PREP(ESR_ELx_EC_MASK, ESR_ELx_EC_FPAC);
+ esr |= FIELD_PREP(ESR_ELx_EC_MASK, ESR_ELx_EC_FPAC) | ESR_ELx_IL;
kvm_inject_nested_sync(vcpu, esr);
return;
}
--
2.54.0.1136.gdb2ca164c4-goog
^ permalink raw reply related
* [PATCH 2/7] KVM: arm64: Unconditionally set IL for injected undefined exceptions
From: Fuad Tabba @ 2026-06-14 16:33 UTC (permalink / raw)
To: Marc Zyngier, Oliver Upton, linux-arm-kernel, kvmarm,
linux-kernel
Cc: Catalin Marinas, Will Deacon, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Vincent Donnefort, Sascha Bischoff,
tabba
In-Reply-To: <20260614163336.3490925-1-tabba@google.com>
inject_undef64() derives IL from the triggering trap's instruction
length (kvm_vcpu_trap_il_is32bit()), but the IL of the injected
exception is fixed by its EC, not by the triggering instruction. The
architecture mandates IL=1 for EC=0 (Unknown) unconditionally, so the
conditional is wrong. The undef-injection paths are not reached from
16-bit instructions, so there is no functional change today, but the
logic should not rely on that.
Set ESR_ELx_IL unconditionally.
Fixes: aa8eff9bfbd5 ("arm64: KVM: fault injection into a guest")
Signed-off-by: Fuad Tabba <tabba@google.com>
---
arch/arm64/kvm/inject_fault.c | 9 +--------
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/arch/arm64/kvm/inject_fault.c b/arch/arm64/kvm/inject_fault.c
index 89982bd3345f..9dfae1bcdf99 100644
--- a/arch/arm64/kvm/inject_fault.c
+++ b/arch/arm64/kvm/inject_fault.c
@@ -170,14 +170,7 @@ void kvm_inject_sync(struct kvm_vcpu *vcpu, u64 esr)
static void inject_undef64(struct kvm_vcpu *vcpu)
{
- u64 esr = (ESR_ELx_EC_UNKNOWN << ESR_ELx_EC_SHIFT);
-
- /*
- * Build an unknown exception, depending on the instruction
- * set.
- */
- if (kvm_vcpu_trap_il_is32bit(vcpu))
- esr |= ESR_ELx_IL;
+ u64 esr = (ESR_ELx_EC_UNKNOWN << ESR_ELx_EC_SHIFT) | ESR_ELx_IL;
kvm_inject_sync(vcpu, esr);
}
--
2.54.0.1136.gdb2ca164c4-goog
^ permalink raw reply related
* [PATCH 1/7] KVM: arm64: Set ESR_ELx.IL for injected undefined exceptions at EL2
From: Fuad Tabba @ 2026-06-14 16:33 UTC (permalink / raw)
To: Marc Zyngier, Oliver Upton, linux-arm-kernel, kvmarm,
linux-kernel
Cc: Catalin Marinas, Will Deacon, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Vincent Donnefort, Sascha Bischoff,
tabba
In-Reply-To: <20260614163336.3490925-1-tabba@google.com>
inject_undef64() constructs an ESR with EC=0 (Unknown) but does not set
IL. The architecture mandates IL=1 for EC=0 unconditionally (ARM DDI
0487, ESR_ELx.IL description), so the injected syndrome is one that
conforming hardware cannot produce.
Set ESR_ELx_IL in the constructed syndrome.
Fixes: e5d40a5a97c1 ("KVM: arm64: pkvm: Add a generic synchronous exception injection primitive")
Reported-by: sashiko <sashiko@sashiko.dev>
Signed-off-by: Fuad Tabba <tabba@google.com>
---
arch/arm64/kvm/hyp/nvhe/sys_regs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/kvm/hyp/nvhe/sys_regs.c b/arch/arm64/kvm/hyp/nvhe/sys_regs.c
index 8c3fbb413a06..9767adf1f73e 100644
--- a/arch/arm64/kvm/hyp/nvhe/sys_regs.c
+++ b/arch/arm64/kvm/hyp/nvhe/sys_regs.c
@@ -278,7 +278,7 @@ static void inject_sync64(struct kvm_vcpu *vcpu, u64 esr)
*/
static void inject_undef64(struct kvm_vcpu *vcpu)
{
- inject_sync64(vcpu, (ESR_ELx_EC_UNKNOWN << ESR_ELx_EC_SHIFT));
+ inject_sync64(vcpu, (ESR_ELx_EC_UNKNOWN << ESR_ELx_EC_SHIFT) | ESR_ELx_IL);
}
static u64 read_id_reg(const struct kvm_vcpu *vcpu,
--
2.54.0.1136.gdb2ca164c4-goog
^ permalink raw reply related
* [PATCH 3/7] KVM: arm64: Unconditionally set IL for injected abort exceptions
From: Fuad Tabba @ 2026-06-14 16:33 UTC (permalink / raw)
To: Marc Zyngier, Oliver Upton, linux-arm-kernel, kvmarm,
linux-kernel
Cc: Catalin Marinas, Will Deacon, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Vincent Donnefort, Sascha Bischoff,
tabba
In-Reply-To: <20260614163336.3490925-1-tabba@google.com>
inject_abt64() derives IL from the triggering trap's instruction length
(kvm_vcpu_trap_il_is32bit()), but the IL of the injected abort is fixed
by its EC, not by the triggering instruction. The architecture mandates
IL=1 for Instruction Aborts unconditionally and for Data Aborts with
ISV=0, and this function never sets ISV (the FSC is always EXTABT or
SEA_TTW). For a 16-bit T32 trap (a 32-bit EL0 task under an AArch64 EL1
guest) the trap has IL=0, so the abort is injected with the wrong IL.
Set ESR_ELx_IL unconditionally.
Fixes: aa8eff9bfbd5 ("arm64: KVM: fault injection into a guest")
Signed-off-by: Fuad Tabba <tabba@google.com>
---
arch/arm64/kvm/inject_fault.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/kvm/inject_fault.c b/arch/arm64/kvm/inject_fault.c
index 9dfae1bcdf99..444d219b0217 100644
--- a/arch/arm64/kvm/inject_fault.c
+++ b/arch/arm64/kvm/inject_fault.c
@@ -138,11 +138,10 @@ static void inject_abt64(struct kvm_vcpu *vcpu, bool is_iabt, unsigned long addr
pend_sync_exception(vcpu);
/*
- * Build an {i,d}abort, depending on the level and the
- * instruction set. Report an external synchronous abort.
+ * Build an {i,d}abort, depending on the level.
+ * Report an external synchronous abort.
*/
- if (kvm_vcpu_trap_il_is32bit(vcpu))
- esr |= ESR_ELx_IL;
+ esr |= ESR_ELx_IL;
/*
* Here, the guest runs in AArch64 mode when in EL1. If we get
--
2.54.0.1136.gdb2ca164c4-goog
^ permalink raw reply related
* [PATCH 0/7] KVM: arm64: Fix missing ESR_ELx.IL in syndrome injection
From: Fuad Tabba @ 2026-06-14 16:33 UTC (permalink / raw)
To: Marc Zyngier, Oliver Upton, linux-arm-kernel, kvmarm,
linux-kernel
Cc: Catalin Marinas, Will Deacon, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Vincent Donnefort, Sascha Bischoff,
tabba
Hi folks,
After sashiko caught the missing IL bug [1], I did an audit of all ESR
syndrome construction sites in KVM/arm64 as Marc suggested. This series
is the result of that audit.
The ARM architecture mandates ESR_ELx.IL=1 for several exception
classes regardless of instruction length: EC=Unknown, Instruction
Aborts, Data Aborts with ISV=0, and SError. For FPAC (EC=0x1C), IL
reflects instruction length, but FPAC can only be generated by A64
instructions, so IL must also be 1.
Patch 1 is the bug sashiko found: inject_undef64() in the pKVM hyp (EL2)
path never set IL.
Patch 2 makes the same fix to inject_undef64() in the normal host path,
where IL was derived from the triggering trap's instruction length. No
instruction that reaches undef injection has a 16-bit encoding, so patch
2 has no functional change today.
Patch 3 makes the matching fix to inject_abt64(). Unlike undef injection,
abort injection is reachable from a 16-bit T32 instruction (a 32-bit EL0
task under an AArch64 EL1 guest), so the old code there injects an abort
with IL=0.
Patch 4 fixes the FPAC syndrome constructed during nested ERET
emulation, which did not set IL.
Patches 5-6 fix SError injection in the emulated and nested paths,
neither of which set IL.
Patch 7 fixes a fake ESR used to exit to the host. The host does not
read IL there, so it is not guest-visible.
Based on Linux 7.1-rc7
Cheers,
/fuad
[1] https://lore.kernel.org/all/87pl1t8q24.wl-maz@kernel.org/
Fuad Tabba (7):
KVM: arm64: Set ESR_ELx.IL for injected undefined exceptions at EL2
KVM: arm64: Unconditionally set IL for injected undefined exceptions
KVM: arm64: Unconditionally set IL for injected abort exceptions
KVM: arm64: Set IL for injected FPAC exceptions during ERET emulation
KVM: arm64: Set IL for emulated SError injection
KVM: arm64: Set IL for nested SError injection
KVM: arm64: Set IL in fake ESR for pKVM memory sharing exit
arch/arm64/kvm/emulate-nested.c | 4 ++--
arch/arm64/kvm/hyp/nvhe/pkvm.c | 3 ++-
arch/arm64/kvm/hyp/nvhe/sys_regs.c | 2 +-
arch/arm64/kvm/inject_fault.c | 18 +++++-------------
4 files changed, 10 insertions(+), 17 deletions(-)
--
2.54.0.1136.gdb2ca164c4-goog
^ permalink raw reply
* ❌ FAIL: Test report for for-kernelci (7.1.0-rc7, upstream-arm-next, c2a9495b)
From: cki-project @ 2026-06-14 16:03 UTC (permalink / raw)
To: linux-arm-kernel, yoyang, will, catalin.marinas
Hi, we tested your kernel and here are the results:
Overall result: FAILED
Merge: OK
Compile: OK
Test: FAILED
Kernel information:
Commit message: Merge branch 'for-next/core' into for-kernelci
You can find all the details about the test run at
https://datawarehouse.cki-project.org/kcidb/checkouts/redhat:2600134910
One or more kernel tests failed:
Unrecognized or new issues:
xfstests - btrfs
aarch64
Logs: https://datawarehouse.cki-project.org/kcidb/tests/redhat:2600134910_aarch64_kernel_kcidb_tool_21463752_9
Non-passing ran subtests:
❌ FAIL generic/301
aarch64
Logs: https://datawarehouse.cki-project.org/kcidb/tests/redhat:2600134910_aarch64_kernel_kcidb_tool_21463753_9
Non-passing ran subtests:
❌ FAIL generic/301
We also see the following known issues which are not related to your changes:
Issue: [upstream] Hardware - Firmware test suite - auto-waive failures
URL: https://gitlab.com/cki-project/infrastructure/-/issues/779
Affected tests:
Hardware - Firmware test suite [aarch64]
If you find a failure unrelated to your changes, please ask the test maintainer to review it.
This will prevent the failures from being incorrectly reported in the future.
Please reply to this email if you have any questions about the tests that we
ran or if you have any suggestions on how to make future tests more effective.
,-. ,-.
( C ) ( K ) Continuous
`-',-.`-' Kernel
( I ) Integration
`-'
______________________________________________________________________________
^ permalink raw reply
* Re: [PATCH v1 4/4] KVM: arm64: Add hyp_printk event to nVHE/pKVM hyp
From: Fuad Tabba @ 2026-06-14 15:25 UTC (permalink / raw)
To: Vincent Donnefort
Cc: maz, oliver.upton, joey.gouly, suzuki.poulose, yuzenghui,
catalin.marinas, will, rostedt, linux-arm-kernel, kvmarm,
kernel-team, qerret
In-Reply-To: <20260612142245.1015744-5-vdonnefort@google.com>
Hi Vincent,
On Fri, 12 Jun 2026 at 15:22, Vincent Donnefort <vdonnefort@google.com> wrote:
>
> Create an event to allow developers to log pretty much anything into the
> hypervisor tracing buffer with trace_hyp_printk(), just like the kernel
> tracing has the function trace_printk().
>
> trace_hyp_printk("foobar");
> trace_hyp_printk("foo=%d", foo);
> trace_hyp_printk("foo=%d bar=0x%016llx", foo, bar);
>
> To ensure writing into the tracing buffer is fast, store the string
> format into a kernel-accessible ELF section. The hypervisor only has to
> write into the event the string ID, which is the delta between the
> hyp_string_fmt and the start of the ELF section.
>
> To not waste tracing buffer data, use a dynamic size. Each
> argument is 8 bytes and the in-kernel printing function can simply know
> how many of them there are by looking at the event length.
>
> Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
>
> diff --git a/arch/arm64/include/asm/kvm_hypevents.h b/arch/arm64/include/asm/kvm_hypevents.h
> index 743c49bd878f..8465b523cb1d 100644
> --- a/arch/arm64/include/asm/kvm_hypevents.h
> +++ b/arch/arm64/include/asm/kvm_hypevents.h
> @@ -57,4 +57,18 @@ HYP_EVENT(selftest,
> ),
> RE_PRINTK("id=%llu", __entry->id)
> );
> +
> +/*
> + * trace_hyp_printk() has too many specificities to be declared with HYP_EVENT().
> + * However, we can use a REMOTE_EVENT macro to automatically do the declaration
> + * for the kernel side.
> + */
> +REMOTE_EVENT_CUSTOM_PRINTK(hyp_printk,
> + 0, /* id will be overwritten during hyp event init */
> + RE_STRUCT(
> + re_field(u16, fmt_id)
> + re_field(u64, args[])
> + ),
> + __hyp_trace_printk(evt, seq)
> +);
> #endif
> diff --git a/arch/arm64/include/asm/kvm_hyptrace.h b/arch/arm64/include/asm/kvm_hyptrace.h
> index de133b735f72..46097105fdd8 100644
> --- a/arch/arm64/include/asm/kvm_hyptrace.h
> +++ b/arch/arm64/include/asm/kvm_hyptrace.h
> @@ -23,4 +23,12 @@ extern struct remote_event __hyp_events_end[];
> extern struct hyp_event_id __hyp_event_ids_start[];
> extern struct hyp_event_id __hyp_event_ids_end[];
>
> +#define HYP_STRING_FMT_MAX_SIZE 128
> +
> +struct hyp_string_fmt {
> + const char fmt[HYP_STRING_FMT_MAX_SIZE];
> +};
> +
> +extern struct hyp_string_fmt __hyp_string_fmts_start[];
> +extern struct hyp_string_fmt __hyp_string_fmts_end[];
> #endif
> diff --git a/arch/arm64/kernel/image-vars.h b/arch/arm64/kernel/image-vars.h
> index d4c7d45ae6bc..ec03621d7a81 100644
> --- a/arch/arm64/kernel/image-vars.h
> +++ b/arch/arm64/kernel/image-vars.h
> @@ -141,6 +141,7 @@ KVM_NVHE_ALIAS(__hyp_rodata_end);
> #ifdef CONFIG_NVHE_EL2_TRACING
> KVM_NVHE_ALIAS(__hyp_event_ids_start);
> KVM_NVHE_ALIAS(__hyp_event_ids_end);
> +KVM_NVHE_ALIAS(__hyp_string_fmts_start);
> #endif
>
> /* pKVM static key */
> diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
> index e1ac876200a3..b6d62642b6bd 100644
> --- a/arch/arm64/kernel/vmlinux.lds.S
> +++ b/arch/arm64/kernel/vmlinux.lds.S
> @@ -324,6 +324,10 @@ SECTIONS
> __hyp_events_start = .;
> *(SORT(_hyp_events.*))
> __hyp_events_end = .;
> +
> + __hyp_string_fmts_start = .;
> + *(_hyp_string_fmts)
> + __hyp_string_fmts_end = .;
> }
> #endif
> /*
> diff --git a/arch/arm64/kvm/hyp/include/nvhe/define_events.h b/arch/arm64/kvm/hyp/include/nvhe/define_events.h
> index 776d4c6cb702..370e8c2d39fe 100644
> --- a/arch/arm64/kvm/hyp/include/nvhe/define_events.h
> +++ b/arch/arm64/kvm/hyp/include/nvhe/define_events.h
> @@ -10,5 +10,3 @@
> #define HYP_EVENT_MULTI_READ
> #include <asm/kvm_hypevents.h>
> #undef HYP_EVENT_MULTI_READ
> -
> -#undef HYP_EVENT
> diff --git a/arch/arm64/kvm/hyp/include/nvhe/trace.h b/arch/arm64/kvm/hyp/include/nvhe/trace.h
> index 8813ff250f8e..3d0b5c634bb3 100644
> --- a/arch/arm64/kvm/hyp/include/nvhe/trace.h
> +++ b/arch/arm64/kvm/hyp/include/nvhe/trace.h
> @@ -46,6 +46,69 @@ static inline pid_t __tracing_get_vcpu_pid(struct kvm_cpu_context *host_ctxt)
> void *tracing_reserve_entry(unsigned long length);
> void tracing_commit_entry(void);
>
> +/*
> + * The trace_hyp_printk boilerplate is too fiddly to be declared with
> + * HYP_EVENT():
> + *
> + * The string format is stored into a kernel-accessible ELF section. The
> + * hypervisor only writes the format ID.
> + *
> + * The function has a variadic prototype. We have no easy way to know each
> + * argument width so they must all cast to u64.
> + */
> +#define REMOTE_EVENT_CUSTOM_PRINTK(...)
> +
> +#define __TO_U64_0()
> +#define __TO_U64_1(x) , (u64)(x)
> +#define __TO_U64_2(x, ...) , (u64)(x) __TO_U64_1(__VA_ARGS__)
> +#define __TO_U64_3(x, ...) , (u64)(x) __TO_U64_2(__VA_ARGS__)
> +#define __TO_U64_4(x, ...) , (u64)(x) __TO_U64_3(__VA_ARGS__)
> +#define __TO_U64_5(x, ...) , (u64)(x) __TO_U64_4(__VA_ARGS__)
> +#define __TO_U64_6(x, ...) , (u64)(x) __TO_U64_5(__VA_ARGS__)
> +#define __TO_U64_7(x, ...) , (u64)(x) __TO_U64_6(__VA_ARGS__)
> +#define __TO_U64_8(x, ...) , (u64)(x) __TO_U64_7(__VA_ARGS__)
> +
> +#define __TO_U64_X(N, ...) CONCATENATE(__TO_U64_, N)(__VA_ARGS__)
> +#define __TO_U64(...) __TO_U64_X(COUNT_ARGS(__VA_ARGS__), ##__VA_ARGS__)
> +
> +REMOTE_EVENT_FORMAT(hyp_printk, HE_STRUCT(he_field(u16, fmt_id) he_field(u64, args[])));
> +extern struct hyp_event_id hyp_event_id_hyp_printk;
> +
> +static __always_inline void __trace_hyp_printk(struct hyp_string_fmt *fmt, int nr_args, ...)
> +{
> + struct remote_event_format_hyp_printk *entry;
> + va_list va;
> + int i;
> +
> + if (!atomic_read(&hyp_event_id_hyp_printk.enabled))
> + return;
> +
> + entry = tracing_reserve_entry(struct_size(entry, args, nr_args));
> + if (!entry)
> + return;
> +
> + entry->hdr.id = hyp_event_id_hyp_printk.id;
> + entry->fmt_id = fmt - __hyp_string_fmts_start;
nit: fmt_id is u16, the subtraction is ptrdiff_t. Silent truncation if
the section ever has more than 65536 entries. Not realistic today, but
a WARN_ON on the section size in hyp_trace_init_events() would catch
it at boot for free.
Reviewed-by: Fuad Tabba <tabba@google.com>
Tested-by: Fuad Tabba <tabba@google.com>
Cheers,
/fuad
> +
> + va_start(va, nr_args);
> + for (i = 0; i < nr_args; i++)
> + entry->args[i] = va_arg(va, u64);
> + va_end(va);
> +
> + tracing_commit_entry();
> +}
> +
> +
> +#define trace_hyp_printk(__fmt, __args...) \
> +do { \
> + static struct hyp_string_fmt __used __section("_hyp_string_fmts") fmt = { \
> + .fmt = __fmt \
> + }; \
> + BUILD_BUG_ON(sizeof(__fmt) > HYP_STRING_FMT_MAX_SIZE); \
> + /* __TO_U64 prepends a comma if there are arguments */ \
> + __trace_hyp_printk(&fmt, COUNT_ARGS(__args) __TO_U64(__args)); \
> +} while (0)
> +
> int __tracing_load(unsigned long desc_va, size_t desc_size);
> void __tracing_unload(void);
> int __tracing_enable(bool enable);
> @@ -58,6 +121,8 @@ static inline void *tracing_reserve_entry(unsigned long length) { return NULL; }
> static inline void tracing_commit_entry(void) { }
> #define HYP_EVENT(__name, __proto, __struct, __assign, __printk) \
> static inline void trace_##__name(__proto) {}
> +#define REMOTE_EVENT_CUSTOM_PRINTK(...)
> +#define trace_hyp_printk(fmt, args...) do { } while (0)
>
> static inline int __tracing_load(unsigned long desc_va, size_t desc_size) { return -ENODEV; }
> static inline void __tracing_unload(void) { }
> diff --git a/arch/arm64/kvm/hyp/nvhe/events.c b/arch/arm64/kvm/hyp/nvhe/events.c
> index add9383aadb5..12223d2e3618 100644
> --- a/arch/arm64/kvm/hyp/nvhe/events.c
> +++ b/arch/arm64/kvm/hyp/nvhe/events.c
> @@ -9,6 +9,12 @@
>
> #include <nvhe/define_events.h>
>
> +/*
> + * The hyp_printk event is not declared with HYP_EVENT in kvm_hypevents.h,
> + * so we manually add the boilerplate here.
> + */
> +HYP_EVENT(hyp_printk, 0, 0, 0, 0);
> +
> int __tracing_enable_event(unsigned short id, bool enable)
> {
> struct hyp_event_id *event_id = &__hyp_event_ids_start[id];
> diff --git a/arch/arm64/kvm/hyp_trace.c b/arch/arm64/kvm/hyp_trace.c
> index 821bc93ecdd1..187a8a295d6f 100644
> --- a/arch/arm64/kvm/hyp_trace.c
> +++ b/arch/arm64/kvm/hyp_trace.c
> @@ -391,6 +391,9 @@ static struct trace_remote_callbacks trace_remote_callbacks = {
>
> static const char *__hyp_enter_exit_reason_str(u8 reason);
>
> +struct remote_event_format_hyp_printk;
> +static void __hyp_trace_printk(struct remote_event_format_hyp_printk *entry, struct trace_seq *seq);
> +
> #include "define_hypevents.h"
>
> static const char *__hyp_enter_exit_reason_str(u8 reason)
> @@ -409,6 +412,61 @@ static const char *__hyp_enter_exit_reason_str(u8 reason)
> return strs[min(reason, HYP_REASON_UNKNOWN)];
> }
>
> +static void __hyp_trace_printk(struct remote_event_format_hyp_printk *entry, struct trace_seq *seq)
> +{
> + const char *fmt = (const char *)(&__hyp_string_fmts_start[entry->fmt_id]);
> + struct ring_buffer_event *evt = (void *)entry - RB_EVNT_HDR_SIZE;
> + int nr_args;
> +
> + trace_seq_putc(seq, ' ');
> +
> + if ((void *)fmt >= (void *)__hyp_string_fmts_end) {
> + trace_seq_printf(seq, "Unknown hyp_string_fmt ID %d\n", entry->fmt_id);
> + return;
> + }
> +
> + nr_args = (ring_buffer_event_length(evt) -
> + offsetof(struct remote_event_format_hyp_printk, args)) / sizeof(entry->args[0]);
> + switch (nr_args) {
> + case 0:
> + trace_seq_printf(seq, fmt);
> + break;
> + case 1:
> + trace_seq_printf(seq, fmt, entry->args[0]);
> + break;
> + case 2:
> + trace_seq_printf(seq, fmt, entry->args[0], entry->args[1]);
> + break;
> + case 3:
> + trace_seq_printf(seq, fmt, entry->args[0], entry->args[1], entry->args[2]);
> + break;
> + case 4:
> + trace_seq_printf(seq, fmt, entry->args[0], entry->args[1], entry->args[2],
> + entry->args[3]);
> + break;
> + case 5:
> + trace_seq_printf(seq, fmt, entry->args[0], entry->args[1], entry->args[2],
> + entry->args[3], entry->args[4]);
> + break;
> + case 6:
> + trace_seq_printf(seq, fmt, entry->args[0], entry->args[1], entry->args[2],
> + entry->args[3], entry->args[4], entry->args[5]);
> + break;
> + case 7:
> + trace_seq_printf(seq, fmt, entry->args[0], entry->args[1], entry->args[2],
> + entry->args[3], entry->args[4], entry->args[5], entry->args[6]);
> + break;
> + default:
> + trace_seq_printf(seq, fmt, entry->args[0], entry->args[1],
> + entry->args[2], entry->args[3], entry->args[4], entry->args[5],
> + entry->args[6], entry->args[7]);
> + break;
> + }
> +
> + if (seq->buffer[trace_seq_used(seq) - 1] != '\n')
> + trace_seq_putc(seq, '\n');
> +}
> +
> static void __init hyp_trace_init_events(void)
> {
> struct hyp_event_id *hyp_event_id = __hyp_event_ids_start;
> --
> 2.54.0.1136.gdb2ca164c4-goog
>
^ permalink raw reply
* Re: [PATCH] KVM: arm64: vgic: Check the interrupt is still ours before migrating it
From: Marc Zyngier @ 2026-06-14 15:16 UTC (permalink / raw)
To: Hyunwoo Kim
Cc: Oliver Upton, joey.gouly, seiden, suzuki.poulose, yuzenghui,
catalin.marinas, will, Sascha.Bischoff, jic23, timothy.hayes,
andre.przywara, linux-arm-kernel, kvmarm
In-Reply-To: <aitta-IcWnRepEva@v4bel>
On Fri, 12 Jun 2026 03:22:35 +0100,
Hyunwoo Kim <imv4bel@gmail.com> wrote:
>
> On Wed, Jun 10, 2026 at 05:00:25PM +0100, Marc Zyngier wrote:
> > It's rather unclear to me what the semantics of this are.
> >
> > If vcpu-a decides to nuke the LPIs of vcpu-b and the LPI had in the
> > meantime been migrated to vcpu-c, but obviously not observed by vcpu-c
> > yet as the LPI is still on vcpu-b's AP-list, then I don't see the
> > point in keeping this state.
> >
> > Am I missing something obvious?
>
> I looked a bit more into Oliver's review, the one suggesting that pending
> be cleared only for resident LPIs while the ones being migrated are left
> in place.
>
> What the leave preserves is the pending edge of a single LPI whose target
> is already vcpu-c but which is still on vcpu-b's ap_list. This edge is
> always lost when we just clear it, but for a device that fires again a
> later INT reaches vcpu-c through the oracle, so it is mostly harmless.
Not completely harmless. When the guest writes EnableLPIs==0, it
accepts the lost of any pending bit that could be stored. These won't
be regenerated, unless the device signals a new event that maps to the
same LPIs. But again, this is the guest's own decision, and I don't
see a reason to prevent it from shooting itself in the foot.
> The
> exception is a software LPI that never fires again(irq->hw == false):
> that edge is then lost with no way to recover it, because
> its_sync_lpi_pending_table only re-syncs the LPIs whose target_vcpu matches,
> and the disable path does no pending writeback. I am not entirely sure about
> this part, though.
I don't think this is a problem, as the architecture doesn't guarantee
the state of the pending table after turning EnableLPIs off. There's
even a note recommending to move the interrupts to another RD before
doing that.
>
> Since this does not look like the common case, if it does not need to be
> covered I will send v2 keeping only the pending clear and the ref hold in
> vgic_prune_ap_list(). What do you think?
So that it is entirely unambiguous, my suggestion is to have this:
diff --git a/arch/arm64/kvm/vgic/vgic.c b/arch/arm64/kvm/vgic/vgic.c
index 5a4768d8cd4f3..70a161383e5a6 100644
--- a/arch/arm64/kvm/vgic/vgic.c
+++ b/arch/arm64/kvm/vgic/vgic.c
@@ -203,6 +203,7 @@ void vgic_flush_pending_lpis(struct kvm_vcpu *vcpu)
list_for_each_entry_safe(irq, tmp, &vgic_cpu->ap_list_head, ap_list) {
if (irq_is_lpi(vcpu->kvm, irq->intid)) {
raw_spin_lock(&irq->irq_lock);
+ irq->pending_latch = false;
list_del(&irq->ap_list);
irq->vcpu = NULL;
raw_spin_unlock(&irq->irq_lock);
@@ -792,7 +793,11 @@ static void vgic_prune_ap_list(struct kvm_vcpu *vcpu)
continue;
}
- /* This interrupt looks like it has to be migrated. */
+ /*
+ * This interrupt looks like it has to be migrated,
+ * make sure it is kept alive while locks are dropped.
+ */
+ vgic_get_irq_ref(irq);
raw_spin_unlock(&irq->irq_lock);
raw_spin_unlock(&vgic_cpu->ap_list_lock);
@@ -836,6 +841,8 @@ static void vgic_prune_ap_list(struct kvm_vcpu *vcpu)
raw_spin_unlock(&vcpuB->arch.vgic_cpu.ap_list_lock);
raw_spin_unlock(&vcpuA->arch.vgic_cpu.ap_list_lock);
+ deleted_lpis |= vgic_put_irq_norelease(vcpu->kvm, irq);
+
if (target_vcpu_needs_kick) {
kvm_make_request(KVM_REQ_IRQ_PENDING, target_vcpu);
kvm_vcpu_kick(target_vcpu);
Could you please give it a go with whatever reproducer you have?
Thanks,
M.
--
Jazz isn't dead. It just smells funny.
^ permalink raw reply related
* Re: [PATCH v1 3/4] tracing/remotes: Add REMOTE_EVENT_CUSTOM_PRINTK() helper
From: Fuad Tabba @ 2026-06-14 14:46 UTC (permalink / raw)
To: Vincent Donnefort
Cc: maz, oliver.upton, joey.gouly, suzuki.poulose, yuzenghui,
catalin.marinas, will, rostedt, linux-arm-kernel, kvmarm,
kernel-team, qerret
In-Reply-To: <20260612142245.1015744-4-vdonnefort@google.com>
On Fri, 12 Jun 2026 at 15:22, Vincent Donnefort <vdonnefort@google.com> wrote:
>
> The current REMOTE_EVENT() takes as a __printk argument a string format
> and a list of arguments, such as RE_STRUCT("foo=%d bar=%d", foo, bar).
> Add a REMOTE_EVENT_CUSTOM_PRINTK() where the __printk argument can be a
> function. This intends to support the creation of a "printk" event for
> the arm64 nVHE/pKVM hypervisor with a dynamic prototype and by extension
> a dynamic print format.
>
> Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
Reviewed-by: Fuad Tabba <tabba@google.com>
Tested-by: Fuad Tabba <tabba@google.com>
Cheers,
/fuad
>
> diff --git a/include/trace/define_remote_events.h b/include/trace/define_remote_events.h
> index 676e803dc144..4f4d58e37b84 100644
> --- a/include/trace/define_remote_events.h
> +++ b/include/trace/define_remote_events.h
> @@ -35,17 +35,26 @@ do { \
>
> #define RE_PRINTK(__args...) __args
>
> -#define REMOTE_EVENT(__name, __id, __struct, __printk) \
> - REMOTE_EVENT_FORMAT(__name, __struct); \
> +#define REMOTE_EVENT_PRINT_FUNC(__name, __printk) \
> static void remote_event_print_##__name(void *evt, struct trace_seq *seq) \
> { \
> struct remote_event_format_##__name __maybe_unused *__entry = evt; \
> trace_seq_puts(seq, #__name); \
> - remote_printk(__printk); \
> + __printk; \
> }
> +
> +#define REMOTE_EVENT(__name, __id, __struct, __printk) \
> + REMOTE_EVENT_FORMAT(__name, __struct); \
> + REMOTE_EVENT_PRINT_FUNC(__name, remote_printk(__printk))
> +
> +#define REMOTE_EVENT_CUSTOM_PRINTK(__name, __id, __struct, __printk) \
> + REMOTE_EVENT_FORMAT(__name, __struct); \
> + REMOTE_EVENT_PRINT_FUNC(__name, __printk)
> +
> #include REMOTE_EVENT_INCLUDE(REMOTE_EVENT_INCLUDE_FILE)
>
> #undef REMOTE_EVENT
> +#undef REMOTE_EVENT_CUSTOM_PRINTK
> #undef RE_PRINTK
> #undef re_field
> #define re_field(__type, __field) \
> @@ -70,4 +79,8 @@ do { \
> .print_fmt = remote_event_print_fmt_##__name, \
> .print = remote_event_print_##__name, \
> }
> +
> +#define REMOTE_EVENT_CUSTOM_PRINTK(__name, __id, __struct, __printk) \
> + REMOTE_EVENT(__name, __id, RE_STRUCT(__struct), "Unknown")
> +
> #include REMOTE_EVENT_INCLUDE(REMOTE_EVENT_INCLUDE_FILE)
> --
> 2.54.0.1136.gdb2ca164c4-goog
>
^ permalink raw reply
* Re: [PATCH v2 7/8] dt-bindings: display: allwinner: Split H616 DE33 layer reg space
From: Jernej Škrabec @ 2026-06-14 14:08 UTC (permalink / raw)
To: wens, Krzysztof Kozlowski
Cc: samuel, mripard, maarten.lankhorst, tzimmermann, airlied, simona,
robh, krzk+dt, conor+dt, mturquette, sboyd, dri-devel, devicetree,
linux-arm-kernel, linux-sunxi, linux-kernel, linux-clk
In-Reply-To: <032c1099-40ab-470e-8cc3-af6d3cad22d4@kernel.org>
Dne ponedeljek, 25. maj 2026 ob 14:10:38 Srednjeevropski poletni čas je Krzysztof Kozlowski napisal(a):
> On 24/05/2026 23:33, Chen-Yu Tsai wrote:
> > Hi,
> >
> > (resent from new email)
> >
> > On Thu, May 14, 2026 at 2:04 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >>
> >> On Sat, May 09, 2026 at 09:00:14PM +0200, Jernej Skrabec wrote:
> >>> From: Jernej Skrabec <jernej.skrabec@gmail.com>
> >>>
> >>> As it turns out, current H616 DE33 binding was written based on
> >>> incomplete understanding of DE33 design. Namely, planes are shared
> >>> resource and not tied to specific mixer, which was the case for previous
> >>> generations of Display Engine (DE3 and earlier).
> >>>
> >>> This means that current DE33 binding doesn't properly reflect HW and
> >>> using it would mean that second mixer (used for second display output)
> >>> can't be supported.
> >>>
> >>> Remove layer register space, which will be represented with additional
> >>> node, and replace it with phandle, which will point to that new, shared
> >>> node. That way, all mixers can share same layers.
> >>>
> >>> There is no user of this binding yet, so changes can be made safely,
> >>> without breaking any backward compatibility.
> >>
> >> There is user. git grep gives me:
> >> drivers/gpu/drm/sun4i/sun8i_mixer.c
> >>
> >> which means this is a released ABI. As I understood, the old code was
> >
> > We held off on merging the DT changes so that we could rework this.
> > I can't find the actual request though. It was probably over IRC.
> >
> >> working fine but just did not support all use cases. Why this cannot be
> >> kept backwards compatible?
> >
> > AFAIK the "planes" block is shared between two display mixers. As the
> > commit message explains, this prevents using the second mixer, since
> > only one of them can claim and map the register space. And on the H700
> > (which is the same die as the H616 discussed here but with more exposed
> > interfaces), there could actually be a use case for the second mixer.
>
> It explains why you want to make the changes but not why you cannot keep
> it backwards compatible.
I guess it can be backward compatible, but I don't think it makes sense.
Yes, original driver implemented original DT bindings, but there is no node
which uses that binding. If there is no user of that, why would driver
need to support it nevertheless? Supporting only actually used DT binding
allows for better code architecture, as there is no need to support second,
unused path. It also simplifies testing, since developer doesn't need to
test both paths if code is changed in that area.
Best regards,
Jernej
Best regards,
Jernej
^ permalink raw reply
* Re: [PATCH 0/2] iio: adc: Initialize completions before requesting IRQs
From: Jonathan Cameron @ 2026-06-14 13:51 UTC (permalink / raw)
To: Maxwell Doose
Cc: David Lechner, Nuno Sá, Andy Shevchenko, Vladimir Zapolskiy,
Piotr Wojtaszczyk, Hartmut Knaack,
open list:IIO SUBSYSTEM AND DRIVERS,
moderated list:ARM/LPC32XX SOC SUPPORT, open list, Sangyun Kim,
Kyungwook Boo, Jaeyoung Chung
In-Reply-To: <20260613005812.160572-1-m32285159@gmail.com>
On Fri, 12 Jun 2026 19:58:09 -0500
Maxwell Doose <m32285159@gmail.com> wrote:
> Hi all,
>
> This short patch series fixes the issues raised by Jaeyoung Chung,
> Sangyun Kim, and Kyungwook Boo regarding init_completion() and spurious
> IRQs. The report is linked below [1], but I will also put it here
> inline:
>
> "lpc32xx_adc_probe() in drivers/iio/adc/lpc32xx_adc.c and
> spear_adc_probe() in drivers/iio/adc/spear_adc.c register their
> interrupt handler with devm_request_irq() before they initialize
> st->completion with init_completion(). If an interrupt arrives after
> devm_request_irq() and before init_completion(), the handler calls
> complete() on an uninitialized completion, causing a kernel panic.
>
> The probe path, in lpc32xx_adc_probe():
>
> iodev = devm_iio_device_alloc(&pdev->dev, sizeof(*st)); /* st kzalloc-zeroed */
> ...
> retval = devm_request_irq(&pdev->dev, irq, lpc32xx_adc_isr, 0,
> LPC32XXAD_NAME, st); /* register handler */
> ...
> init_completion(&st->completion); /* initialize completion */
>
> spear_adc_probe() has the same ordering: devm_request_irq() for
> spear_adc_isr() before init_completion(&st->completion).
>
> Both interrupt handlers, lpc32xx_adc_isr() and spear_adc_isr(), call
> complete():
>
> complete(&st->completion);
>
> If the device raises an interrupt before init_completion() runs,
> complete() acquires the uninitialized wait.lock and walks the zeroed
> task_list in swake_up_locked(). The zeroed task_list makes list_empty()
> return false, so swake_up_locked() dereferences a NULL list entry,
> triggering a KASAN wild-memory-access.
>
> Suggested fix: move init_completion(&st->completion) above
> devm_request_irq(), so the completion is valid before the handler can run.
>
> Reported-by: Sangyun Kim <sangyun.kim@snu.ac.kr>
> Reported-by: Kyungwook Boo <bookyungwook@gmail.com>"
>
> + Reported-by: Jaeyoung Chung <jjy600901@snu.ac.kr>
>
> Quick note, I ended up editing the report a little in the individual
> commits to match the driver we were fixing.
>
> [1] Link: https://lore.kernel.org/linux-iio/20260610115700.774689-1-jjy600901@snu.ac.kr/
Applied to the fixes-togreg branch of iio.git and marked for stable.
Note that I'll be rebasing on rc1 once available.
Thanks
Jonathan
>
> Maxwell Doose (2):
> iio: adc: lpc32xx: Initialize completion before requesting IRQ
> iio: adc: spear: Initialize completion before requesting IRQ
>
> drivers/iio/adc/lpc32xx_adc.c | 4 ++--
> drivers/iio/adc/spear_adc.c | 3 +--
> 2 files changed, 3 insertions(+), 4 deletions(-)
>
^ permalink raw reply
* Re: [PATCH v1 2/4] KVM: arm64: Move kvm_define_hypevents.h to arch/arm64/kvm/
From: Fuad Tabba @ 2026-06-14 13:41 UTC (permalink / raw)
To: Vincent Donnefort
Cc: maz, oliver.upton, joey.gouly, suzuki.poulose, yuzenghui,
catalin.marinas, will, rostedt, linux-arm-kernel, kvmarm,
kernel-team, qerret
In-Reply-To: <20260612142245.1015744-3-vdonnefort@google.com>
Hi Vincent,
On Fri, 12 Jun 2026 at 15:22, Vincent Donnefort <vdonnefort@google.com> wrote:
>
> kvm_define_hypevents.h is used to define the kernel-side structures for
> hypervisor events. It doesn't need to be used anywhere else than in
> hyp_trace.c.
>
> Move it to arch/arm64/kvm/
nit: rename and move
Reviewed-by: Fuad Tabba <tabba@google.com>
Tested-by: Fuad Tabba <tabba@google.com>
Cheers,
/fuad
>
> Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
>
> diff --git a/arch/arm64/include/asm/kvm_define_hypevents.h b/arch/arm64/kvm/define_hypevents.h
> similarity index 100%
> rename from arch/arm64/include/asm/kvm_define_hypevents.h
> rename to arch/arm64/kvm/define_hypevents.h
> diff --git a/arch/arm64/kvm/hyp_trace.c b/arch/arm64/kvm/hyp_trace.c
> index c4b3ee552131..821bc93ecdd1 100644
> --- a/arch/arm64/kvm/hyp_trace.c
> +++ b/arch/arm64/kvm/hyp_trace.c
> @@ -391,7 +391,7 @@ static struct trace_remote_callbacks trace_remote_callbacks = {
>
> static const char *__hyp_enter_exit_reason_str(u8 reason);
>
> -#include <asm/kvm_define_hypevents.h>
> +#include "define_hypevents.h"
>
> static const char *__hyp_enter_exit_reason_str(u8 reason)
> {
> --
> 2.54.0.1136.gdb2ca164c4-goog
>
^ permalink raw reply
* Re: [PATCH v1 1/4] KVM: arm64: Allow early calls to pKVM host_share/unshare_hyp
From: Fuad Tabba @ 2026-06-14 13:39 UTC (permalink / raw)
To: Vincent Donnefort
Cc: maz, oliver.upton, joey.gouly, suzuki.poulose, yuzenghui,
catalin.marinas, will, rostedt, linux-arm-kernel, kvmarm,
kernel-team
In-Reply-To: <20260612142245.1015744-2-vdonnefort@google.com>
On Fri, 12 Jun 2026 at 15:22, Vincent Donnefort <vdonnefort@google.com> wrote:
>
> The hypervisor tracing for pKVM relies on the __pkvm_host_share_hyp and
> __pkvm_host_unshare_hyp HVCs. In order to start tracing as early as
> possible, allow those two HVCs before the host is deprivileged.
>
> Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
To my good friend Sashiko:
https://lore.kernel.org/all/20260529121755.2923500-1-tabba@google.com/
The hyp_trace_load() issue seems legit though.
As for this patch itself:
Reviewed-by: Fuad Tabba <tabba@google.com>
Tested-by: Fuad Tabba <tabba@google.com>
Cheers,
/fuad
>
> diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h
> index 043495f7fc78..fb049c40d04f 100644
> --- a/arch/arm64/include/asm/kvm_asm.h
> +++ b/arch/arm64/include/asm/kvm_asm.h
> @@ -89,12 +89,12 @@ enum __kvm_host_smccc_func {
> __KVM_HOST_SMCCC_FUNC___vgic_v3_restore_vmcr_aprs,
> __KVM_HOST_SMCCC_FUNC___vgic_v5_save_apr,
> __KVM_HOST_SMCCC_FUNC___vgic_v5_restore_vmcr_apr,
> + __KVM_HOST_SMCCC_FUNC___pkvm_host_share_hyp,
> + __KVM_HOST_SMCCC_FUNC___pkvm_host_unshare_hyp,
>
> MARKER(__KVM_HOST_SMCCC_FUNC_PKVM_ONLY),
>
> /* Hypercalls that are available only when pKVM has finalised. */
> - __KVM_HOST_SMCCC_FUNC___pkvm_host_share_hyp,
> - __KVM_HOST_SMCCC_FUNC___pkvm_host_unshare_hyp,
> __KVM_HOST_SMCCC_FUNC___pkvm_host_donate_guest,
> __KVM_HOST_SMCCC_FUNC___pkvm_host_share_guest,
> __KVM_HOST_SMCCC_FUNC___pkvm_host_unshare_guest,
> diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> index 06db299c37a8..f0c52667cf52 100644
> --- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> +++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> @@ -721,9 +721,9 @@ static const hcall_t host_hcall[] = {
> HANDLE_FUNC(__vgic_v3_restore_vmcr_aprs),
> HANDLE_FUNC(__vgic_v5_save_apr),
> HANDLE_FUNC(__vgic_v5_restore_vmcr_apr),
> -
> HANDLE_FUNC(__pkvm_host_share_hyp),
> HANDLE_FUNC(__pkvm_host_unshare_hyp),
> +
> HANDLE_FUNC(__pkvm_host_donate_guest),
> HANDLE_FUNC(__pkvm_host_share_guest),
> HANDLE_FUNC(__pkvm_host_unshare_guest),
> --
> 2.54.0.1136.gdb2ca164c4-goog
>
^ permalink raw reply
* Re: [PATCH 4/7] drivers: staging: media: sunxi: cedrus: add H616 variant
From: Jernej Škrabec @ 2026-06-14 13:36 UTC (permalink / raw)
To: wens
Cc: Maxime Ripard, Paul Kocialkowski, Mauro Carvalho Chehab,
Jernej Skrabec, Samuel Holland, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Greg Kroah-Hartman, linux-media, linux-staging,
devicetree, linux-sunxi, linux-arm-kernel, linux-kernel
In-Reply-To: <CAGb2v677Pi9s3eWC7aXh8j=+eJh7AV5Mucr7SDXMN9Lo8yA2nA@mail.gmail.com>
Dne sobota, 13. junij 2026 ob 16:34:00 Srednjeevropski poletni čas je Chen-Yu Tsai napisal(a):
> On Sat, Jun 13, 2026 at 6:33 PM Jernej Škrabec <jernej.skrabec@gmail.com> wrote:
> >
> > Dne sobota, 30. maj 2026 ob 18:43:05 Srednjeevropski poletni čas je Chen-Yu Tsai napisal(a):
> > > On Tue, May 5, 2026 at 7:18 PM Jernej Škrabec <jernej.skrabec@gmail.com> wrote:
> > > >
> > > > Dne torek, 5. maj 2026 ob 15:48:08 Srednjeevropski poletni čas je Chen-Yu Tsai napisal(a):
> > > > > The Allwinner H616 SoC has a video engine hardware block like the one
> > > > > found on previous generations such as the H6. In addition to the
> > > > > currently supported features of the H6, it is also supposed to include
> > > >
> > > > Remove "supposed".
> > >
> > > I can't actually verify that, so "supposed" is accurate from my point of
> > > view.
> >
> > Isn't info from manual good enough?
>
> The manual says the SoC supports it. Same was said for the H6. Then
> we discovered that the VP9 decoder was a separate Hantro block.
>
> So again, *I* cannot claim in the commit message that the hardware
> block supports VP9 decoding, because I have not verified it.
>
> > In the interest of unblocking this, I would be fine with "supposed" too,
> > but manual and all my experiments show VP9 is supported.
>
> Please give an ack or reviewed-by with a comment at the end stating
> VP9 verified.
Well, just go with original text.
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Best regards,
Jernej
>
>
> Thanks
> ChenYu
>
>
> > Best regards,
> > Jernej
> >
> > >
> > > ChenYu
> > >
> > > > > a VP9 decoder. However software support for this is currently missing
> > > > > and still needs to be reverse engineered from the vendor BSP.
> > > > >
> > > > > Add the compatible for the H616 variant, using the H6 variant data.
> > > > >
> > > > > Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
> > > >
> > > > With that:
> > > > Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
> > > >
> > > > Best regards,
> > > > Jernej
> > > >
> > > >
> > >
> >
> >
> >
> >
> >
>
^ permalink raw reply
* Re: [PATCH v10 4/6] dt-bindings: sun6i-a31-mipi-dphy: Add V3s SoC compatible entry
From: Paul Kocialkowski @ 2026-06-14 13:28 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-media, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel, Yong Deng, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Michael Turquette, Stephen Boyd, Brian Masney,
Maxime Ripard
In-Reply-To: <20260613-nondescript-sociable-goat-aee13a@quoll>
[-- Attachment #1: Type: text/plain, Size: 1535 bytes --]
Hi,
Le Sat 13 Jun 26, 20:22, Krzysztof Kozlowski a écrit :
> On Sat, Jun 13, 2026 at 05:26:53PM +0200, Paul Kocialkowski wrote:
> > The V3s/V3/S3 comes with a rx-only D-PHY paired with the MIPI CSI-2
> > controller. It is compatible with the D-PHY found on the A31.
> >
> > Add an entry with a new compatible and the A31 compatible as fallback.
> >
> > Signed-off-by: Paul Kocialkowski <paulk@sys-base.io>
> > ---
> > .../devicetree/bindings/phy/allwinner,sun6i-a31-mipi-dphy.yaml | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/phy/allwinner,sun6i-a31-mipi-dphy.yaml b/Documentation/devicetree/bindings/phy/allwinner,sun6i-a31-mipi-dphy.yaml
> > index 6a4fd4929959..3ca1a1c47032 100644
> > --- a/Documentation/devicetree/bindings/phy/allwinner,sun6i-a31-mipi-dphy.yaml
> > +++ b/Documentation/devicetree/bindings/phy/allwinner,sun6i-a31-mipi-dphy.yaml
> > @@ -21,6 +21,9 @@ properties:
> > - items:
> > - const: allwinner,sun50i-a64-mipi-dphy
> > - const: allwinner,sun6i-a31-mipi-dphy
> > + - items:
> > + - const: allwinner,sun8i-v3s-mipi-dphy
>
> So that's enum with previous first entry (50i-a64) - same fallback.
Ah sorry about that. Thanks for the review!
All the best,
Paul
--
Paul Kocialkowski,
Independent contractor - sys-base - https://www.sys-base.io/
Free software developer - https://www.paulk.fr/
Expert in multimedia, graphics and embedded hardware support with Linux.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] ARM: dts: exynos: Add bluetooth support to manta
From: Krzysztof Kozlowski @ 2026-06-14 13:25 UTC (permalink / raw)
To: Lukas Timmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Alim Akhtar
Cc: devicetree, linux-arm-kernel, linux-samsung-soc, linux-kernel,
Alexandre Marquet
In-Reply-To: <ai2OYGlCx0x4NUs8@archstation>
On 13/06/2026 19:11, Lukas Timmermann wrote:
> #include <atomic>
> On Mon, Apr 27, 2026 at 03:49:34PM +0200, Krzysztof Kozlowski wrote:
>> On 08/04/2026 13:56, Lukas Timmermann wrote:
>>> Enable the bcm4330-bt device for manta boards on serial0.
>>> Also adds the necessary pin definitions and interrupt handling for
>>> wakeup.
>>>
>>> Signed-off-by: Lukas Timmermann <linux@timmermann.space>
>>> Co-developed-by: Alexandre Marquet <tb@a-marquet.fr>
>>> Signed-off-by: Alexandre Marquet <tb@a-marquet.fr>
>>
>> Incomplete/incorrect DCO chain. Please do not reorder tags. Git does
>> them correctly, so you HAD to change them manually.
>>
>> You send the patch or you apply the patch so you must commit with sign off.
> I developed the actual patch based on his findings. We both don't really
> care about who is mentioned first or anything.
>
> Sorry. Yes I rearranged stuff. So it should be:
>
> co-dev: alex
> sign-off: alex
> co-dev: me
> sign-off: me
>
> Correct?
>>
Yes
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v1 0/4] trace_hyp_printk() for pKVM/nVHE hypervisor
From: Fuad Tabba @ 2026-06-14 12:57 UTC (permalink / raw)
To: Vincent Donnefort
Cc: maz, oliver.upton, joey.gouly, suzuki.poulose, yuzenghui,
catalin.marinas, will, rostedt, linux-arm-kernel, kvmarm,
kernel-team, qerret
In-Reply-To: <20260612142245.1015744-1-vdonnefort@google.com>
Hi Vincent,
On Fri, 12 Jun 2026 at 15:22, Vincent Donnefort <vdonnefort@google.com> wrote:
>
> Hi all,
>
> This series adds a hypervisor event "hyp_printk" which enables
> developers to log pretty much anything into the hypervisor tracing
> buffer, just like the kernel function trace_printk().
>
> This enables rich logging from the hypervisor, while leaving all the
> string parsing burden to the kernel. This has been the main way of
> debugging pKVM in Android.
I tested the series on v7.1-rc7 under QEMU (cortex-a53 CPU, pKVM nVHE):
- Booted a host under pKVM with a non-protected kvmtool guest (npVM)
and a protected kvmtool guest (pVM).
- Functional test: added a temporary trace_hyp_printk() call site in
handle___kvm_vcpu_run() with 0-arg, 1-arg, and 2-arg calls. Mounted
tracefs, enabled the hyp_printk event, ran a kvmtool guest to trigger
vcpu_run, read the trace buffer. All expected entries appeared with
correctly formatted output.
One question: kvm_hyp_trace_init() returns early when
is_kernel_in_hyp_mode() is true. On VHE-capable hardware, pKVM uses
hVHE. So it seams that the entire hyp tracing subsystem (not just
hyp_printk) is non-functional in hVHE mode. Is hVHE support
intentionally deferred?
Cheers,
/fuad
>
> Even though not strictly related to trace_hyp_printk, I have added the
> following two patches:
>
> * KVM: arm64: Allow early calls to pKVM host_share/unshare_hyp
>
> This one mainly intends to support one of the new features I have
> posted here [1], which allows to enable tracing as early as
> possible. I have added it here to limit cross-posting.
>
> * KVM: arm64: Move kvm_define_hypevents.h to arch/arm64/kvm/
>
> This one is just a cleanup.
>
> [1] https://lore.kernel.org/all/20260605163825.1762953-1-vdonnefort@google.com/
>
> Vincent Donnefort (4):
> KVM: arm64: Allow early calls to pKVM host_share/unshare_hyp
> KVM: arm64: Move kvm_define_hypevents.h to arch/arm64/kvm/
> tracing/remotes: Add REMOTE_EVENT_CUSTOM_PRINTK() helper
> KVM: arm64: Add hyp_printk event to nVHE/pKVM hyp
>
> arch/arm64/include/asm/kvm_asm.h | 4 +-
> arch/arm64/include/asm/kvm_hypevents.h | 14 ++++
> arch/arm64/include/asm/kvm_hyptrace.h | 8 +++
> arch/arm64/kernel/image-vars.h | 1 +
> arch/arm64/kernel/vmlinux.lds.S | 4 ++
> .../define_hypevents.h} | 0
> .../kvm/hyp/include/nvhe/define_events.h | 2 -
> arch/arm64/kvm/hyp/include/nvhe/trace.h | 65 +++++++++++++++++++
> arch/arm64/kvm/hyp/nvhe/events.c | 6 ++
> arch/arm64/kvm/hyp/nvhe/hyp-main.c | 2 +-
> arch/arm64/kvm/hyp_trace.c | 60 ++++++++++++++++-
> include/trace/define_remote_events.h | 19 +++++-
> 12 files changed, 176 insertions(+), 9 deletions(-)
> rename arch/arm64/{include/asm/kvm_define_hypevents.h => kvm/define_hypevents.h} (100%)
>
>
> base-commit: 4549871118cf616eecdd2d939f78e3b9e1dddc48
> --
> 2.54.0.1136.gdb2ca164c4-goog
>
^ permalink raw reply
* Re: [PATCH RFC 4/4] Documentation/kernel-parameters: add/update printk_delay/boot_delay
From: Andrew Murray @ 2026-06-14 12:55 UTC (permalink / raw)
To: Petr Mladek
Cc: Jonathan Corbet, Shuah Khan, Russell King, Florian Fainelli,
Broadcom internal kernel review list, Ray Jui, Scott Branden,
Steven Rostedt, John Ogness, Sergey Senozhatsky, Andrew Morton,
Sebastian Andrzej Siewior, Clark Williams, Randy Dunlap,
Linus Torvalds, linux-doc, linux-kernel, linux-arm-kernel,
linux-rpi-kernel, linux-rt-devel
In-Reply-To: <aibfFQpK0Se-SiaT@pathway.suse.cz>
On Mon, 8 Jun 2026 at 16:26, Petr Mladek <pmladek@suse.com> wrote:
>
> On Mon 2026-06-01 00:17:40, Andrew Murray wrote:
> > boot_delay has been deprecated in favour of an extended printk_delay,
> > let's update kernel-parameters to reflect the addition of printk_delay
> > and the deprecation of boot_delay.
> >
> > Signed-off-by: Andrew Murray <amurray@thegoodpenguin.co.uk>
>
> LGTM:
>
> Reviewed-by: Petr Mladek <pmladek@suse.com>
>
> Best Regards,
> Petr
Thanks for the reviews!
Andrew Murray
^ permalink raw reply
* Re: [PATCH RFC 3/4] printk: nbcon: move printk_delay to console emiting code
From: Andrew Murray @ 2026-06-14 12:55 UTC (permalink / raw)
To: Petr Mladek
Cc: Jonathan Corbet, Shuah Khan, Russell King, Florian Fainelli,
Broadcom internal kernel review list, Ray Jui, Scott Branden,
Steven Rostedt, John Ogness, Sergey Senozhatsky, Andrew Morton,
Sebastian Andrzej Siewior, Clark Williams, Randy Dunlap,
Linus Torvalds, linux-doc, linux-kernel, linux-arm-kernel,
linux-rpi-kernel, linux-rt-devel
In-Reply-To: <aibe12WcrLxVWTez@pathway.suse.cz>
On Mon, 8 Jun 2026 at 16:25, Petr Mladek <pmladek@suse.com> wrote:
>
> On Mon 2026-06-01 00:17:39, Andrew Murray wrote:
> > The printk_delay and boot_delay features are helpful for debugging
> > as kernel output can be slowed down during boot allowing messages to
> > be seen before scrolling off the screen, or to correlate timing between
> > some physical event and console output.
> >
> > However, since the introduction of nbcon and the legacy printer thread
> > for PREEMPT_RT kernels, printk records are now emited to the console
> > asynchronously to the caller of printk. Thus, any printk delay added by
> > boot_delay/printk_delay continues to slow down the calling process but
> > may not have any impact to the rate in which records are emited to the
> > console.
> >
> > Let's address this by moving the printk delay from the calling code
> > to the console emiting code instead. Whilst this ensures that delays
> > are still observed (especially for slower consoles), it doesn't improve
> > the use-case of using boot_delay/printk_delay to correlate timings
> > between physical events and console output.
> >
> > --- a/include/linux/printk.h
> > +++ b/include/linux/printk.h
>
> The declaration is needed just inside kernel/printk/ directory.
> It should better be done via kernel/printk/internal.h
OK.
>
> > @@ -209,6 +209,7 @@ extern bool nbcon_device_try_acquire(struct console *con);
> > extern void nbcon_device_release(struct console *con);
> > void nbcon_atomic_flush_unsafe(void);
> > bool pr_flush(int timeout_ms, bool reset_on_progress);
> > +void printk_delay(bool use_atomic);
> > #else
> > static inline __printf(1, 0)
> > int vprintk(const char *s, va_list args)
> > @@ -326,6 +327,9 @@ static inline bool pr_flush(int timeout_ms, bool reset_on_progress)
> > {
> > return true;
> > }
> > +static inline void printk_delay(bool use_atomic)
> > +{
> > +}
> >
> > #endif
> >
> > diff --git a/kernel/printk/nbcon.c b/kernel/printk/nbcon.c
> > index d7044a7a214bdd4537a5e20d876d99bc3ffe8b3a..a507a2fed5bf4366e24330f763b842a698ecf6f7 100644
> > --- a/kernel/printk/nbcon.c
> > +++ b/kernel/printk/nbcon.c
> > @@ -1267,11 +1267,16 @@ static int nbcon_kthread_func(void *__console)
> >
> > con_flags = console_srcu_read_flags(con);
> >
> > + wctxt.len = 0;
> > +
> > if (console_is_usable(con, con_flags, false))
> > backlog = nbcon_emit_one(&wctxt, false);
> >
> > console_srcu_read_unlock(cookie);
> >
> > + if (backlog && wctxt.len > 0)
>
> Heh, this is tricky. It might probably work but it is not guarantted
> by design.
>
> The "backlog" name is a bit misleading. The value is basically
> wctxt.ctxt.backlog. The real meaning is that printk_get_next_message()
> was able to read a message. It means that there _was_ a backlog.
> But it is not clear whether there are still pending messages or not.
Yes I found that to be the case (see my notes in the cover letter) -
backlog is only true if a record was successfully retrieved, though
that record may be one that is suppressed.
>
> Also it is not clear that whether the message was pushed to the
> console or not. It might have been supressed in which case
> (wctxt.len == 0). But it might also be emitted only partially
> when a higher priority context took over the console context
> ownership.
You say it might probably work but isn't guaranteed by design, I'm
struggling to see what I've missed...
As far as I could tell, nbcon_emit_next_record only returns true when
a record has been printed and it still has context. The only exception
to that is where pmsg.outbuf_len is zero (suppressed), in which case
it may return true. Thus if (nbcon_emit_next_record() &&
!pmsg.outbuf_len) then we can be sure a record was printed. In order
to apply this test from the various callers...
for nbcon_emit_one - this returns ctxt->backlog if
nbcon_emit_next_record returned true. But backlog is *always* true
when nbcon_emit_next_record returns true. Thus the test of (backlog &&
wctxt.len) is equivelant to (nbcon_emit_next_record() &&
!pmsg.outbuf_len).
So I still think this implementation is valid.
>
> I would prefer to explicitely set some flag when
> nbcon_emit_next_record() really called con->write*().
> See below.
>
> > + printk_delay(false);
> > +
> > cond_resched();
> >
> > } while (backlog);
> > @@ -1525,6 +1530,8 @@ bool nbcon_legacy_emit_next_record(struct console *con, bool *handover,
> > }
> >
> > progress = nbcon_emit_one(&wctxt, use_atomic);
> > + if (progress && wctxt.len > 0)
>
> Same here.
>
> > + printk_delay(use_atomic);
> >
> > if (use_atomic) {
> > start_critical_timings();
> > @@ -1584,6 +1591,8 @@ static int __nbcon_atomic_flush_pending_con(struct console *con, u64 stop_seq)
> > if (!nbcon_context_try_acquire(ctxt, false))
> > return -EPERM;
> >
> > + wctxt.len = 0;
> > +
> > /*
> > * nbcon_emit_next_record() returns false when
> > * the console was handed over or taken over.
> > @@ -1595,7 +1604,9 @@ static int __nbcon_atomic_flush_pending_con(struct console *con, u64 stop_seq)
> > nbcon_context_release(ctxt);
> > }
> >
> > - if (!ctxt->backlog) {
> > + if (ctxt->backlog && wctxt.len > 0) {
> > + printk_delay(true);
> > + } else {
>
> This changes the semantic. The original code call this when
> no message was read. The new code would call this path also
> when the output was suppressed. It would probably work.
> But still.
Ah, good spot! I missed that.
>
> > /* Are there reserved but not yet finalized records? */
> > if (nbcon_seq_read(con) < stop_seq)
> > err = -ENOENT;
>
>
> As mentioned above, I would add a flag which would be set when
> con->write*() was called.
I'm not sure why I tried to avoid adding members to nbcon_context, but
I prefer your solution, it isn't so fragile, and makes it easier to
understand. I'll update for my next revision.
>
> It modifies the type of unsafe_takeover in struct nbcon_write_context.
> But it actually makes it more compatible with struct nbcon_state.
What is the intent of this change (bool to unsigned char)?
>
> My proposal (on top of this patch):
>
> diff --git a/include/linux/console.h b/include/linux/console.h
> index 5520e4477ad7..5a86942e55ef 100644
> --- a/include/linux/console.h
> +++ b/include/linux/console.h
> @@ -290,6 +290,7 @@ struct nbcon_context {
> * @outbuf: Pointer to the text buffer for output
> * @len: Length to write
> * @unsafe_takeover: If a hostile takeover in an unsafe state has occurred
> + * @emitted: The write context tried to emit the message. Might be incomplete.
> * @cpu: CPU on which the message was generated
> * @pid: PID of the task that generated the message
> * @comm: Name of the task that generated the message
> @@ -298,7 +299,8 @@ struct nbcon_write_context {
> struct nbcon_context __private ctxt;
> char *outbuf;
> unsigned int len;
> - bool unsafe_takeover;
> + unsigned char unsafe_takeover : 1;
> + unsigned char emitted : 1
> #ifdef CONFIG_PRINTK_EXECUTION_CTX
> int cpu;
> pid_t pid;
> diff --git a/kernel/printk/nbcon.c b/kernel/printk/nbcon.c
> index a507a2fed5bf..060534becefc 100644
> --- a/kernel/printk/nbcon.c
> +++ b/kernel/printk/nbcon.c
> @@ -1069,6 +1069,9 @@ static bool nbcon_emit_next_record(struct nbcon_write_context *wctxt, bool use_a
> else
> con->write_thread(con, wctxt);
>
> + /* Tried to emit something. Might be incomplete. */
> + wctxt.emitted = 1;
> +
> if (!wctxt->outbuf) {
> /*
> * Ownership was lost and reacquired by the driver. Handle it
> @@ -1267,14 +1270,14 @@ static int nbcon_kthread_func(void *__console)
>
> con_flags = console_srcu_read_flags(con);
>
> - wctxt.len = 0;
> + wctxt.emitted = 0;
>
> if (console_is_usable(con, con_flags, false))
> backlog = nbcon_emit_one(&wctxt, false);
>
> console_srcu_read_unlock(cookie);
>
> - if (backlog && wctxt.len > 0)
> + if (wctxt.emitted)
> printk_delay(false);
>
> cond_resched();
> @@ -1530,7 +1533,7 @@ bool nbcon_legacy_emit_next_record(struct console *con, bool *handover,
> }
>
> progress = nbcon_emit_one(&wctxt, use_atomic);
> - if (progress && wctxt.len > 0)
> + if (wctxt.emitted)
> printk_delay(use_atomic);
>
> if (use_atomic) {
> @@ -1591,7 +1594,7 @@ static int __nbcon_atomic_flush_pending_con(struct console *con, u64 stop_seq)
> if (!nbcon_context_try_acquire(ctxt, false))
> return -EPERM;
>
> - wctxt.len = 0;
> + wctxt.emitted = 0;
>
> /*
> * nbcon_emit_next_record() returns false when
> @@ -1604,9 +1607,10 @@ static int __nbcon_atomic_flush_pending_con(struct console *con, u64 stop_seq)
> nbcon_context_release(ctxt);
> }
>
> - if (ctxt->backlog && wctxt.len > 0) {
> + if (wctxt.emitted)
> printk_delay(true);
> - } else {
> +
> + if (!ctxt->backlog) {
> /* Are there reserved but not yet finalized records? */
> if (nbcon_seq_read(con) < stop_seq)
> err = -ENOENT;
Thanks,
Andrew Murray
^ permalink raw reply
* Re: [PATCH v2] Input: apple_z2 - bound the device-reported finger count
From: Joshua Peisach @ 2026-06-14 12:24 UTC (permalink / raw)
To: hexlabsecurity, Sasha Finkelstein, Dmitry Torokhov
Cc: linux-kernel, Janne Grunau, linux-arm-kernel, linux-input,
Sven Peter, asahi, Neal Gompa
In-Reply-To: <20260613-b4-disp-4ebcbd68-v2-1-0161acfbd688@proton.me>
On Sat Jun 13, 2026 at 9:22 PM EDT, Bryam Vargas via B4 Relay wrote:
> From: Bryam Vargas <hexlabsecurity@proton.me>
>
> apple_z2_parse_touches() takes the finger count from the touch
> controller's report and loops over that many fixed-size finger records
> without ever checking the count against the length of the report:
>
> nfingers = msg[APPLE_Z2_NUM_FINGERS_OFFSET];
> fingers = (struct apple_z2_finger *)(msg + APPLE_Z2_FINGERS_OFFSET);
> for (i = 0; i < nfingers; i++)
> /* read fingers[i] ... */
>
> msg points into the fixed 4000-byte z2->rx_buf and nfingers is a single
> device-supplied byte, so it can be as large as 255. A malicious,
> malfunctioning or counterfeit controller (or an interposer on the SPI
> bus) can report a large finger count in a short packet, making the loop
> read up to 255 * sizeof(struct apple_z2_finger) bytes starting 24 bytes
> into msg -- far past the 4000-byte buffer. This is a controller-driven
> heap out-of-bounds read, and the finger fields that are read (position,
> pressure, touch and tool dimensions) are forwarded to userspace as input
> events, leaking adjacent kernel memory.
>
> Bound the device-reported count to the number of finger records the
> report actually carries.
>
> Reported-by: sashiko-bot@kernel.org
> Closes: https://lore.kernel.org/all/20260613215358.329921F000E9@smtp.kernel.org/
> Fixes: 471a92f8a21a ("Input: apple_z2 - add a driver for Apple Z2 touchscreens")
> Cc: stable@vger.kernel.org
> Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me>
> ---
> Changes since v1 [1]:
> - Keep the early-return at NUM_FINGERS_OFFSET instead of moving it to
> FINGERS_OFFSET, so a short zero-finger ("all lifted") report still
> reaches input_mt_sync_frame()/input_sync() and does not leave touches
> stuck on the screen (caught by the sashiko-bot review of v1 [2]). A
> packet too short to hold even one finger record clamps nfingers to 0
> instead of being dropped.
>
> [1] https://lore.kernel.org/all/20260613-b4-disp-f0148c89-v1-1-868a48b2a187@proton.me/
> [2] https://lore.kernel.org/all/20260614000725.6B8D11F000E9@smtp.kernel.org/
>
> Reachable on every touch interrupt once the controller is booted
> (apple_z2_irq -> apple_z2_read_packet -> apple_z2_parse_touches).
>
> nfingers is bounded here by the message length; the message length is in
> turn bounded by the companion "Input: apple_z2 - bound the device-reported
> packet length" change (in flight), which caps the device-reported pkt_len
> to the 4000-byte receive buffer. The two together close the device-driven
> out-of-bounds accesses in apple_z2_parse_touches() / apple_z2_read_packet().
>
> Verified with a faithful in-kernel KASAN litmus (the verbatim 4000-byte
> buffer, the struct apple_z2_finger layout and the parse loop),
> CONFIG_KASAN=y on x86_64:
>
> Arm A, nfingers = 255 in a short packet (msg_len 19):
> BUG: KASAN: slab-out-of-bounds in apple_z2_parse_touches
> Read of size 2 ... 1 bytes to the right of allocated 4000-byte region
> ... cache kmalloc-4k of size 4096
> Arm B, with this patch: a zero-finger report (msg_len 19) reaches the
> sync; a 255-finger claim is clamped to what the packet holds; clean.
> Arm C, benign device (3 fingers): clean
>
> AddressSanitizer (x86_64 and i386): heap-buffer-overflow READ, both ABIs.
>
> Reproducer and full logs available on request.
> ---
> drivers/input/touchscreen/apple_z2.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/input/touchscreen/apple_z2.c b/drivers/input/touchscreen/apple_z2.c
> index 271ababf0ad5..39ade83ef0de 100644
> --- a/drivers/input/touchscreen/apple_z2.c
> +++ b/drivers/input/touchscreen/apple_z2.c
> @@ -92,6 +92,12 @@ static void apple_z2_parse_touches(struct apple_z2 *z2,
> return;
> nfingers = msg[APPLE_Z2_NUM_FINGERS_OFFSET];
> fingers = (struct apple_z2_finger *)(msg + APPLE_Z2_FINGERS_OFFSET);
> + /* a malicious controller can claim more fingers than the packet holds */
> + if (msg_len < APPLE_Z2_FINGERS_OFFSET)
> + nfingers = 0;
> + else
> + nfingers = min_t(int, nfingers,
> + (msg_len - APPLE_Z2_FINGERS_OFFSET) / sizeof(*fingers));
> for (i = 0; i < nfingers; i++) {
> slot = input_mt_get_slot_by_key(z2->input_dev, fingers[i].finger);
> if (slot < 0) {
>
> ---
> base-commit: 8e65320d91cdc3b241d4b94855c88459b91abf66
> change-id: 20260613-b4-disp-4ebcbd68-ed8a28672ccc
>
> Best regards,
Reviewed-by: Joshua Peisach <jpeisach@ubuntu.com>
^ permalink raw reply
* Re: [PATCH] ARM: disable broken eBPF JIT on the Risc PC
From: David Laight @ 2026-06-14 11:58 UTC (permalink / raw)
To: Ethan Nelson-Moore
Cc: linux-arm-kernel, linux-kernel, stable, Russell King,
Russell King (Oracle), Arnd Bergmann, Linus Walleij, Kees Cook,
Nathan Chancellor, Thomas Weissschuh, Peter Zijlstra,
Shubham Bansal, David S. Miller
In-Reply-To: <20260518014920.135011-1-enelsonmoore@gmail.com>
On Sun, 17 May 2026 18:49:17 -0700
Ethan Nelson-Moore <enelsonmoore@gmail.com> wrote:
> The eBPF JIT unconditionally generates ldrh/strh instructions, which do
> not function correctly on the Risc PC because its bus is unable to
> signal half-word accesses. Work around this issue by disabling the eBPF
> JIT when building for ARMv3 (the Risc PC is the only currently
> supported ARMv3 machine).
Isn't it more the case that the ldrh/strh instructions were added for armv4.
Whether the bus supports 16bit accesses is entirely different.
I'm guessing that WRITE_ONCE() gets implemented as two 8-bit writes and
the code 'just hopes' than an ISR won't care and won't do an update.
David
>
> Fixes: 39c13c204bb1 ("arm: eBPF JIT compiler")
> Cc: stable@vger.kernel.org
> Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
> ---
> arch/arm/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 1155c78bb6aa..8185d013e5d1 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -98,7 +98,7 @@ config ARM
> select HAVE_ARCH_TRACEHOOK
> select HAVE_ARCH_TRANSPARENT_HUGEPAGE if ARM_LPAE
> select HAVE_ARM_SMCCC if CPU_V7
> - select HAVE_EBPF_JIT if !CPU_ENDIAN_BE32
> + select HAVE_EBPF_JIT if !CPU_ENDIAN_BE32 && !CPU_32v3
> select HAVE_CONTEXT_TRACKING_USER
> select HAVE_C_RECORDMCOUNT
> select HAVE_BUILDTIME_MCOUNT_SORT
^ permalink raw reply
* Re: [PATCH RFC 2/4] printk: deprecate boot_delay in favour of printk_delay
From: Andrew Murray @ 2026-06-14 11:45 UTC (permalink / raw)
To: Petr Mladek
Cc: Jonathan Corbet, Shuah Khan, Russell King, Florian Fainelli,
Broadcom internal kernel review list, Ray Jui, Scott Branden,
Steven Rostedt, John Ogness, Sergey Senozhatsky, Andrew Morton,
Sebastian Andrzej Siewior, Clark Williams, Randy Dunlap,
Linus Torvalds, linux-doc, linux-kernel, linux-arm-kernel,
linux-rpi-kernel, linux-rt-devel
In-Reply-To: <aibMr16r55xE26rU@pathway.suse.cz>
On Mon, 8 Jun 2026 at 15:07, Petr Mladek <pmladek@suse.com> wrote:
>
> On Mon 2026-06-01 00:17:38, Andrew Murray wrote:
> > The boot_delay (BOOT_PRINTK_DELAY) kernel parameter and printk_delay sysctl
> > are two distinct mechanisms for providing similar functionality which add a
> > delay prior to each printed printk message.
> >
> > boot_delay provides a kernel parameter for delaying printk output from
> > kernel start through to boot (SYSTEM_RUNNING), whereas printk_delay is
> > configurable only via sysctl and thus is only used post boot.
> >
> > Let's deprecate the boot_delay feature in favour of printk_delay. In order
> > to preserve functionality, we'll also extend printk_delay such that it can
> > additionally configured via a kernel parameter.
>
> I would make it clear and say: "via an early kernel parameter".
>
> Note that there are also kernel parameters which can be modified at runtime
> via /sys/module/kernel/paramters/<parameter>
OK thanks, I will update.
>
> Also I would make it clear that this changes the behavior, for
> example:
>
> <proposal>
> Behavior change:
>
> The delay enabled by both "boot_delay" and "printk_delay" continues
> working even in SYSTEM_RUNNING state. It must be explicitly stopped
> by setting printk_delay=0 via sysctl.
>
> The delay is skipped when the message is suppressed in all system
> states. It used to skipped only for the boot_delay.
> </proposal>
Yes, I'm happy to make that clearer.
>
> > --- a/kernel/printk/printk.c
> > +++ b/kernel/printk/printk.c
> > @@ -1339,11 +1327,34 @@ static void boot_delay_msec(int level)
> > }
> > }
> > #else
> > -static inline void boot_delay_msec(int level)
> > +static inline void __init printk_delay_calculate(void)
> > +{
> > +}
> > +
> > +static inline void early_boot_delay_msec(void)
> > {
>
> It would be nice to print a warning that the early boot delay
> does not work, something like:
>
> pr_warn_once("Early boot delay does not work without CONFIG_GENERIC_CALIBRATE_DELAY enabled.\n");
>
> > }
> > #endif
> >
> > +static int __init printk_delay_setup(char *str)
> > +{
> > + get_option(&str, &printk_delay_msec);
> > + if (printk_delay_msec > 10 * 1000)
> > + printk_delay_msec = 0;
>
> Sashiko AI warns that this code accepts negative values.
> It might cause long delays, see
> https://sashiko.dev/#/patchset/20260601-deprecate_boot_delay-v1-0-c34c187142a6%40thegoodpenguin.co.uk
>
> The problem has already been there even before. But it would be nice
> to fix it.
Thanks for pointing out Sashiko, I hadn't seen its review on my
patches. Are authors expected to get emails from it, as I didn't?
In any case, it's a good spot, so I'll address.
>
> > +
> > + printk_delay_calculate();
> > +
> > + return 0;
> > +}
> > +early_param("printk_delay", printk_delay_setup);
> > +
> > +static int __init boot_delay_setup(char *str)
> > +{
> > + pr_warn("boot_delay will soon be deprecated, please use printk_delay instead");
> > + return printk_delay_setup(str);
> > +}
> > +early_param("boot_delay", boot_delay_setup);
> > +
> > static bool printk_time = IS_ENABLED(CONFIG_PRINTK_TIME);
> > module_param_named(time, printk_time, bool, S_IRUGO | S_IWUSR);
>
> Otherwise, it looks good to me.
>
> Best Regards,
> Petr
Thanks,
Andrew Murray
^ 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