From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A63C82FC022; Wed, 1 Oct 2025 13:50:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759326644; cv=none; b=LwXjy6dFkiSjESP9b5OfMt/sC0TSW3LMgPsd1QpoYy0G4w/cmKQ9aVuR9PVhINU+uQJ60kmK1nWxkhoDtsKczR1KKeeW5SYuglOm3httuuuVjFWh3YEwJB3D9RbgiF1uZ6j67XlfhDPQcYeNHCGlR8YcehX9KHM8g/BgaAftsiM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1759326644; c=relaxed/simple; bh=ZdhaWAfKmxbKABNyDvOv6tEXnr56Ewe14zIvrLNS+q0=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=QSZ7eSvr9W/eIlDLEAzRjv7fQAgwXEwrMI3qCwqn6NetOjUqdATeVpkMJK/85PoxnUM1XH/Gx6YHldWOB4p1NSnvOkNcN3Bsy+wuSBolM6QHE6DuSSWF15TG9EPsx8tXD4oQcIlDX1wb1lfG80QRzPF3GFe9aSvY2MQ3Q3ap+tk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=StWNG2X4; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="StWNG2X4" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 112B2C4CEF1; Wed, 1 Oct 2025 13:50:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1759326644; bh=ZdhaWAfKmxbKABNyDvOv6tEXnr56Ewe14zIvrLNS+q0=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=StWNG2X43Oln/YTs39wgGNy2vivNkf3C+7Q9ZKEkvKLqU6ivY6UUbwJO2s5fpqi7V zDyY4ias5QmrcL4bn0bOcijCxxS86WzRffaQ4k15osdCSYrKYXn+X5yqpIXiUo+6Gw or8kEjUjJ35ksXmKxgKnM71neNwPM2fy0yx8t50Lv1maBWMbjdqV0A6wcZLmsmQlCP HRy9aMRLl40+wdbLBWI6IAh18rjqwovKTacejOeqZv2qbz+QXrqBGN6n4yw2sR4NLT zAV0f19ZTdgAuxYn/PblZd93t56iNeYq5AkXM5ORfZj7e7aOD9OLgVimcTxq7IoHZD WwCFwRSr/Bspg== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1v3xE9-0000000Aor0-4Bb3; Wed, 01 Oct 2025 13:50:42 +0000 Date: Wed, 01 Oct 2025 14:50:41 +0100 Message-ID: <86frc2zq6m.wl-maz@kernel.org> From: Marc Zyngier To: Steven Price Cc: kvm@vger.kernel.org, kvmarm@lists.linux.dev, Catalin Marinas , Will Deacon , James Morse , Oliver Upton , Suzuki K Poulose , Zenghui Yu , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Joey Gouly , Alexandru Elisei , Christoffer Dall , Fuad Tabba , linux-coco@lists.linux.dev, Ganapatrao Kulkarni , Gavin Shan , Shanker Donthineni , Alper Gun , "Aneesh Kumar K . V" , Emi Kisanuki , Vishal Annapurve Subject: Re: [PATCH v10 09/43] KVM: arm64: Allow passing machine type in KVM creation In-Reply-To: <20250820145606.180644-10-steven.price@arm.com> References: <20250820145606.180644-1-steven.price@arm.com> <20250820145606.180644-10-steven.price@arm.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: steven.price@arm.com, kvm@vger.kernel.org, kvmarm@lists.linux.dev, catalin.marinas@arm.com, will@kernel.org, james.morse@arm.com, oliver.upton@linux.dev, suzuki.poulose@arm.com, yuzenghui@huawei.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, joey.gouly@arm.com, alexandru.elisei@arm.com, christoffer.dall@arm.com, tabba@google.com, linux-coco@lists.linux.dev, gankulkarni@os.amperecomputing.com, gshan@redhat.com, sdonthineni@nvidia.com, alpergun@google.com, aneesh.kumar@kernel.org, fj0570is@fujitsu.com, vannapurve@google.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Wed, 20 Aug 2025 15:55:29 +0100, Steven Price wrote: > > Previously machine type was used purely for specifying the physical > address size of the guest. Reserve the higher bits to specify an ARM > specific machine type and declare a new type 'KVM_VM_TYPE_ARM_REALM' > used to create a realm guest. > > Reviewed-by: Suzuki K Poulose > Reviewed-by: Gavin Shan > Signed-off-by: Steven Price > --- > Changes since v9: > * Explictly set realm.state to REALM_STATE_NONE rather than rely on the > zeroing of the structure. > Changes since v7: > * Add some documentation explaining the new machine type. > Changes since v6: > * Make the check for kvm_rme_is_available more visible and report an > error code of -EPERM (instead of -EINVAL) to make it explicit that > the kernel supports RME, but the platform doesn't. > --- > Documentation/virt/kvm/api.rst | 16 ++++++++++++++-- > arch/arm64/kvm/arm.c | 16 ++++++++++++++++ > arch/arm64/kvm/mmu.c | 3 --- > include/uapi/linux/kvm.h | 19 +++++++++++++++---- > 4 files changed, 45 insertions(+), 9 deletions(-) > > diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst > index 69c0a9eba6c5..fad3191df311 100644 > --- a/Documentation/virt/kvm/api.rst > +++ b/Documentation/virt/kvm/api.rst > @@ -181,8 +181,20 @@ flag KVM_VM_MIPS_VZ. > ARM64: > ^^^^^^ > > -On arm64, the physical address size for a VM (IPA Size limit) is limited > -to 40bits by default. The limit can be configured if the host supports the > +On arm64, the machine type identifier is used to encode a type and the > +physical address size for the VM. The lower byte (bits[7-0]) encode the > +address size and the upper bits[11-8] encode a machine type. The machine > +types that might be available are: > + > + ====================== ============================================ > + KVM_VM_TYPE_ARM_NORMAL A standard VM > + KVM_VM_TYPE_ARM_REALM A "Realm" VM using the Arm Confidential > + Compute extensions, the VM's memory is > + protected from the host. > + ====================== ============================================ > + > +The physical address size for a VM (IPA Size limit) is limited to 40bits > +by default. The limit can be configured if the host supports the > extension KVM_CAP_ARM_VM_IPA_SIZE. When supported, use > KVM_VM_TYPE_ARM_IPA_SIZE(IPA_Bits) to set the size in the machine type > identifier, where IPA_Bits is the maximum width of any physical > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c > index 8c0e9ec34f0a..5b582b705eee 100644 > --- a/arch/arm64/kvm/arm.c > +++ b/arch/arm64/kvm/arm.c > @@ -172,6 +172,22 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type) > mutex_unlock(&kvm->lock); > #endif > > + if (type & ~(KVM_VM_TYPE_ARM_MASK | KVM_VM_TYPE_ARM_IPA_SIZE_MASK)) > + return -EINVAL; > + > + switch (type & KVM_VM_TYPE_ARM_MASK) { > + case KVM_VM_TYPE_ARM_NORMAL: > + break; > + case KVM_VM_TYPE_ARM_REALM: > + if (!static_branch_unlikely(&kvm_rme_is_available)) > + return -EPERM; EPERM? That's rather odd. You can only do that if the CCA capability has been advertised. So asking for it when you can find that it is not there deserves more of an EINVAL response. > + WRITE_ONCE(kvm->arch.realm.state, REALM_STATE_NONE); > + kvm->arch.is_realm = true; > + break; > + default: > + return -EINVAL; > + } > + > kvm_init_nested(kvm); > > ret = kvm_share_hyp(kvm, kvm + 1); > diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c > index de10dbde4761..130f28dfb3cb 100644 > --- a/arch/arm64/kvm/mmu.c > +++ b/arch/arm64/kvm/mmu.c > @@ -881,9 +881,6 @@ static int kvm_init_ipa_range(struct kvm *kvm, > if (kvm_is_realm(kvm)) > kvm_ipa_limit = kvm_realm_ipa_limit(); > > - if (type & ~KVM_VM_TYPE_ARM_IPA_SIZE_MASK) > - return -EINVAL; > - How about the *other* bits? You need to be able to detect that userspace is using the reserved bits and error out. > phys_shift = KVM_VM_TYPE_ARM_IPA_SIZE(type); > if (is_protected_kvm_enabled()) { > phys_shift = kvm_ipa_limit; > diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h > index 7dafb443368a..b70ecee918de 100644 > --- a/include/uapi/linux/kvm.h > +++ b/include/uapi/linux/kvm.h > @@ -672,14 +672,25 @@ struct kvm_enable_cap { > #define KVM_S390_SIE_PAGE_OFFSET 1 > > /* > - * On arm64, machine type can be used to request the physical > - * address size for the VM. Bits[7-0] are reserved for the guest > - * PA size shift (i.e, log2(PA_Size)). For backward compatibility, > - * value 0 implies the default IPA size, 40bits. > + * On arm64, machine type can be used to request both the machine type and > + * the physical address size for the VM. > + * > + * Bits[11-8] are reserved for the ARM specific machine type. > + * > + * Bits[7-0] are reserved for the guest PA size shift (i.e, log2(PA_Size)). > + * For backward compatibility, value 0 implies the default IPA size, 40bits. > */ > +#define KVM_VM_TYPE_ARM_SHIFT 8 > +#define KVM_VM_TYPE_ARM_MASK (0xfULL << KVM_VM_TYPE_ARM_SHIFT) > +#define KVM_VM_TYPE_ARM(_type) \ > + (((_type) << KVM_VM_TYPE_ARM_SHIFT) & KVM_VM_TYPE_ARM_MASK) > +#define KVM_VM_TYPE_ARM_NORMAL KVM_VM_TYPE_ARM(0) > +#define KVM_VM_TYPE_ARM_REALM KVM_VM_TYPE_ARM(1) Why can't that be just "PROTECTED", using bit 31, just like pKVM? I don't see the point in deviating from an established practice. M. -- Without deviation from the norm, progress is not possible.