Message ID | 20230127112932.38045-6-steven.price@arm.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp783118wrn; Fri, 27 Jan 2023 03:33:01 -0800 (PST) X-Google-Smtp-Source: AK7set81UTgSZBakheBt+gNByVBqvFQUCCHJljgk0qbjHtcZmXrxrENxjvzsX48R9q0MnZFfD9bR X-Received: by 2002:a17:902:f550:b0:196:1682:6fe with SMTP id h16-20020a170902f55000b00196168206femr16890403plf.64.1674819181434; Fri, 27 Jan 2023 03:33:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1674819181; cv=none; d=google.com; s=arc-20160816; b=sUz3K2RYWWV9c5WBq4BdZT0jM3zSC93NhySe3MI5peS33/N/RQE0nT7O1PP6NCrWWv Ha6O5Sf3BaWZ53OjYyPmK0zOa4Hn9HI1rCYNIjyeW43VOzem/XD0pHBOpR//voUIeYBD d34GOyktNVid1bhxEsgYMBjPNbYM419yynuqpK/4vqIhPHDVqt3pmmopV6MSxtrdO0sZ ZGpSEh6gXzQaHDXuH1ZX+12h0UxuWe4WmHV8Bu4w56fEzlz39nChnJgWmiLENp4FrgzO bRb5Z4+/jq8TGehVAloV6dhKqYy7RQJknFBZ4SsrDa9Z9QWwlMmeettF3PFfeA+gRLzE DmOA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=lAYefdcE1lEEe71L7njJGKRJ3Lud4QfHf368xnUjN/4=; b=zPO32K9RWm1Sqg+pnn0yHZPf7MEweamAujgUNhstdbmxgJRDgNOarldDtAjmjlvlvF Hu4189obKwdBEF9PWJ5zKGQb/MJYLRac+x27iQT01JFY3Q9Ie6bIe+xrDtvFvLEfyjAt 1BTqFKSYU0nLAH6CosfepvjgZC4WN71kZcNP+YfXALEAeYMvXlCbUCzBeg8sLsZFj5XD Qbs80mAD4Cl+zMpOEyjKC0g+im3gf1regtjGq93Jc8AzoyTAy9wDfolxOpPvO5GkG7IL O6aBFH4dv3bbMcKV5L6Vp4t+Kcrah5ZL9UCCY10abCRO++5hLT0P8+4tvaLFqP16ePNk uU9A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id s6-20020a170902b18600b001873a81f2d1si4011456plr.87.2023.01.27.03.32.49; Fri, 27 Jan 2023 03:33:01 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233313AbjA0Lc1 (ORCPT <rfc822;lekhanya01809@gmail.com> + 99 others); Fri, 27 Jan 2023 06:32:27 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41942 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233574AbjA0LcK (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 27 Jan 2023 06:32:10 -0500 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 427DF80038; Fri, 27 Jan 2023 03:30:37 -0800 (PST) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id DDEF815BF; Fri, 27 Jan 2023 03:30:37 -0800 (PST) Received: from e122027.cambridge.arm.com (e122027.cambridge.arm.com [10.1.35.16]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D62683F64C; Fri, 27 Jan 2023 03:29:53 -0800 (PST) From: Steven Price <steven.price@arm.com> To: kvm@vger.kernel.org, kvmarm@lists.linux.dev Cc: Steven Price <steven.price@arm.com>, Catalin Marinas <catalin.marinas@arm.com>, Marc Zyngier <maz@kernel.org>, Will Deacon <will@kernel.org>, James Morse <james.morse@arm.com>, Oliver Upton <oliver.upton@linux.dev>, Suzuki K Poulose <suzuki.poulose@arm.com>, Zenghui Yu <yuzenghui@huawei.com>, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Joey Gouly <joey.gouly@arm.com>, Alexandru Elisei <alexandru.elisei@arm.com>, Christoffer Dall <christoffer.dall@arm.com>, Fuad Tabba <tabba@google.com>, linux-coco@lists.linux.dev Subject: [RFC PATCH 05/28] arm64: RME: Define the user ABI Date: Fri, 27 Jan 2023 11:29:09 +0000 Message-Id: <20230127112932.38045-6-steven.price@arm.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230127112932.38045-1-steven.price@arm.com> References: <20230127112248.136810-1-suzuki.poulose@arm.com> <20230127112932.38045-1-steven.price@arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1756175197792232594?= X-GMAIL-MSGID: =?utf-8?q?1756175197792232594?= |
Series |
arm64: Support for Arm CCA in KVM
|
|
Commit Message
Steven Price
Jan. 27, 2023, 11:29 a.m. UTC
There is one (multiplexed) CAP which can be used to create, populate and
then activate the realm.
Signed-off-by: Steven Price <steven.price@arm.com>
---
Documentation/virt/kvm/api.rst | 1 +
arch/arm64/include/uapi/asm/kvm.h | 63 +++++++++++++++++++++++++++++++
include/uapi/linux/kvm.h | 2 +
3 files changed, 66 insertions(+)
Comments
On Fri, 27 Jan 2023 11:29:09 +0000 Steven Price <steven.price@arm.com> wrote: > There is one (multiplexed) CAP which can be used to create, populate and > then activate the realm. > > Signed-off-by: Steven Price <steven.price@arm.com> > --- > Documentation/virt/kvm/api.rst | 1 + > arch/arm64/include/uapi/asm/kvm.h | 63 +++++++++++++++++++++++++++++++ > include/uapi/linux/kvm.h | 2 + > 3 files changed, 66 insertions(+) > > diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst > index 0dd5d8733dd5..f1a59d6fb7fc 100644 > --- a/Documentation/virt/kvm/api.rst > +++ b/Documentation/virt/kvm/api.rst > @@ -4965,6 +4965,7 @@ Recognised values for feature: > > ===== =========================================== > arm64 KVM_ARM_VCPU_SVE (requires KVM_CAP_ARM_SVE) > + arm64 KVM_ARM_VCPU_REC (requires KVM_CAP_ARM_RME) > ===== =========================================== > > Finalizes the configuration of the specified vcpu feature. > diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h > index a7a857f1784d..fcc0b8dce29b 100644 > --- a/arch/arm64/include/uapi/asm/kvm.h > +++ b/arch/arm64/include/uapi/asm/kvm.h > @@ -109,6 +109,7 @@ struct kvm_regs { > #define KVM_ARM_VCPU_SVE 4 /* enable SVE for this CPU */ > #define KVM_ARM_VCPU_PTRAUTH_ADDRESS 5 /* VCPU uses address authentication */ > #define KVM_ARM_VCPU_PTRAUTH_GENERIC 6 /* VCPU uses generic authentication */ > +#define KVM_ARM_VCPU_REC 7 /* VCPU REC state as part of Realm */ > > struct kvm_vcpu_init { > __u32 target; > @@ -401,6 +402,68 @@ enum { > #define KVM_DEV_ARM_VGIC_SAVE_PENDING_TABLES 3 > #define KVM_DEV_ARM_ITS_CTRL_RESET 4 > > +/* KVM_CAP_ARM_RME on VM fd */ > +#define KVM_CAP_ARM_RME_CONFIG_REALM 0 > +#define KVM_CAP_ARM_RME_CREATE_RD 1 > +#define KVM_CAP_ARM_RME_INIT_IPA_REALM 2 > +#define KVM_CAP_ARM_RME_POPULATE_REALM 3 > +#define KVM_CAP_ARM_RME_ACTIVATE_REALM 4 > + It is a little bit confusing here. These seems more like 'commands' not caps. Will leave more comments after reviewing the later patches. > +#define KVM_CAP_ARM_RME_MEASUREMENT_ALGO_SHA256 0 > +#define KVM_CAP_ARM_RME_MEASUREMENT_ALGO_SHA512 1 > + > +#define KVM_CAP_ARM_RME_RPV_SIZE 64 > + > +/* List of configuration items accepted for KVM_CAP_ARM_RME_CONFIG_REALM */ > +#define KVM_CAP_ARM_RME_CFG_RPV 0 > +#define KVM_CAP_ARM_RME_CFG_HASH_ALGO 1 > +#define KVM_CAP_ARM_RME_CFG_SVE 2 > +#define KVM_CAP_ARM_RME_CFG_DBG 3 > +#define KVM_CAP_ARM_RME_CFG_PMU 4 > + > +struct kvm_cap_arm_rme_config_item { > + __u32 cfg; > + union { > + /* cfg == KVM_CAP_ARM_RME_CFG_RPV */ > + struct { > + __u8 rpv[KVM_CAP_ARM_RME_RPV_SIZE]; > + }; > + > + /* cfg == KVM_CAP_ARM_RME_CFG_HASH_ALGO */ > + struct { > + __u32 hash_algo; > + }; > + > + /* cfg == KVM_CAP_ARM_RME_CFG_SVE */ > + struct { > + __u32 sve_vq; > + }; > + > + /* cfg == KVM_CAP_ARM_RME_CFG_DBG */ > + struct { > + __u32 num_brps; > + __u32 num_wrps; > + }; > + > + /* cfg == KVM_CAP_ARM_RME_CFG_PMU */ > + struct { > + __u32 num_pmu_cntrs; > + }; > + /* Fix the size of the union */ > + __u8 reserved[256]; > + }; > +}; > + > +struct kvm_cap_arm_rme_populate_realm_args { > + __u64 populate_ipa_base; > + __u64 populate_ipa_size; > +}; > + > +struct kvm_cap_arm_rme_init_ipa_args { > + __u64 init_ipa_base; > + __u64 init_ipa_size; > +}; > + > /* Device Control API on vcpu fd */ > #define KVM_ARM_VCPU_PMU_V3_CTRL 0 > #define KVM_ARM_VCPU_PMU_V3_IRQ 0 > diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h > index 20522d4ba1e0..fec1909e8b73 100644 > --- a/include/uapi/linux/kvm.h > +++ b/include/uapi/linux/kvm.h > @@ -1176,6 +1176,8 @@ struct kvm_ppc_resize_hpt { > #define KVM_CAP_S390_PROTECTED_ASYNC_DISABLE 224 > #define KVM_CAP_DIRTY_LOG_RING_WITH_BITMAP 225 > > +#define KVM_CAP_ARM_RME 300 // FIXME: Large number to prevent conflicts > + > #ifdef KVM_CAP_IRQ_ROUTING > > struct kvm_irq_routing_irqchip {
On 13/02/2023 16:04, Zhi Wang wrote: > On Fri, 27 Jan 2023 11:29:09 +0000 > Steven Price <steven.price@arm.com> wrote: > >> There is one (multiplexed) CAP which can be used to create, populate and >> then activate the realm. >> >> Signed-off-by: Steven Price <steven.price@arm.com> >> --- >> Documentation/virt/kvm/api.rst | 1 + >> arch/arm64/include/uapi/asm/kvm.h | 63 +++++++++++++++++++++++++++++++ >> include/uapi/linux/kvm.h | 2 + >> 3 files changed, 66 insertions(+) >> >> diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst >> index 0dd5d8733dd5..f1a59d6fb7fc 100644 >> --- a/Documentation/virt/kvm/api.rst >> +++ b/Documentation/virt/kvm/api.rst >> @@ -4965,6 +4965,7 @@ Recognised values for feature: >> >> ===== =========================================== >> arm64 KVM_ARM_VCPU_SVE (requires KVM_CAP_ARM_SVE) >> + arm64 KVM_ARM_VCPU_REC (requires KVM_CAP_ARM_RME) >> ===== =========================================== >> >> Finalizes the configuration of the specified vcpu feature. >> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h >> index a7a857f1784d..fcc0b8dce29b 100644 >> --- a/arch/arm64/include/uapi/asm/kvm.h >> +++ b/arch/arm64/include/uapi/asm/kvm.h >> @@ -109,6 +109,7 @@ struct kvm_regs { >> #define KVM_ARM_VCPU_SVE 4 /* enable SVE for this CPU */ >> #define KVM_ARM_VCPU_PTRAUTH_ADDRESS 5 /* VCPU uses address authentication */ >> #define KVM_ARM_VCPU_PTRAUTH_GENERIC 6 /* VCPU uses generic authentication */ >> +#define KVM_ARM_VCPU_REC 7 /* VCPU REC state as part of Realm */ >> >> struct kvm_vcpu_init { >> __u32 target; >> @@ -401,6 +402,68 @@ enum { >> #define KVM_DEV_ARM_VGIC_SAVE_PENDING_TABLES 3 >> #define KVM_DEV_ARM_ITS_CTRL_RESET 4 >> >> +/* KVM_CAP_ARM_RME on VM fd */ >> +#define KVM_CAP_ARM_RME_CONFIG_REALM 0 >> +#define KVM_CAP_ARM_RME_CREATE_RD 1 >> +#define KVM_CAP_ARM_RME_INIT_IPA_REALM 2 >> +#define KVM_CAP_ARM_RME_POPULATE_REALM 3 >> +#define KVM_CAP_ARM_RME_ACTIVATE_REALM 4 >> + > > It is a little bit confusing here. These seems more like 'commands' not caps. > Will leave more comments after reviewing the later patches. Sorry for the slow response. Thank you for your review - I hope to post a new version of this series (rebased on 6.3-rc1) in the coming weeks with your comments addressed. They are indeed commands - and using caps is a bit of a hack. The benefit here is that all the Realm commands are behind the one KVM_CAP_ARM_RME. The options I can see are: a) What I've got here - (ab)using KVM_ENABLE_CAP to perform commands. b) Add new ioctls for each of the above stages (so 5 new ioctls on top of the CAP for discovery). With any future extensions requiring new ioctls. c) Add a single new multiplexing ioctl (along with the CAP for discovery). I'm not massively keen on defining a new multiplexing scheme (c), but equally (b) seems like it's burning through ioctl numbers. Which led me to stick with (a) which at least keeps the rebasing simple (there's only the one CAP number which could conflict) and there's already a multiplexing scheme. But I'm happy to change if there's consensus a different approach would be preferable. Thanks, Steve >> +#define KVM_CAP_ARM_RME_MEASUREMENT_ALGO_SHA256 0 >> +#define KVM_CAP_ARM_RME_MEASUREMENT_ALGO_SHA512 1 >> + >> +#define KVM_CAP_ARM_RME_RPV_SIZE 64 >> + >> +/* List of configuration items accepted for KVM_CAP_ARM_RME_CONFIG_REALM */ >> +#define KVM_CAP_ARM_RME_CFG_RPV 0 >> +#define KVM_CAP_ARM_RME_CFG_HASH_ALGO 1 >> +#define KVM_CAP_ARM_RME_CFG_SVE 2 >> +#define KVM_CAP_ARM_RME_CFG_DBG 3 >> +#define KVM_CAP_ARM_RME_CFG_PMU 4 >> + >> +struct kvm_cap_arm_rme_config_item { >> + __u32 cfg; >> + union { >> + /* cfg == KVM_CAP_ARM_RME_CFG_RPV */ >> + struct { >> + __u8 rpv[KVM_CAP_ARM_RME_RPV_SIZE]; >> + }; >> + >> + /* cfg == KVM_CAP_ARM_RME_CFG_HASH_ALGO */ >> + struct { >> + __u32 hash_algo; >> + }; >> + >> + /* cfg == KVM_CAP_ARM_RME_CFG_SVE */ >> + struct { >> + __u32 sve_vq; >> + }; >> + >> + /* cfg == KVM_CAP_ARM_RME_CFG_DBG */ >> + struct { >> + __u32 num_brps; >> + __u32 num_wrps; >> + }; >> + >> + /* cfg == KVM_CAP_ARM_RME_CFG_PMU */ >> + struct { >> + __u32 num_pmu_cntrs; >> + }; >> + /* Fix the size of the union */ >> + __u8 reserved[256]; >> + }; >> +}; >> + >> +struct kvm_cap_arm_rme_populate_realm_args { >> + __u64 populate_ipa_base; >> + __u64 populate_ipa_size; >> +}; >> + >> +struct kvm_cap_arm_rme_init_ipa_args { >> + __u64 init_ipa_base; >> + __u64 init_ipa_size; >> +}; >> + >> /* Device Control API on vcpu fd */ >> #define KVM_ARM_VCPU_PMU_V3_CTRL 0 >> #define KVM_ARM_VCPU_PMU_V3_IRQ 0 >> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h >> index 20522d4ba1e0..fec1909e8b73 100644 >> --- a/include/uapi/linux/kvm.h >> +++ b/include/uapi/linux/kvm.h >> @@ -1176,6 +1176,8 @@ struct kvm_ppc_resize_hpt { >> #define KVM_CAP_S390_PROTECTED_ASYNC_DISABLE 224 >> #define KVM_CAP_DIRTY_LOG_RING_WITH_BITMAP 225 >> >> +#define KVM_CAP_ARM_RME 300 // FIXME: Large number to prevent conflicts >> + >> #ifdef KVM_CAP_IRQ_ROUTING >> >> struct kvm_irq_routing_irqchip { >
On Wed, 1 Mar 2023 11:54:34 +0000 Steven Price <steven.price@arm.com> wrote: > On 13/02/2023 16:04, Zhi Wang wrote: > > On Fri, 27 Jan 2023 11:29:09 +0000 > > Steven Price <steven.price@arm.com> wrote: > > > >> There is one (multiplexed) CAP which can be used to create, populate and > >> then activate the realm. > >> > >> Signed-off-by: Steven Price <steven.price@arm.com> > >> --- > >> Documentation/virt/kvm/api.rst | 1 + > >> arch/arm64/include/uapi/asm/kvm.h | 63 +++++++++++++++++++++++++++++++ > >> include/uapi/linux/kvm.h | 2 + > >> 3 files changed, 66 insertions(+) > >> > >> diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst > >> index 0dd5d8733dd5..f1a59d6fb7fc 100644 > >> --- a/Documentation/virt/kvm/api.rst > >> +++ b/Documentation/virt/kvm/api.rst > >> @@ -4965,6 +4965,7 @@ Recognised values for feature: > >> > >> ===== =========================================== > >> arm64 KVM_ARM_VCPU_SVE (requires KVM_CAP_ARM_SVE) > >> + arm64 KVM_ARM_VCPU_REC (requires KVM_CAP_ARM_RME) > >> ===== =========================================== > >> > >> Finalizes the configuration of the specified vcpu feature. > >> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h > >> index a7a857f1784d..fcc0b8dce29b 100644 > >> --- a/arch/arm64/include/uapi/asm/kvm.h > >> +++ b/arch/arm64/include/uapi/asm/kvm.h > >> @@ -109,6 +109,7 @@ struct kvm_regs { > >> #define KVM_ARM_VCPU_SVE 4 /* enable SVE for this CPU */ > >> #define KVM_ARM_VCPU_PTRAUTH_ADDRESS 5 /* VCPU uses address authentication */ > >> #define KVM_ARM_VCPU_PTRAUTH_GENERIC 6 /* VCPU uses generic authentication */ > >> +#define KVM_ARM_VCPU_REC 7 /* VCPU REC state as part of Realm */ > >> > >> struct kvm_vcpu_init { > >> __u32 target; > >> @@ -401,6 +402,68 @@ enum { > >> #define KVM_DEV_ARM_VGIC_SAVE_PENDING_TABLES 3 > >> #define KVM_DEV_ARM_ITS_CTRL_RESET 4 > >> > >> +/* KVM_CAP_ARM_RME on VM fd */ > >> +#define KVM_CAP_ARM_RME_CONFIG_REALM 0 > >> +#define KVM_CAP_ARM_RME_CREATE_RD 1 > >> +#define KVM_CAP_ARM_RME_INIT_IPA_REALM 2 > >> +#define KVM_CAP_ARM_RME_POPULATE_REALM 3 > >> +#define KVM_CAP_ARM_RME_ACTIVATE_REALM 4 > >> + > > > > It is a little bit confusing here. These seems more like 'commands' not caps. > > Will leave more comments after reviewing the later patches. > > Sorry for the slow response. Thank you for your review - I hope to post > a new version of this series (rebased on 6.3-rc1) in the coming weeks > with your comments addressed. > Hi: No worries. I spent most of my time on closing the review of TDX/SNP series recently while stopped at patch 16 of this series. I will try to finish the rest of this series this week. I am glad if my efforts help and more reviewers can smoothly jump in later. > They are indeed commands - and using caps is a bit of a hack. The > benefit here is that all the Realm commands are behind the one > KVM_CAP_ARM_RME. > > The options I can see are: > > a) What I've got here - (ab)using KVM_ENABLE_CAP to perform commands. > > b) Add new ioctls for each of the above stages (so 5 new ioctls on top > of the CAP for discovery). With any future extensions requiring new ioctls. > > c) Add a single new multiplexing ioctl (along with the CAP for discovery). > > I'm not massively keen on defining a new multiplexing scheme (c), but > equally (b) seems like it's burning through ioctl numbers. Which led me > to stick with (a) which at least keeps the rebasing simple (there's only > the one CAP number which could conflict) and there's already a > multiplexing scheme. > > But I'm happy to change if there's consensus a different approach would > be preferable. > Let's see if others have different opinions. My coin goes to b as it is better to respect "what it is, make it explicit and clear" when coming to define the UABI. Ioctl number is for UABI. If it is going to burn out, IMHO, we need to find another way, perhaps another fd to group those ioctls, like KVM. 1. a) seems abusing the usage of the cap. for sure, the benefit is obvious. 2. c) seems hiding the details, which saves the ioctl numbers, but it didn't actually help a lot on the complexity and might end up with another bunch of "command code". > Thanks, > > Steve > > >> +#define KVM_CAP_ARM_RME_MEASUREMENT_ALGO_SHA256 0 > >> +#define KVM_CAP_ARM_RME_MEASUREMENT_ALGO_SHA512 1 > >> + > >> +#define KVM_CAP_ARM_RME_RPV_SIZE 64 > >> + > >> +/* List of configuration items accepted for KVM_CAP_ARM_RME_CONFIG_REALM */ > >> +#define KVM_CAP_ARM_RME_CFG_RPV 0 > >> +#define KVM_CAP_ARM_RME_CFG_HASH_ALGO 1 > >> +#define KVM_CAP_ARM_RME_CFG_SVE 2 > >> +#define KVM_CAP_ARM_RME_CFG_DBG 3 > >> +#define KVM_CAP_ARM_RME_CFG_PMU 4 > >> + > >> +struct kvm_cap_arm_rme_config_item { > >> + __u32 cfg; > >> + union { > >> + /* cfg == KVM_CAP_ARM_RME_CFG_RPV */ > >> + struct { > >> + __u8 rpv[KVM_CAP_ARM_RME_RPV_SIZE]; > >> + }; > >> + > >> + /* cfg == KVM_CAP_ARM_RME_CFG_HASH_ALGO */ > >> + struct { > >> + __u32 hash_algo; > >> + }; > >> + > >> + /* cfg == KVM_CAP_ARM_RME_CFG_SVE */ > >> + struct { > >> + __u32 sve_vq; > >> + }; > >> + > >> + /* cfg == KVM_CAP_ARM_RME_CFG_DBG */ > >> + struct { > >> + __u32 num_brps; > >> + __u32 num_wrps; > >> + }; > >> + > >> + /* cfg == KVM_CAP_ARM_RME_CFG_PMU */ > >> + struct { > >> + __u32 num_pmu_cntrs; > >> + }; > >> + /* Fix the size of the union */ > >> + __u8 reserved[256]; > >> + }; > >> +}; > >> + > >> +struct kvm_cap_arm_rme_populate_realm_args { > >> + __u64 populate_ipa_base; > >> + __u64 populate_ipa_size; > >> +}; > >> + > >> +struct kvm_cap_arm_rme_init_ipa_args { > >> + __u64 init_ipa_base; > >> + __u64 init_ipa_size; > >> +}; > >> + > >> /* Device Control API on vcpu fd */ > >> #define KVM_ARM_VCPU_PMU_V3_CTRL 0 > >> #define KVM_ARM_VCPU_PMU_V3_IRQ 0 > >> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h > >> index 20522d4ba1e0..fec1909e8b73 100644 > >> --- a/include/uapi/linux/kvm.h > >> +++ b/include/uapi/linux/kvm.h > >> @@ -1176,6 +1176,8 @@ struct kvm_ppc_resize_hpt { > >> #define KVM_CAP_S390_PROTECTED_ASYNC_DISABLE 224 > >> #define KVM_CAP_DIRTY_LOG_RING_WITH_BITMAP 225 > >> > >> +#define KVM_CAP_ARM_RME 300 // FIXME: Large number to prevent conflicts > >> + > >> #ifdef KVM_CAP_IRQ_ROUTING > >> > >> struct kvm_irq_routing_irqchip { > > >
diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index 0dd5d8733dd5..f1a59d6fb7fc 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -4965,6 +4965,7 @@ Recognised values for feature: ===== =========================================== arm64 KVM_ARM_VCPU_SVE (requires KVM_CAP_ARM_SVE) + arm64 KVM_ARM_VCPU_REC (requires KVM_CAP_ARM_RME) ===== =========================================== Finalizes the configuration of the specified vcpu feature. diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h index a7a857f1784d..fcc0b8dce29b 100644 --- a/arch/arm64/include/uapi/asm/kvm.h +++ b/arch/arm64/include/uapi/asm/kvm.h @@ -109,6 +109,7 @@ struct kvm_regs { #define KVM_ARM_VCPU_SVE 4 /* enable SVE for this CPU */ #define KVM_ARM_VCPU_PTRAUTH_ADDRESS 5 /* VCPU uses address authentication */ #define KVM_ARM_VCPU_PTRAUTH_GENERIC 6 /* VCPU uses generic authentication */ +#define KVM_ARM_VCPU_REC 7 /* VCPU REC state as part of Realm */ struct kvm_vcpu_init { __u32 target; @@ -401,6 +402,68 @@ enum { #define KVM_DEV_ARM_VGIC_SAVE_PENDING_TABLES 3 #define KVM_DEV_ARM_ITS_CTRL_RESET 4 +/* KVM_CAP_ARM_RME on VM fd */ +#define KVM_CAP_ARM_RME_CONFIG_REALM 0 +#define KVM_CAP_ARM_RME_CREATE_RD 1 +#define KVM_CAP_ARM_RME_INIT_IPA_REALM 2 +#define KVM_CAP_ARM_RME_POPULATE_REALM 3 +#define KVM_CAP_ARM_RME_ACTIVATE_REALM 4 + +#define KVM_CAP_ARM_RME_MEASUREMENT_ALGO_SHA256 0 +#define KVM_CAP_ARM_RME_MEASUREMENT_ALGO_SHA512 1 + +#define KVM_CAP_ARM_RME_RPV_SIZE 64 + +/* List of configuration items accepted for KVM_CAP_ARM_RME_CONFIG_REALM */ +#define KVM_CAP_ARM_RME_CFG_RPV 0 +#define KVM_CAP_ARM_RME_CFG_HASH_ALGO 1 +#define KVM_CAP_ARM_RME_CFG_SVE 2 +#define KVM_CAP_ARM_RME_CFG_DBG 3 +#define KVM_CAP_ARM_RME_CFG_PMU 4 + +struct kvm_cap_arm_rme_config_item { + __u32 cfg; + union { + /* cfg == KVM_CAP_ARM_RME_CFG_RPV */ + struct { + __u8 rpv[KVM_CAP_ARM_RME_RPV_SIZE]; + }; + + /* cfg == KVM_CAP_ARM_RME_CFG_HASH_ALGO */ + struct { + __u32 hash_algo; + }; + + /* cfg == KVM_CAP_ARM_RME_CFG_SVE */ + struct { + __u32 sve_vq; + }; + + /* cfg == KVM_CAP_ARM_RME_CFG_DBG */ + struct { + __u32 num_brps; + __u32 num_wrps; + }; + + /* cfg == KVM_CAP_ARM_RME_CFG_PMU */ + struct { + __u32 num_pmu_cntrs; + }; + /* Fix the size of the union */ + __u8 reserved[256]; + }; +}; + +struct kvm_cap_arm_rme_populate_realm_args { + __u64 populate_ipa_base; + __u64 populate_ipa_size; +}; + +struct kvm_cap_arm_rme_init_ipa_args { + __u64 init_ipa_base; + __u64 init_ipa_size; +}; + /* Device Control API on vcpu fd */ #define KVM_ARM_VCPU_PMU_V3_CTRL 0 #define KVM_ARM_VCPU_PMU_V3_IRQ 0 diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h index 20522d4ba1e0..fec1909e8b73 100644 --- a/include/uapi/linux/kvm.h +++ b/include/uapi/linux/kvm.h @@ -1176,6 +1176,8 @@ struct kvm_ppc_resize_hpt { #define KVM_CAP_S390_PROTECTED_ASYNC_DISABLE 224 #define KVM_CAP_DIRTY_LOG_RING_WITH_BITMAP 225 +#define KVM_CAP_ARM_RME 300 // FIXME: Large number to prevent conflicts + #ifdef KVM_CAP_IRQ_ROUTING struct kvm_irq_routing_irqchip {