From: sashiko-bot@kernel.org
To: "Fuad Tabba" <fuad.tabba@linux.dev>
Cc: kvmarm@lists.linux.dev, "Oliver Upton" <oupton@kernel.org>,
"Marc Zyngier" <maz@kernel.org>
Subject: Re: [PATCH v5 2/8] KVM: arm64: Make vcpu_{read,write}_sys_reg available to HYP code
Date: Tue, 14 Jul 2026 10:43:44 +0000 [thread overview]
Message-ID: <20260714104344.615DA1F00A3E@smtp.kernel.org> (raw)
In-Reply-To: <20260714101601.4142645-3-fuad.tabba@linux.dev>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The WARN_ON_ONCE checks in __vcpu_read_sysreg_vhe and __vcpu_write_sysreg_vhe contain impossible conditions.
--
--- Patch [2]: [PATCH v5 2/8] KVM: arm64: Make vcpu_{read,write}_sys_reg available to HYP code ---
commit fbd97ecacd267a88fbcb547ae114d7b3bbe56fb4
Author: Fuad Tabba <fuad.tabba@linux.dev>
KVM: arm64: Make vcpu_{read,write}_sys_reg available to HYP code
This patch renames the host-only implementations to
__vcpu_{read,write}_sysreg_vhe() and turns vcpu_{read,write}_sys_reg() into
context-dispatching wrappers. This allows helpers built on them to be shared
with hyp code.
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index 08ba882799d48..c6a416974a61f 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -291,7 +291,7 @@ static void write_sr_to_cpu(enum vcpu_sysreg reg, u64 val)
> }
> }
>
> -u64 vcpu_read_sys_reg(const struct kvm_vcpu *vcpu, enum vcpu_sysreg reg)
> +u64 __vcpu_read_sysreg_vhe(const struct kvm_vcpu *vcpu, enum vcpu_sysreg reg)
> {
> struct sr_loc loc = {};
>
[Severity: Low]
Since the new vcpu_read_sys_reg() wrapper in kvm_emulate.h explicitly checks
has_vhe(), does this make the WARN_ON_ONCE(!has_vhe() ...) check inside this
function dead code?
Specifically, just below this declaration:
locate_register(vcpu, reg, &loc);
WARN_ON_ONCE(!has_vhe() && loc.loc != SR_LOC_MEMORY);
Is it worth removing the check now that the caller guarantees has_vhe()
is true?
[ ... ]
> @@ -338,7 +338,7 @@ u64 vcpu_read_sys_reg(const struct kvm_vcpu *vcpu, enum vcpu_sysreg reg)
> return __vcpu_sys_reg(vcpu, reg);
> }
>
> -void vcpu_write_sys_reg(struct kvm_vcpu *vcpu, u64 val, enum vcpu_sysreg reg)
> +void __vcpu_write_sysreg_vhe(struct kvm_vcpu *vcpu, u64 val, enum vcpu_sysreg reg)
> {
> struct sr_loc loc = {};
>
[Severity: Low]
Similarly, does the WARN_ON_ONCE(!has_vhe() ...) check inside this function
become unreachable now that the wrapper only calls this when has_vhe()
is true?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260714101601.4142645-1-fuad.tabba@linux.dev?part=2
next prev parent reply other threads:[~2026-07-14 10:43 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-14 10:15 [PATCH v5 0/8] KVM: arm64: pKVM vCPU state management at EL2 (series A) Fuad Tabba
2026-07-14 10:15 ` [PATCH v5 1/8] KVM: arm64: Extract MPIDR computation into a shared header Fuad Tabba
2026-07-14 10:15 ` [PATCH v5 2/8] KVM: arm64: Make vcpu_{read,write}_sys_reg available to HYP code Fuad Tabba
2026-07-14 10:43 ` sashiko-bot [this message]
2026-07-14 11:19 ` Fuad Tabba
2026-07-14 10:52 ` Vincent Donnefort
2026-07-14 15:19 ` Marc Zyngier
2026-07-14 15:32 ` Fuad Tabba
2026-07-14 10:15 ` [PATCH v5 3/8] KVM: arm64: Factor out reusable vCPU reset helpers Fuad Tabba
2026-07-14 10:15 ` [PATCH v5 4/8] KVM: arm64: Move PSCI helper functions to a shared header Fuad Tabba
2026-07-14 11:10 ` sashiko-bot
2026-07-14 11:15 ` Fuad Tabba
2026-07-14 10:15 ` [PATCH v5 5/8] KVM: arm64: Add host and hypervisor vCPU lookup primitives Fuad Tabba
2026-07-14 10:15 ` [PATCH v5 6/8] KVM: arm64: Minimise EL2's exposure of host VGIC state during world switch Fuad Tabba
2026-07-14 11:53 ` sashiko-bot
2026-07-14 12:17 ` Fuad Tabba
2026-07-14 10:16 ` [PATCH v5 7/8] KVM: arm64: Add primitives to flush/sync the VGIC state at EL2 Fuad Tabba
2026-07-14 12:20 ` sashiko-bot
2026-07-14 13:04 ` Fuad Tabba
2026-07-14 10:16 ` [PATCH v5 8/8] KVM: arm64: Implement lazy vCPU state sync for non-protected guests Fuad Tabba
2026-07-14 12:33 ` sashiko-bot
2026-07-14 13:08 ` Fuad Tabba
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=20260714104344.615DA1F00A3E@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=fuad.tabba@linux.dev \
--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.