From: sashiko-bot@kernel.org
To: "Suzuki K Poulose" <suzuki.poulose@arm.com>
Cc: kvm@vger.kernel.org, kvmarm@lists.linux.dev,
"Marc Zyngier" <maz@kernel.org>,
"Oliver Upton" <oupton@kernel.org>
Subject: Re: [PATCH v17 16/20] KVM: arm64: CCA: Provide register list for unfinalized RECs
Date: Tue, 08 Sep 2026 16:57:08 +0000 [thread overview]
Message-ID: <20260908165709.2799B1F00A3D@smtp.kernel.org> (raw)
In-Reply-To: <20260908162223.1683432-17-suzuki.poulose@arm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Mismatch between KVM_GET_REG_LIST implementation for RECs and its commit message / comment.
--
commit ce52f6b2727531d94e14139ee2966392538b6218
Author: Jean-Philippe Brucker <jpb@kernel.org>
KVM: arm64: CCA: Provide register list for unfinalized RECs
This commit modifies the KVM_GET_REG_LIST ioctl handler to allow fetching
the register list for Realm Execution Contexts (RECs) before the VCPUs are
fully finalized, provided SVE is finalized. It adjusts the size probing and
array copying logic to prevent -EPERM errors during late REC finalization.
> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> --- a/arch/arm64/kvm/arm.c
> +++ b/arch/arm64/kvm/arm.c
[ ... ]
> @@ -1980,6 +1980,18 @@ static int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu,
> return __kvm_arm_vcpu_set_events(vcpu, events);
> }
>
> +/*
> + * Realm VCPUs can be finalized after the Realm descriptor is created.
> + * Allow the register list for RECs before the VCPUs are finalized, but
> + * after the SVE is finalized.
> + */
> +static bool kvm_arm_vcpu_reg_list_allowed(struct kvm_vcpu *vcpu)
> +{
> + if (kvm_arm_vcpu_is_finalized(vcpu))
> + return true;
> + return vcpu_is_rec(vcpu);
> +}
[Severity: Medium]
Does this logic in kvm_arm_vcpu_reg_list_allowed() unconditionally allow
RECs, bypassing the SVE finalization check? The comment explicitly states
"but after the SVE is finalized," yet if the VCPU is a REC, this path
returns true regardless of the SVE finalization status.
> diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
> --- a/arch/arm64/kvm/guest.c
> +++ b/arch/arm64/kvm/guest.c
[ ... ]
> @@ -616,9 +616,6 @@ static int copy_sve_reg_indices(const struct kvm_vcpu *vcpu,
> if (!vcpu_has_sve(vcpu))
> return 0;
>
> - /* Policed by KVM_GET_REG_LIST: */
> - WARN_ON(!kvm_arm_vcpu_sve_finalized(vcpu));
> -
> /*
> * Enumerate this first, so that userspace can save/restore in
> * the order reported by KVM_GET_REG_LIST:
> @@ -628,6 +625,9 @@ static int copy_sve_reg_indices(const struct kvm_vcpu *vcpu,
> return -EFAULT;
> ++num_regs;
>
> + if (!kvm_arm_vcpu_sve_finalized(vcpu))
> + return num_regs;
> +
[Severity: Medium]
Does this return a positive success code (num_regs) rather than an error?
The commit message states that "a KVM_GET_REG_LIST call that only probes
for the array size will now succeed even if SVE is not finalized, but that
seems harmless since the following KVM_GET_REG_LIST with the full array
will fail."
Returning a positive number of registers here in copy_sve_reg_indices()
causes the full array fetch to succeed silently instead of failing as the
commit message claims.
> for (i = 0; i < slices; i++) {
> for (n = 0; n < SVE_NUM_ZREGS; n++) {
> reg = KVM_REG_ARM64_SVE_ZREG(n, i);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260908162223.1683432-1-suzuki.poulose@arm.com?part=16
next prev parent reply other threads:[~2026-09-08 16:57 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-08 16:22 [PATCH v17 00/20] KVM: arm64: CCA: Add basic plumbing for Realms Suzuki K Poulose
2026-09-08 16:22 ` [PATCH v17 01/20] KVM: arm64: Include kvm_emulate.h in kvm/arm_psci.h Suzuki K Poulose
2026-09-09 11:20 ` Fuad Tabba
2026-09-08 16:22 ` [PATCH v17 02/20] KVM: arm64: Avoid including linux/kvm_host.h in kvm_pgtable.h Suzuki K Poulose
2026-09-09 11:22 ` Fuad Tabba
2026-09-09 11:24 ` Suzuki K Poulose
2026-09-10 3:40 ` Gavin Shan
2026-09-08 16:22 ` [PATCH v17 03/20] KVM: arm64: Track the type of VM in kvm_arch Suzuki K Poulose
2026-09-09 11:28 ` Fuad Tabba
2026-09-09 11:30 ` Suzuki K Poulose
2026-09-10 3:39 ` Gavin Shan
2026-09-10 6:35 ` Suzuki K Poulose
2026-09-08 16:22 ` [PATCH v17 04/20] KVM: arm64: Refactor the vcpu_load to allow for VM specific callbacks Suzuki K Poulose
2026-09-10 4:00 ` Gavin Shan
2026-09-10 10:21 ` Suzuki K Poulose
2026-09-08 16:22 ` [PATCH v17 05/20] KVM: arm64: Add vcpu load/put call backs for flavors Suzuki K Poulose
2026-09-10 5:33 ` Gavin Shan
2026-09-10 8:40 ` Suzuki K Poulose
2026-09-08 16:22 ` [PATCH v17 06/20] KVM: arm64: CCA: Add a new mode for supporting Realm guests Suzuki K Poulose
2026-09-09 3:26 ` Kohei Enju
2026-09-09 10:48 ` Marc Zyngier
2026-09-10 4:49 ` Kohei Enju
2026-09-10 5:53 ` Gavin Shan
2026-09-10 8:43 ` Suzuki K Poulose
2026-09-10 9:40 ` Gavin Shan
2026-09-08 16:22 ` [PATCH v17 07/20] KVM: arm64: CCA: Introduce Realms Suzuki K Poulose
2026-09-08 16:22 ` [PATCH v17 08/20] KVM: arm64: coco: Add a helper to check if a VM is confidential compute guest Suzuki K Poulose
2026-09-08 16:22 ` [PATCH v17 09/20] KVM: arm64: coco: arch_timer: Prevent timer offset configuration Suzuki K Poulose
2026-09-08 16:46 ` sashiko-bot
2026-09-10 12:19 ` Suzuki K Poulose
2026-09-08 16:22 ` [PATCH v17 10/20] KVM: arm64: coco: Disable Steal time accounting for coco guests Suzuki K Poulose
2026-09-09 11:45 ` Fuad Tabba
2026-09-09 11:52 ` Suzuki K Poulose
2026-09-09 12:23 ` Fuad Tabba
2026-09-10 10:27 ` Suzuki K Poulose
2026-09-10 12:42 ` Fuad Tabba
2026-09-10 12:44 ` Suzuki K Poulose
2026-09-08 16:22 ` [PATCH v17 11/20] KVM: arm64: coco: Don't handle MMIO with no ISV Suzuki K Poulose
2026-09-08 16:22 ` [PATCH v17 12/20] KVM: arm64: CCA: Support timers in realm RECs Suzuki K Poulose
2026-09-08 16:56 ` sashiko-bot
2026-09-08 18:58 ` Suzuki K Poulose
2026-09-08 16:22 ` [PATCH v17 13/20] KVM: arm64: CCA: Add VCPU load/put for Realms Suzuki K Poulose
2026-09-08 16:22 ` [PATCH v17 14/20] KVM: arm64: CCA: Don't expose unsupported capabilities for realm guests Suzuki K Poulose
2026-09-08 16:52 ` sashiko-bot
2026-09-10 12:18 ` Suzuki K Poulose
2026-09-08 16:22 ` [PATCH v17 15/20] KVM: arm64: CCA: WARN on injected undef exceptions Suzuki K Poulose
2026-09-08 16:22 ` [PATCH v17 16/20] KVM: arm64: CCA: Provide register list for unfinalized RECs Suzuki K Poulose
2026-09-08 16:57 ` sashiko-bot [this message]
2026-09-10 12:15 ` Suzuki K Poulose
2026-09-08 16:22 ` [PATCH v17 17/20] KVM: arm64: CCA: Provide an accurate register list Suzuki K Poulose
2026-09-08 17:00 ` sashiko-bot
2026-09-10 12:17 ` Suzuki K Poulose
2026-09-08 16:22 ` [PATCH v17 18/20] KVM: arm64: Reuse kvm_stage2_unmap_range in kvm_unmap_gfn_range Suzuki K Poulose
2026-09-09 11:50 ` Fuad Tabba
2026-09-08 16:22 ` [PATCH v17 19/20] KVM: arm64: Add VM specific callback for S2 MMU operations Suzuki K Poulose
2026-09-08 16:59 ` sashiko-bot
2026-09-08 18:59 ` Suzuki K Poulose
2026-09-08 16:22 ` [PATCH v17 20/20] KVM: arm64: Abstract out memory abort handling Suzuki K Poulose
2026-09-09 13:18 ` [PATCH v17 00/20] KVM: arm64: CCA: Add basic plumbing for Realms Fuad Tabba
2026-09-09 13:52 ` Suzuki K Poulose
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=20260908165709.2799B1F00A3D@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=maz@kernel.org \
--cc=oupton@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=suzuki.poulose@arm.com \
/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.