From: Oliver Upton <oupton@kernel.org>
To: Fuad Tabba <tabba@google.com>
Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
maz@kernel.org, oliver.upton@linux.dev, will@kernel.org,
joey.gouly@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com,
catalin.marinas@arm.com, vladimir.murzin@arm.com
Subject: Re: [PATCH v4 7/8] KVM: arm64: Check whether a VM IOCTL is allowed in pKVM
Date: Wed, 12 Nov 2025 02:07:30 -0800 [thread overview]
Message-ID: <aRRcYltFUrBlcbfX@kernel.org> (raw)
In-Reply-To: <20251112092051.1376245-8-tabba@google.com>
Hi Fuad,
On Wed, Nov 12, 2025 at 09:20:50AM +0000, Fuad Tabba wrote:
> +/*
> + * Check whether the KVM VM IOCTL is allowed in pKVM.
> + *
> + * Certain features are allowed only for non-protected VMs in pKVM, which is why
> + * this takes the VM (kvm) as a parameter.
> + */
> +static inline bool kvm_pkvm_ioctl_allowed(struct kvm *kvm, unsigned int ioctl)
> +{
> + switch (ioctl) {
> + case KVM_CREATE_IRQCHIP:
> + return kvm_pkvm_ext_allowed(kvm, KVM_CAP_IRQCHIP);
> + case KVM_ARM_SET_DEVICE_ADDR:
> + return kvm_pkvm_ext_allowed(kvm, KVM_CAP_ARM_SET_DEVICE_ADDR);
> + case KVM_ARM_MTE_COPY_TAGS:
> + return kvm_pkvm_ext_allowed(kvm, KVM_CAP_ARM_MTE);
> + case KVM_ARM_SET_COUNTER_OFFSET:
> + return kvm_pkvm_ext_allowed(kvm, KVM_CAP_COUNTER_OFFSET);
> + case KVM_HAS_DEVICE_ATTR:
> + case KVM_SET_DEVICE_ATTR:
> + case KVM_GET_DEVICE_ATTR:
> + return kvm_pkvm_ext_allowed(kvm, KVM_CAP_DEVICE_CTRL) ||
> + kvm_pkvm_ext_allowed(kvm, KVM_CAP_VM_ATTRIBUTES);
> + case KVM_ARM_GET_REG_WRITABLE_MASKS:
> + return kvm_pkvm_ext_allowed(kvm, KVM_CAP_ARM_SUPPORTED_REG_MASK_RANGES);
> + default:
> + return true;
> + }
> +}
> +
I was thinking of something a bit more tabular since CCA will impose its
own restrictions + pKVM could share the ioctl <=> KVM_CAP association.
Anyway, ioctl filtering should be an allowlist (default to false) just
like kvm_pkvm_ext_allowed(). The default assumption is that new UAPI is not
supported for pVMs unless explicitly stated otherwise.
Thanks,
Oliver
next prev parent reply other threads:[~2025-11-12 10:07 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-12 9:20 [PATCH v4 0/8] KVM: arm64: Fixes for guest CPU feature trapping and enabling Fuad Tabba
2025-11-12 9:20 ` [PATCH v4 1/8] KVM: arm64: Fix Trace Buffer trapping for protected VMs Fuad Tabba
2025-11-12 9:20 ` [PATCH v4 2/8] KVM: arm64: Fix Trace Buffer trap polarity " Fuad Tabba
2025-11-12 9:20 ` [PATCH v4 3/8] KVM: arm64: Fix MTE flag initialization " Fuad Tabba
2025-11-12 9:39 ` Ben Horgan
2025-11-12 9:20 ` [PATCH v4 4/8] KVM: arm64: Introduce helper to calculate fault IPA offset Fuad Tabba
2025-11-12 9:20 ` [PATCH v4 5/8] KVM: arm64: Include VM type when checking VM capabilities in pKVM Fuad Tabba
2025-11-12 9:20 ` [PATCH v4 6/8] KVM: arm64: Do not allow KVM_CAP_ARM_MTE for any guest " Fuad Tabba
2025-11-12 9:20 ` [PATCH v4 7/8] KVM: arm64: Check whether a VM IOCTL is allowed " Fuad Tabba
2025-11-12 10:07 ` Oliver Upton [this message]
2025-11-12 10:51 ` Fuad Tabba
2025-11-12 9:20 ` [PATCH v4 8/8] KVM: arm64: Prevent host from managing timer offsets for protected VMs 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=aRRcYltFUrBlcbfX@kernel.org \
--to=oupton@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=joey.gouly@arm.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=maz@kernel.org \
--cc=oliver.upton@linux.dev \
--cc=suzuki.poulose@arm.com \
--cc=tabba@google.com \
--cc=vladimir.murzin@arm.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.