From: Marc Zyngier <maz@kernel.org>
To: sashiko-reviews@lists.linux.dev
Cc: kvmarm@lists.linux.dev, "Oliver Upton" <oupton@kernel.org>
Subject: Re: [PATCH 2/5] KVM: arm64: Add a helper providing an inlined literal value for ICH_VTR_EL2
Date: Mon, 20 Jul 2026 15:49:51 +0100 [thread overview]
Message-ID: <867bmpg1gw.wl-maz@kernel.org> (raw)
In-Reply-To: <20260720134628.BEB071F000E9@smtp.kernel.org>
On Mon, 20 Jul 2026 14:46:28 +0100,
sashiko-bot@kernel.org wrote:
>
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [High] The `kvm_patch_ich_vtr_el2()` helper fails to apply the `vgic_v3_broken_seis()` workaround mask to the `ICH_VTR_EL2` value.
> - [High] The `noinstr` function `kvm_patch_ich_vtr_el2()` calls out-of-line instrumentable functions, which violates `.noinstr.text` safety rules.
> --
>
> --- Patch [2]: [PATCH 2/5] KVM: arm64: Add a helper providing an inlined literal value for ICH_VTR_EL2 ---
> commit aedd950f23aaa5667277a7a495b598168c06eb84
> Author: Marc Zyngier <maz@kernel.org>
>
> KVM: arm64: Add a helper providing an inlined literal value for ICH_VTR_EL2
>
> This commit adds an alternative patching callback to provide an inlined
> literal value for the ICH_VTR_EL2 system register. It computes the value
> at boot time and patches it into the relevant code locations.
>
> > diff --git a/arch/arm64/kvm/vgic/vgic-v3.c b/arch/arm64/kvm/vgic/vgic-v3.c
> > index 9e841e7afd4a7..ef62dd498f5cf 100644
> > --- a/arch/arm64/kvm/vgic/vgic-v3.c
> > +++ b/arch/arm64/kvm/vgic/vgic-v3.c
> > @@ -876,6 +876,57 @@ void noinstr kvm_compute_ich_hcr_trap_bits(struct alt_instr *alt,
> > *updptr = cpu_to_le32(insn);
> > }
> >
> > +void noinstr kvm_patch_ich_vtr_el2(struct alt_instr *alt,
> > + __le32 *origptr, __le32 *updptr,
> > + int nr_inst)
> > +{
> > + struct arm_smccc_res res = {};
> > + u32 insn, oinsn, rd, vtr;
> > +
> > + /* No KVM? Nothing to do */
> > + if (!is_hyp_mode_available())
> > + return;
> > +
> > + /* No v3 (or v3 compat)? Nothing to do either */
> > + if (!this_cpu_has_cap(ARM64_HAS_GICV5_LEGACY) &&
> > + !this_cpu_has_cap(ARM64_HAS_GICV3_CPUIF))
> > + return;
>
> [Severity: High]
> Is it safe to call out-of-line and instrumentable functions like
> this_cpu_has_cap() from a noinstr context?
Yeah, that's borderline stupid. This should be "cpus_have_cap()".
>
> This violates the .noinstr.text safety rules and might expose the
> alternative patching sequence to ftrace, KASAN, and kprobes, potentially
> leading to recursive faults.
>
> [ ... ]
>
> > + if (WARN_ON(res.a0 == HVC_STUB_ERR))
> > + return;
>
> [Severity: High]
> Could WARN_ON() also expand to out-of-line instrumentable trap or warning
> functions, further violating the noinstr constraints of
> kvm_patch_ich_vtr_el2()?
I guess that if that fails, we will already have failed much earlier,
while probing for TDIR. I'll drop that.
>
> > +
> > + vtr = res.a1;
> > +
> > + /* Compute target register */
> > + oinsn = le32_to_cpu(*origptr);
>
> [Severity: High]
> Does this sequence miss the workaround mask for broken locally generated
> System Error Interrupts (SEI)?
It isn't missing. It is just that the relevant hunk is in the wrong
patch and needs to be moved here.
>
> The code reads SYS_ICH_VTR_EL2 and directly bakes it into instructions
> without applying the vgic_v3_broken_seis() mask to clear the
> ICH_VTR_EL2_SEIS bit. Affected hardware might incorrectly advertise SEI
> support as a result.
>
> > + rd = aarch64_insn_decode_register(AARCH64_INSN_REGTYPE_RD, oinsn);
> > +
> > + /* movz rd, #(vtr & 0xffff) */
> > + insn = aarch64_insn_gen_movewide(rd,
> > + (u16)vtr,
> > + 0,
> > + AARCH64_INSN_VARIANT_64BIT,
> > + AARCH64_INSN_MOVEWIDE_ZERO);
> > + *updptr++ = cpu_to_le32(insn);
>
> [Severity: High]
> Like this_cpu_has_cap() above, aarch64_insn_decode_register() and
> aarch64_insn_gen_movewide() are out-of-line C functions. Should these
> calls be avoided inside a noinstr patching callback to prevent recursive
> faulting during instruction patching?
That's something that needs to be separately addressed. There was some
work from Ada a long while ago that needs to be brought back to life.
M.
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2026-07-20 14:49 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 [this message]
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
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=867bmpg1gw.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=kvmarm@lists.linux.dev \
--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.