From: Gavin Shan <gshan@redhat.com>
To: Suzuki K Poulose <suzuki.poulose@arm.com>,
kvm@vger.kernel.org, kvmarm@lists.linux.dev
Cc: maz@kernel.org, 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, joey.gouly@arm.com,
tabba@google.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,
Jean-Philippe Brucker <jean-philippe@linaro.org>
Subject: Re: [PATCH v22 23/23] KVM: arm64: CCA: Control user register access for Realms
Date: Tue, 6 Oct 2026 16:16:37 +1000 [thread overview]
Message-ID: <6bd785aa-4693-407d-b70a-39b1d0eda63e@redhat.com> (raw)
In-Reply-To: <7b6ed626-eca4-41f2-ae56-0af59a931b29@arm.com>
On 10/6/26 4:01 PM, Suzuki K Poulose wrote:
> On 06/10/2026 06:47, Gavin Shan wrote:
>> On 10/5/26 7:07 PM, Suzuki K Poulose wrote:
>>> From: Jean-Philippe Brucker <jean-philippe@linaro.org>
>>>
>>> The RMM restricts the access to the register states that the host can
>>> read/modify for a given Realm.
>>>
>>> e.g., At VCPU creation, can modify GPRS (x0-x30) and PC.
>>> While servicing SMCCC calls via RSI_HOST_CALL or servicing PSCI
>>> requests.
>>> MMIO emulation in the unprotected space.
>>>
>>> Additionally we use the sysreg configuration to advertise/configure the
>>> following Realm parameters, which are required before the Realm Descriptor
>>> is created:
>>> - SVE Vector Length
>>> - Number of HW Breakpoints/Watchpoints
>>> - PMU Counters.
>>>
>>> Thus KVM also additionally allows access to ID_AA64DFR0_EL1 and SVE_VLS for
>>> the configuration of Realm creation parameters. We don't support PMUs for
>>> the Realm VMs yet, so PMCR is not exposed.
>>>
>>> The RMM makes similar restrictions for reading of the guest's registers
>>> (this is *confidential* compute after all), however we don't impose the
>>> restriction here. This allows the VMM to read (stale) values from the
>>> registers which might be useful to read back the initial values even if
>>> the RMM doesn't provide the latest version. For migration of a realm VM,
>>> a new interface will be needed so that the VMM can receive an
>>> (encrypted) blob of the VM's state.
>>>
>>> Reflect the above in KVM_GET_REG_LIST, KVM_SET_ONE_REG calls.
>
>>> static int core_reg_size_from_offset(const struct kvm_vcpu *vcpu, u64 off)
>>> {
>>> int size;
>>> @@ -553,6 +572,9 @@ static int copy_core_reg_indices(const struct kvm_vcpu *vcpu,
>>> u64 reg = KVM_REG_ARM64 | KVM_REG_ARM_CORE | i;
>>> int size = core_reg_size_from_offset(vcpu, i);
>>> + if (vcpu_is_rec(vcpu) && !kvm_realm_validate_core_reg(i))
>>> + continue;
>>> +
>>> if (size < 0)
>>> continue;
>>> @@ -598,6 +620,9 @@ static unsigned long num_sve_regs(const struct kvm_vcpu *vcpu)
>>> if (!vcpu_has_sve(vcpu))
>>> return 0;
>>> + if (kvm_vm_is_realm(vcpu->kvm))
>>> + return 1; /* KVM_REG_ARM64_SVE_VLS */
>>> +
>>> if (!kvm_arm_vcpu_sve_finalized(vcpu))
>>> return 1; /* KVM_REG_ARM64_SVE_VLS */
>>>
>>
>> Aren't above two checks conflicting to each other?
>
> Do they? We allow SVE_VLS only for the Realms and we allow that
> before the vCPUs are finalized. For normal VMs, depending on
> whether the vcpus are finalized, we either send 1 or the full list.
>
num_sve_regs() can be called for 3 cases: (a) non-finalized RECs; (b) finalized
RECs; (c) Other finalized vCPUs, correct? "if (kvm_vm_is_realm(vcpu->kvm))", which
would be "if (vcpu_is_rec(vcpu))", covers (a) and (b). We needn't the excessive
check "if (!kvm_arm_vcpu_sve_finalized(vcpu))". So the check would be something
as below after this series is applied:
/*
* KVM_REG_ARM64_SVE_VLS is visible on realm vCPU no matter if it
* has been finalized.
*/
if (vcpu_is_rec(vcpu))
return 1;
This check "if (vcpu_is_rec(vcpu))" belongs to PATCH[22]. Hope I make myself
clear this time :)
>>
>>> @@ -625,6 +650,10 @@ static int copy_sve_reg_indices(const struct kvm_vcpu *vcpu,
>>> return -EFAULT;
>>> ++num_regs;
>>> + /* For Realms only support SVE_VLS */
>>> + if (kvm_vm_is_realm(vcpu->kvm))
>>> + return num_regs;
>>> +
>>> if (!kvm_arm_vcpu_sve_finalized(vcpu))
>>> return num_regs;
>>
>> Same question here.
>
> As above.
>
> Suzuki
Thanks,
Gavin
next prev parent reply other threads:[~2026-10-06 6:16 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-05 9:07 [PATCH v22 00/23] KVM: arm64: CCA: Add basic plumbing for Realms Suzuki K Poulose
2026-10-05 9:07 ` [PATCH v22 01/23] KVM: arm64: protected VM: Handle user writes to CNTVCT_EL0/CNTPCT_EL0 Suzuki K Poulose
2026-10-06 0:02 ` Gavin Shan
2026-10-05 9:07 ` [PATCH v22 02/23] KVM: arm64: Disable Steal time accounting for protected guests Suzuki K Poulose
2026-10-06 0:03 ` Gavin Shan
2026-10-05 9:07 ` [PATCH v22 03/23] KVM: arm64: Include kvm_emulate.h in kvm/arm_psci.h Suzuki K Poulose
2026-10-05 9:07 ` [PATCH v22 04/23] KVM: arm64: Avoid including linux/kvm_host.h in kvm_pgtable.h Suzuki K Poulose
2026-10-05 9:07 ` [PATCH v22 05/23] KVM: arm64: Track the type of VM in kvm_arch Suzuki K Poulose
2026-10-06 3:55 ` Gavin Shan
2026-10-06 8:33 ` Marc Zyngier
2026-10-06 8:49 ` Suzuki K Poulose
2026-10-05 9:07 ` [PATCH v22 06/23] KVM: arm64: Don't call vcpu_set_pauth_traps for pKVM host Suzuki K Poulose
2026-10-06 0:29 ` Gavin Shan
2026-10-05 9:07 ` [PATCH v22 07/23] KVM: arm64: Refactor the vcpu_load to allow for VM specific callbacks Suzuki K Poulose
2026-10-05 9:07 ` [PATCH v22 08/23] KVM: arm64: Add vcpu load/put call backs for flavors Suzuki K Poulose
2026-10-06 2:15 ` Gavin Shan
2026-10-05 9:07 ` [PATCH v22 09/23] KVM: arm64: Prevent unsupported vcpu features for VM types Suzuki K Poulose
2026-10-06 2:24 ` Gavin Shan
2026-10-06 2:25 ` Gavin Shan
2026-10-06 5:16 ` Suzuki K Poulose
2026-10-06 8:50 ` Marc Zyngier
2026-10-05 9:07 ` [PATCH v22 10/23] KVM: arm64: Consolidate stage2 unmap range into kvm_stage2_unmap_range Suzuki K Poulose
2026-10-06 2:37 ` Gavin Shan
2026-10-05 9:07 ` [PATCH v22 11/23] KVM: arm64: Add VM specific callback for S2 MMU operations Suzuki K Poulose
2026-10-06 3:00 ` Gavin Shan
2026-10-06 5:22 ` Suzuki K Poulose
2026-10-06 9:24 ` Marc Zyngier
2026-10-06 10:36 ` Suzuki K Poulose
2026-10-06 15:14 ` Suzuki K Poulose
2026-10-05 9:07 ` [PATCH v22 12/23] KVM: arm64: Use a local kvm pointer in kvm_handle_guest_abort() Suzuki K Poulose
2026-10-06 3:02 ` Gavin Shan
2026-10-05 9:07 ` [PATCH v22 13/23] KVM: arm64: Abstract out memory abort handling Suzuki K Poulose
2026-10-06 3:07 ` Gavin Shan
2026-10-06 5:25 ` Suzuki K Poulose
2026-10-05 9:07 ` [PATCH v22 14/23] KVM: arm64: Mandate VGIC v3 for pKVM VMs and Realms Suzuki K Poulose
2026-10-06 3:10 ` Gavin Shan
2026-10-05 9:07 ` [PATCH v22 15/23] KVM: arm64: CCA: Add a new mode for supporting Realm guests Suzuki K Poulose
2026-10-06 3:11 ` Gavin Shan
2026-10-05 9:07 ` [PATCH v22 16/23] KVM: arm64: CCA: Add VCPU load/put for Realms Suzuki K Poulose
2026-10-06 3:16 ` Gavin Shan
2026-10-06 5:09 ` Suzuki K Poulose
2026-10-05 9:07 ` [PATCH v22 17/23] KVM: arm64: CCA: Add bare minimal S2 operations for Realm Suzuki K Poulose
2026-10-06 3:18 ` Gavin Shan
2026-10-05 9:07 ` [PATCH v22 18/23] KVM: arm64: CCA: Introduce Realms Suzuki K Poulose
2026-10-06 3:42 ` Gavin Shan
2026-10-06 5:10 ` Suzuki K Poulose
2026-10-05 9:07 ` [PATCH v22 19/23] KVM: arm64: CCA: Don't expose unsupported capabilities for realm guests Suzuki K Poulose
2026-10-06 4:58 ` Gavin Shan
2026-10-05 9:07 ` [PATCH v22 20/23] KVM: arm64: CCA: WARN on injected undef exceptions Suzuki K Poulose
2026-10-06 3:49 ` Gavin Shan
2026-10-05 9:07 ` [PATCH v22 21/23] KVM: arm64: CCA: Support timers in realm RECs Suzuki K Poulose
2026-10-06 5:44 ` Gavin Shan
2026-10-05 9:07 ` [PATCH v22 22/23] KVM: arm64: CCA: Expose SVE VL register before VCPU finalization Suzuki K Poulose
2026-10-06 5:35 ` Gavin Shan
2026-10-06 5:57 ` Suzuki K Poulose
2026-10-05 9:07 ` [PATCH v22 23/23] KVM: arm64: CCA: Control user register access for Realms Suzuki K Poulose
2026-10-05 9:30 ` sashiko-bot
2026-10-05 13:08 ` Suzuki K Poulose
2026-10-06 5:47 ` Gavin Shan
2026-10-06 6:01 ` Suzuki K Poulose
2026-10-06 6:16 ` Gavin Shan [this message]
2026-10-06 12:36 ` Suzuki K Poulose
2026-10-06 22:00 ` Gavin Shan
2026-10-06 6:23 ` Gavin Shan
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=6bd785aa-4693-407d-b70a-39b1d0eda63e@redhat.com \
--to=gshan@redhat.com \
--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=jean-philippe@linaro.org \
--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=maz@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.