From: Oliver Upton <oupton@kernel.org>
To: Fuad Tabba <fuad.tabba@linux.dev>
Cc: Marc Zyngier <maz@kernel.org>, Joey Gouly <joey.gouly@arm.com>,
Steffen Eiden <seiden@linux.ibm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Zenghui Yu <yuzenghui@huawei.com>, Will Deacon <will@kernel.org>,
Lorenzo Stoakes <ljs@kernel.org>,
Jack Thomson <jackabt@amazon.com>,
kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Fuad Tabba <tabba@google.com>
Subject: Re: [PATCH v2] KVM: arm64: Restore the VM's feature bitmap when kvm_setup_vcpu() fails
Date: Mon, 21 Sep 2026 00:09:17 -0700 [thread overview]
Message-ID: <arDYHSlFHm_XzGvN@kernel.org> (raw)
In-Reply-To: <20260921063718.1604533-1-fuad.tabba@linux.dev>
Hi Fuad,
On Mon, Sep 21, 2026 at 07:37:18AM +0100, Fuad Tabba wrote:
> __kvm_vcpu_set_target() copies the requested features into the VM-wide
> bitmap before kvm_setup_vcpu() runs and doesn't undo it when setup
> fails, so a rejected KVM_ARM_VCPU_INIT leaves the VM recording features
> that were never set up. With HAS_EL2 | HAS_EL2_E2H0 on a host without
> FEAT_NV1, kvm_vcpu_init_nested() returns -EINVAL before it allocates any
> nested stage-2 MMU, and vcpu_has_nv() is then true with
> nested_mmus_size == 0; its -ENOMEM paths do the same on a VM's first
> INIT.
>
> Nothing in the tree loads a vCPU whose init failed, so this is latent.
> The upcoming series that enables KVM_PRE_FAULT_MEMORY for arm64 exposes
> it: the generic kvm_vcpu_pre_fault_memory() calls vcpu_load() whether
> or not the vCPU has been initialised.
That's a bug, not a feature. We should require an initialized vcpu for
the ioctl.
> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> index eaf583b771931..b25725f91c925 100644
> --- a/arch/arm64/kvm/arm.c
> +++ b/arch/arm64/kvm/arm.c
> @@ -1685,6 +1685,7 @@ static int kvm_setup_vcpu(struct kvm_vcpu *vcpu)
> static int __kvm_vcpu_set_target(struct kvm_vcpu *vcpu,
> const struct kvm_vcpu_init *init)
> {
> + DECLARE_BITMAP(old_features, KVM_VCPU_MAX_FEATURES);
> unsigned long features = init->features[0];
> struct kvm *kvm = vcpu->kvm;
> int ret = -EINVAL;
> @@ -1695,11 +1696,15 @@ static int __kvm_vcpu_set_target(struct kvm_vcpu *vcpu,
> kvm_vcpu_init_changed(vcpu, init))
> goto out_unlock;
>
> + /* Setup reads the VM-wide bitmap, so undo the copy if setup fails. */
> + bitmap_copy(old_features, kvm->arch.vcpu_features, KVM_VCPU_MAX_FEATURES);
> bitmap_copy(kvm->arch.vcpu_features, &features, KVM_VCPU_MAX_FEATURES);
>
> ret = kvm_setup_vcpu(vcpu);
> - if (ret)
> + if (ret) {
> + bitmap_copy(kvm->arch.vcpu_features, old_features, KVM_VCPU_MAX_FEATURES);
> goto out_unlock;
> + }
The bitmap copy is a bit confusing because there's only two possible
situations:
- KVM_ARCH_FLAG_VCPU_FEATURES_CONFIGURED is unset and the bitmap was
previously zero
- KVM_ARCH_FLAG_VCPU_FEATURES_CONFIGURED is set and @init->features is
identical to vcpu_features (see kvm_vcpu_init_changed())
While there's nothing wrong with your diff, I'd prefer if the above
detail was represented directly.
ret = kvm_setup_vcpu(vcpu);
if (ret) {
/*
* Clear the bitmap if setup fails on the first vCPU to be
* initialized.
*/
if (!test_bit(KVM_ARCH_FLAG_VCPU_FEATURES_CONFIGURED, &kvm->arch.flags))
bitmap_zero(kvm->arch.vcpu_features, KVM_VCPU_MAX_FEATURES);
goto out_unlock;
}
Thanks,
Oliver
next prev parent reply other threads:[~2026-09-21 7:09 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-21 6:37 [PATCH v2] KVM: arm64: Restore the VM's feature bitmap when kvm_setup_vcpu() fails Fuad Tabba
2026-09-21 7:09 ` Oliver Upton [this message]
2026-09-21 7:24 ` Fuad Tabba
2026-09-21 11:42 ` Lorenzo Stoakes (ARM)
2026-09-21 13:34 ` Lorenzo Stoakes (ARM)
2026-09-21 18:39 ` Oliver Upton
2026-09-22 7:31 ` Lorenzo Stoakes (ARM)
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=arDYHSlFHm_XzGvN@kernel.org \
--to=oupton@kernel.org \
--cc=fuad.tabba@linux.dev \
--cc=jackabt@amazon.com \
--cc=joey.gouly@arm.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ljs@kernel.org \
--cc=maz@kernel.org \
--cc=seiden@linux.ibm.com \
--cc=suzuki.poulose@arm.com \
--cc=tabba@google.com \
--cc=will@kernel.org \
--cc=yuzenghui@huawei.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.