From: Marc Zyngier <maz@kernel.org>
To: Fuad Tabba <tabba@google.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>,
kvm@vger.kernel.org, kvmarm@lists.linux.dev, will@kernel.org,
catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, steven.price@arm.com,
aneesh.kumar@kernel.org, oupton@kernel.org, gshan@redhat.com,
joey.gouly@arm.com, yuzenghui@huawei.com,
linux-coco@lists.linux.dev, gankulkarni@os.amperecomputing.com,
sdonthineni@nvidia.com, alpergun@google.com,
fj0570is@fujitsu.com, WeiLin.Chang@arm.com,
lpieralisi@kernel.org, enju.kohei@fujitsu.com,
sudeep.holla@arm.com, jonathan.cameron@oss.qualcomm.com
Subject: Re: [PATCH v23 14/14] KVM: arm64: Prevent unsupported vcpu features for VM types
Date: Fri, 09 Oct 2026 09:55:52 +0100 [thread overview]
Message-ID: <86a4on2qxz.wl-maz@kernel.org> (raw)
In-Reply-To: <CA+EHjTx-niYPnnRDvAAiY3MXLpSYau_PhiBTCiE9mOYUChASPQ@mail.gmail.com>
On Wed, 07 Oct 2026 15:19:53 +0100,
Fuad Tabba <tabba@google.com> wrote:
>
> Hi Suzuki,
>
> On Wed, 07 Oct 2026 08:35:37 +0100, Suzuki K Poulose
> <suzuki.poulose@arm.com> wrote:
> [...]
> > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> > index 4d0e6bd2009ac..97089c81d6428 100644
> > --- a/arch/arm64/include/asm/kvm_host.h
> > +++ b/arch/arm64/include/asm/kvm_host.h
> > @@ -42,6 +42,13 @@
> > #define KVM_VCPU_MAX_FEATURES 10
> > #define KVM_VCPU_VALID_FEATURES (BIT(KVM_VCPU_MAX_FEATURES) - 1)
> >
> > +/* As dictated by kvm_pkvm_ext_allowed() */
> > +#define KVM_PROTECTED_VCPU_VALID_FEATURES \
> > + (BIT(KVM_ARM_VCPU_POWER_OFF) | \
> > + BIT(KVM_ARM_VCPU_PSCI_0_2) | \
> > + BIT(KVM_ARM_VCPU_PTRAUTH_ADDRESS) | \
> > + BIT(KVM_ARM_VCPU_PTRAUTH_GENERIC))
>
> kvmarm/next already restricts protected VM features through
> kvm_pkvm_vcpu_allowed_features(), shared with EL2 (0b7d843ef3bf).
> Could you rebase on that and drop the protected half of this patch,
> rather than add a second list?
A rebase would be a terrible idea. This thing *must* go on its own
branch, and not depend on anything else.
I can however fix things at merge time. is something like this what
you had in mind? It compiles, and is therefore perfect...
M.
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 300ffc2e31c7d..1c6632216e327 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -45,13 +45,6 @@
#define KVM_VCPU_MAX_FEATURES 10
#define KVM_VCPU_VALID_FEATURES (BIT(KVM_VCPU_MAX_FEATURES) - 1)
-/* As dictated by kvm_pkvm_ext_allowed() */
-#define KVM_PROTECTED_VCPU_VALID_FEATURES \
- (BIT(KVM_ARM_VCPU_POWER_OFF) | \
- BIT(KVM_ARM_VCPU_PSCI_0_2) | \
- BIT(KVM_ARM_VCPU_PTRAUTH_ADDRESS) | \
- BIT(KVM_ARM_VCPU_PTRAUTH_GENERIC))
-
#define KVM_REQ_SLEEP \
KVM_ARCH_REQ_FLAGS(0, KVM_REQUEST_WAIT | KVM_REQUEST_NO_WAKEUP)
#define KVM_REQ_IRQ_PENDING KVM_ARCH_REQ(1)
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index 3ae8f51ce948a..a0e7f1d2d1575 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -1706,12 +1706,10 @@ int kvm_vm_ioctl_irq_line(struct kvm *kvm, struct kvm_irq_level *irq_level,
static unsigned long system_supported_vcpu_features(struct kvm_vcpu *vcpu)
{
- unsigned long features;
+ unsigned long features = KVM_VCPU_VALID_FEATURES;
if (vcpu->kvm->arch.vm_flavor == VM_PROTECTED_PKVM)
- features = KVM_PROTECTED_VCPU_VALID_FEATURES;
- else
- features = KVM_VCPU_VALID_FEATURES;
+ kvm_pkvm_vcpu_allowed_features(vcpu->kvm, &features);
if (!cpus_have_final_cap(ARM64_HAS_32BIT_EL1))
clear_bit(KVM_ARM_VCPU_EL1_32BIT, &features);
@@ -1753,19 +1751,6 @@ static int kvm_vcpu_init_check_features(struct kvm_vcpu *vcpu,
if (features & ~system_supported_vcpu_features(vcpu))
return -EINVAL;
- /* Reject features EL2 would drop when it creates the hyp VM. */
- if (vcpu_is_protected(vcpu)) {
- DECLARE_BITMAP(allowed, KVM_VCPU_MAX_FEATURES);
-
- kvm_pkvm_vcpu_allowed_features(vcpu->kvm, allowed);
- if (!bitmap_subset(&features, allowed, KVM_VCPU_MAX_FEATURES))
- return -EINVAL;
-
- /* EL2 implements PSCI 1.1; the host must not dispatch as 0.1. */
- if (!test_bit(KVM_ARM_VCPU_PSCI_0_2, &features))
- return -EINVAL;
- }
-
/*
* For now make sure that both address/generic pointer authentication
* features are requested by the userspace together.
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2026-10-09 8:56 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-07 7:35 [PATCH v23 00/14] KVM: arm64: CCA: Add basic plumbing for Realms Suzuki K Poulose
2026-10-07 7:35 ` [PATCH v23 01/14] KVM: arm64: protected VM: Handle user writes to CNTVCT_EL0/CNTPCT_EL0 Suzuki K Poulose
2026-10-07 10:43 ` Fuad Tabba
2026-10-07 7:35 ` [PATCH v23 02/14] KVM: arm64: Disable Steal time accounting for protected guests Suzuki K Poulose
2026-10-07 10:51 ` Fuad Tabba
2026-10-07 13:10 ` Suzuki K Poulose
2026-10-07 7:35 ` [PATCH v23 03/14] KVM: arm64: Include kvm_emulate.h in kvm/arm_psci.h Suzuki K Poulose
2026-10-07 8:03 ` sashiko-bot
2026-10-07 11:00 ` Fuad Tabba
2026-10-07 7:35 ` [PATCH v23 04/14] KVM: arm64: Avoid including linux/kvm_host.h in kvm_pgtable.h Suzuki K Poulose
2026-10-07 7:35 ` [PATCH v23 05/14] KVM: arm64: Track the type of VM in kvm_arch Suzuki K Poulose
2026-10-07 7:35 ` [PATCH v23 06/14] KVM: arm64: Don't call vcpu_set_pauth_traps for pKVM host Suzuki K Poulose
2026-10-07 11:07 ` Fuad Tabba
2026-10-07 7:35 ` [PATCH v23 07/14] KVM: arm64: Refactor the vcpu_load to allow for VM specific callbacks Suzuki K Poulose
2026-10-07 11:12 ` Fuad Tabba
2026-10-07 7:35 ` [PATCH v23 08/14] KVM: arm64: Add vcpu load/put call backs for flavors Suzuki K Poulose
2026-10-07 11:18 ` Fuad Tabba
2026-10-07 7:35 ` [PATCH v23 09/14] KVM: arm64: Consolidate stage2 unmap range into kvm_stage2_unmap_range Suzuki K Poulose
2026-10-07 7:49 ` sashiko-bot
2026-10-07 8:52 ` Suzuki K Poulose
2026-10-07 11:23 ` Fuad Tabba
2026-10-07 7:35 ` [PATCH v23 10/14] KVM: arm64: Add VM specific callback for S2 MMU operations Suzuki K Poulose
2026-10-07 11:38 ` Fuad Tabba
2026-10-07 7:35 ` [PATCH v23 11/14] KVM: arm64: Use a local kvm pointer in kvm_handle_guest_abort() Suzuki K Poulose
2026-10-07 7:35 ` [PATCH v23 12/14] KVM: arm64: Abstract out memory abort handling Suzuki K Poulose
2026-10-07 13:45 ` Fuad Tabba
2026-10-07 7:35 ` [PATCH v23 13/14] KVM: arm64: Mandate VGIC v3 for pKVM VMs and Realms Suzuki K Poulose
2026-10-07 13:45 ` Fuad Tabba
2026-10-08 8:51 ` Suzuki K Poulose
2026-10-08 11:17 ` Fuad Tabba
2026-10-07 7:35 ` [PATCH v23 14/14] KVM: arm64: Prevent unsupported vcpu features for VM types Suzuki K Poulose
2026-10-07 14:19 ` Fuad Tabba
2026-10-09 8:55 ` Marc Zyngier [this message]
2026-10-09 10:10 ` Fuad Tabba
2026-10-09 12:16 ` Marc Zyngier
2026-10-09 13:28 ` [PATCH v23 00/14] KVM: arm64: CCA: Add basic plumbing for Realms Marc Zyngier
2026-10-09 14:20 ` Fuad Tabba
2026-10-10 9:19 ` Marc Zyngier
2026-10-10 9:44 ` 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=86a4on2qxz.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=WeiLin.Chang@arm.com \
--cc=alpergun@google.com \
--cc=aneesh.kumar@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=enju.kohei@fujitsu.com \
--cc=fj0570is@fujitsu.com \
--cc=gankulkarni@os.amperecomputing.com \
--cc=gshan@redhat.com \
--cc=joey.gouly@arm.com \
--cc=jonathan.cameron@oss.qualcomm.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-coco@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=oupton@kernel.org \
--cc=sdonthineni@nvidia.com \
--cc=steven.price@arm.com \
--cc=sudeep.holla@arm.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.