From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 49ACFC433EF for ; Thu, 24 Mar 2022 17:22:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=NraIOvh4HGYzNLVFXuZr4D8vZWzJf04ye6vBw5jIEKk=; b=po+Gw2qu3WkTEV WLNezZXfBOE0QFLBIJDawiA7j3MN4LiBaHfoknDuBDwiwNH5/ghi8PxpNhYJ6W+DuT80tUC3+6u1p td58Mzvqw5r8iVOT75YHj3tr6Df8aHKgITolKVikQcjV8zCLDuASft0f9nJ5b0PHzRDGMGxGhndHc ln5umKFNjJDj2ZLQGOmMK/QImzjBoYxBeSmTEhaV2AQpNOQvLnzg6ggkSSeNaxKbmZbpVFuQvB+A+ ndFuzK6qWIiWu5ItOwrGKZCb9lknzieIesLREXA9737qlAkihjOs2HwkIBtErUDlQdryA8WcsMA1s iINgwkI5C5qkPTdThsow==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nXR9a-00HLXH-7T; Thu, 24 Mar 2022 17:21:42 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nXR9V-00HLWR-Qt for linux-arm-kernel@lists.infradead.org; Thu, 24 Mar 2022 17:21:39 +0000 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 577CA1515; Thu, 24 Mar 2022 10:21:36 -0700 (PDT) Received: from [10.1.39.159] (e121487-lin.cambridge.arm.com [10.1.39.159]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 6CE0F3F73B; Thu, 24 Mar 2022 10:21:35 -0700 (PDT) Message-ID: <089fe68e-4679-4bdb-6b13-4e51c08c032a@arm.com> Date: Thu, 24 Mar 2022 17:21:34 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [kvmtool PATCH v2 2/2] aarch64: Add support for MTE Content-Language: en-US To: Alexandru Elisei Cc: will@kernel.org, julien.thierry.kdev@gmail.com, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, catalin.marinas@arm.com, steven.price@arm.com References: <20220324113942.24217-1-alexandru.elisei@arm.com> <20220324113942.24217-3-alexandru.elisei@arm.com> From: Vladimir Murzin In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220324_102138_001305_9D092631 X-CRM114-Status: GOOD ( 20.79 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 3/24/22 5:09 PM, Alexandru Elisei wrote: > Hi, > > On Thu, Mar 24, 2022 at 02:19:58PM +0000, Vladimir Murzin wrote: >> Hi Alexandru, >> >> On 3/24/22 11:39 AM, Alexandru Elisei wrote: >>> MTE has been supported in Linux since commit 673638f434ee ("KVM: arm64: >>> Expose KVM_ARM_CAP_MTE"), add support for it in kvmtool. MTE is enabled by >>> default. >>> >>> Enabling the MTE capability incurs a cost, both in time (for each >>> translation fault the tags need to be cleared), and in space (the tags need >>> to be saved when a physical page is swapped out). This overhead is expected >>> to be negligible for most users, but for those cases where they matter >>> (like performance benchmarks), a --disable-mte option has been added. >>> >>> Signed-off-by: Alexandru Elisei >>> --- >>> arm/aarch32/include/kvm/kvm-arch.h | 3 +++ >>> arm/aarch64/include/kvm/kvm-arch.h | 1 + >>> arm/aarch64/include/kvm/kvm-config-arch.h | 2 ++ >>> arm/aarch64/kvm.c | 23 +++++++++++++++++++++++ >>> arm/include/arm-common/kvm-config-arch.h | 1 + >>> arm/kvm.c | 2 ++ >>> 6 files changed, 32 insertions(+) >>> >>> diff --git a/arm/aarch32/include/kvm/kvm-arch.h b/arm/aarch32/include/kvm/kvm-arch.h >>> index bee2fc255a82..5616b27e257e 100644 >>> --- a/arm/aarch32/include/kvm/kvm-arch.h >>> +++ b/arm/aarch32/include/kvm/kvm-arch.h >>> @@ -5,6 +5,9 @@ >>> #define kvm__arch_get_kern_offset(...) 0x8000 >>> +struct kvm; >>> +static inline void kvm__arch_enable_mte(struct kvm *kvm) {} >>> + >>> #define ARM_MAX_MEMORY(...) ARM_LOMAP_MAX_MEMORY >>> #define MAX_PAGE_SIZE SZ_4K >>> diff --git a/arm/aarch64/include/kvm/kvm-arch.h b/arm/aarch64/include/kvm/kvm-arch.h >>> index 5e5ee41211ed..9124f6919d0f 100644 >>> --- a/arm/aarch64/include/kvm/kvm-arch.h >>> +++ b/arm/aarch64/include/kvm/kvm-arch.h >>> @@ -6,6 +6,7 @@ >>> struct kvm; >>> unsigned long long kvm__arch_get_kern_offset(struct kvm *kvm, int fd); >>> int kvm__arch_get_ipa_limit(struct kvm *kvm); >>> +void kvm__arch_enable_mte(struct kvm *kvm); >>> #define ARM_MAX_MEMORY(kvm) ({ \ >>> u64 max_ram; \ >>> diff --git a/arm/aarch64/include/kvm/kvm-config-arch.h b/arm/aarch64/include/kvm/kvm-config-arch.h >>> index 04be43dfa9b2..df4a15ff00a7 100644 >>> --- a/arm/aarch64/include/kvm/kvm-config-arch.h >>> +++ b/arm/aarch64/include/kvm/kvm-config-arch.h >>> @@ -6,6 +6,8 @@ >>> "Run AArch32 guest"), \ >>> OPT_BOOLEAN('\0', "pmu", &(cfg)->has_pmuv3, \ >>> "Create PMUv3 device"), \ >>> + OPT_BOOLEAN('\0', "disable-mte", &(cfg)->mte_disabled, \ >>> + "Disable Memory Tagging Extension capability"), \ >>> OPT_U64('\0', "kaslr-seed", &(cfg)->kaslr_seed, \ >>> "Specify random seed for Kernel Address Space " \ >>> "Layout Randomization (KASLR)"), >>> diff --git a/arm/aarch64/kvm.c b/arm/aarch64/kvm.c >>> index 56a0aedc263d..1035171a00f0 100644 >>> --- a/arm/aarch64/kvm.c >>> +++ b/arm/aarch64/kvm.c >>> @@ -81,3 +81,26 @@ int kvm__get_vm_type(struct kvm *kvm) >>> return KVM_VM_TYPE_ARM_IPA_SIZE(ipa_bits); >>> } >>> + >>> +void kvm__arch_enable_mte(struct kvm *kvm) >>> +{ >>> + struct kvm_enable_cap cap = { >>> + .cap = KVM_CAP_ARM_MTE, >>> + }; >>> + >>> + if (kvm->cfg.arch.mte_disabled) { >>> + pr_debug("MTE capability disabled by user"); >>> + return; >>> + } >> >> Nitpick: I'd move that bellow capability check, so it'd appear only in >> setups which support MTE > > I have no problem moving it, but I'm curious why you think it would be > useful. If the user disables MTE from kvmtool's command line doesn't that > mean that they aren't interested if the host supports it? It looks a bit > unexpected to me for kvmtool to check if the host supports MTE when the > user doesn't want to enable the cap. It is probably matters of taste (so nitpick). I'm thinking if somebody has scripts with --disable-mte which runs on zoo of hardware - we would output "MTE capability disabled by user" even on those which do no support MTE at all... "MTE capability not present", IMO, would look nicer on those machines Anyway, it is not a show stopper ;) Cheers Vladimir _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel