From: sashiko-bot@kernel.org
To: "Marc Zyngier" <maz@kernel.org>
Cc: "Marc Zyngier" <maz@kernel.org>,
"Oliver Upton" <oupton@kernel.org>,
kvmarm@lists.linux.dev
Subject: Re: [PATCH 4/5] KVM: arm64: vgic-v3: Simplify initial GICv3 configuration sampling
Date: Mon, 20 Jul 2026 13:38:26 +0000 [thread overview]
Message-ID: <20260720133827.2A32C1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260720132220.2143486-6-maz@kernel.org>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The `noinstr` function `kvm_patch_ich_vtr_el2()` calls a non-`noinstr` function (`vgic_v3_broken_seis()`), causing a `noinstr` section violation.
- [Medium] `WARN_ON` inside the `noinstr` alternative patching callback `kvm_patch_ich_vtr_el2()` violates instrumentation rules and risks deadlocks.
--
--- Patch [4]: [PATCH 4/5] KVM: arm64: vgic-v3: Simplify initial GICv3 configuration sampling ---
commit bf26cd3d96184399493f95667d1786d9b2823890
Author: Marc Zyngier <maz@kernel.org>
KVM: arm64: vgic-v3: Simplify initial GICv3 configuration sampling
This commit simplifies the initial GICv3 configuration sampling by returning
early if GICv5 CPU interface support is present. It also inlines a workaround
for a broken locally generated SEI directly into the alternative patching
callback.
[ ... ]
> diff --git a/arch/arm64/kvm/vgic/vgic-v3.c b/arch/arm64/kvm/vgic/vgic-v3.c
> index ef62dd498f5cf..68d4a486df0a1 100644
> --- a/arch/arm64/kvm/vgic/vgic-v3.c
> +++ b/arch/arm64/kvm/vgic/vgic-v3.c
> @@ -906,6 +906,9 @@ void noinstr kvm_patch_ich_vtr_el2(struct alt_instr *alt,
>
> vtr = res.a1;
>
> + if (vgic_v3_broken_seis())
> + vtr &= ~ICH_VTR_EL2_SEIS;
[Severity: Medium]
Does this code call an instrumentable function from within a noinstr section?
Looking at vgic_v3_broken_seis(), it calls is_midr_in_range_list(). Calling an
instrumentable function from a noinstr function like kvm_patch_ich_vtr_el2()
breaks safety invariants, which can result in objtool build warnings or
ftrace/kprobe recursion deadlocks if the patching code is traced.
[Severity: Medium]
Also, just before this addition in kvm_patch_ich_vtr_el2(), there is a WARN_ON
call:
if (WARN_ON(res.a0 == HVC_STUB_ERR))
return;
vtr = res.a1;
Is it safe to use WARN_ON inside a noinstr alternative patching callback?
Alternative patching callbacks like kvm_patch_ich_vtr_el2() typically run under
stop_machine() with CPUs parked and interrupts disabled. If WARN_ON triggers,
it invokes the warning exception machinery which can attempt to acquire console
locks. If a parked CPU holds these locks, it could cause a hard deadlock.
Additionally, WARN_ON expands to instrumentable paths, directly violating
noinstr requirements.
> +
> /* Compute target register */
> oinsn = le32_to_cpu(*origptr);
> rd = aarch64_insn_decode_register(AARCH64_INSN_REGTYPE_RD, oinsn);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260720132220.2143486-1-maz@kernel.org?part=4
next prev parent reply other threads:[~2026-07-20 13:38 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-20 13:22 [PATCH 0/5] KVM: arm64: Make ICH_VTR_EL2 accesses an inlined literal Marc Zyngier
2026-07-20 13:22 ` [PATCH 1/5] KVM: arm64: vgic-v3: Make vtr_to_* helpers use architectural field symbols Marc Zyngier
2026-07-20 13:22 ` [PATCH 2/5] KVM: arm64: Add a helper providing an inlined literal value for ICH_VTR_EL2 Marc Zyngier
2026-07-20 13:46 ` sashiko-bot
2026-07-20 14:49 ` Marc Zyngier
2026-07-20 13:22 ` [PATCH 2/5] KVM: arm64: Add a helper providing an inlined litteral " Marc Zyngier
2026-07-20 13:22 ` [PATCH 3/5] KVM: arm64: Convert most ICH_VTR_EL2 accesses to inlined literal value Marc Zyngier
2026-07-20 13:22 ` [PATCH 4/5] KVM: arm64: vgic-v3: Simplify initial GICv3 configuration sampling Marc Zyngier
2026-07-20 13:38 ` sashiko-bot [this message]
2026-07-20 14:50 ` Marc Zyngier
2026-07-20 13:22 ` [PATCH 5/5] KVM: arm64: vgic-v3: Kill kvm_vgic_global_state.ich_vtr_el2 Marc Zyngier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260720133827.2A32C1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=maz@kernel.org \
--cc=oupton@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.