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 C545CC433F5 for ; Wed, 23 Mar 2022 13:51:49 +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-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=+KKdDI+F+dfZ9dJDnjgfOwmZvzz9D96wjVyU2uXRoU0=; b=GZ5mDA7foGnBAC 8aX877IkrCli8vJC9P4QDuNvoE5IJjc25yfuBBPwyr5xHfmvVXN7fustSXp2BVxGhMcoXECJhKRNc +h9+iZzMwykDXQk4ANSkKRrKeJDX/6yOMekDPLB8AAQM7z8rLeROJRDp/H5vyB9WyH5b4PHExfx0/ GvK3aQj3Ey6MREJHDYoV7TLpYwu3H7vW7jyp/yZypVVwtJwSOtwW3NHuQy9i1XJbgAO2uYnpwfzhR EbY2KCptwkykfNCMikBV2q+JYOBtcop8cqBChlVsSi618VT5PHkZaMrIKlCfpuzrrLJI6/b4dHhuw ACp02PUZqCtsznSFSQDw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nX1Nl-00Dmlv-Ra; Wed, 23 Mar 2022 13:50:37 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nX1Nh-00DmlN-Rh for linux-arm-kernel@lists.infradead.org; Wed, 23 Mar 2022 13:50:35 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 4ED52616A8; Wed, 23 Mar 2022 13:50:33 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4C051C340E8; Wed, 23 Mar 2022 13:50:31 +0000 (UTC) Date: Wed, 23 Mar 2022 13:50:27 +0000 From: Catalin Marinas To: Alexandru Elisei Cc: Vladimir Murzin , will@kernel.org, kvm@vger.kernel.org, julien.thierry.kdev@gmail.com, linux-arm-kernel@lists.infradead.org, steven.price@arm.com Subject: Re: [kvmtool PATCH 2/2] aarch64: Add support for MTE Message-ID: References: <20220321152820.246700-1-alexandru.elisei@arm.com> <20220321152820.246700-3-alexandru.elisei@arm.com> <3cf3b621-5a07-5c06-cb9f-f9c776b6717d@arm.com> <7e5ebae0-db08-ad87-0fa9-26da048a9b72@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220323_065034_021787_AFAAAF18 X-CRM114-Status: GOOD ( 36.15 ) 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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Mar 23, 2022 at 12:03:33PM +0000, Alexandru Elisei wrote: > On Wed, Mar 23, 2022 at 10:31:15AM +0000, Vladimir Murzin wrote: > > On 3/21/22 5:08 PM, Alexandru Elisei wrote: > > > On Mon, Mar 21, 2022 at 03:40:18PM +0000, Vladimir Murzin wrote: > > > > Can we enable it unconditionally if KVM_CAP_ARM_MTE is supported like we do for > > > > PAC and SVE? > > > > > > I thought about that, the reason I chose to enable it based a kvmtool > > > command line option, instead of always being enabled if available, is > > > because of the overhead of sanitising the MTE tags on each stage 2 data > > > abort. Steven, am I overreacting and that overhead is negligible? > > > > > > Also, as far as I know, PAC and SVE incur basically no overhead in KVM > > > until the guest starts to use those features. > > > > > > Do you have a specific reason for wanting MTE to always be enabled if > > > available? I'm happy to be convinced to make MTE enabled by default, I > > > don't have preference either way. > > > > Well, automatically enabling if available would align with what we do for > > other features in kvmtool and Linux itself - we tend to default y for new > > features, even MTE, thus improving chances to get reports back early if > > something (even performance) goes wrong. Just my 2p. > > According to Steven, for each 4k page the kernel uses an 128 byte buffer to > store the tags, and then some extra memory is used to keep track of the > buffers. Let's take the case of a VM with 1GB of memory, and be > conservative and only account for the tag buffer. In this case, the tag > buffers alone will be 32MB. The 128 byte buffer is only allocated *if* the page is swapped out. So if the host swaps out the entire 1GB guest memory, it will incur the 32MB cost. But a fully swapped out VM is pretty useless, so this doesn't happen very often. We do have the cost of zeroing the tags when the page is mapped into guests. I don't remember the KVM implementation but maybe we can optimise this to zero the tags at the same time with zeroing the data as we do for anonymous pages in the host (unless it does this already). We could use the fine-grained traps to detect when MAIR_EL1 was configured by the guest for Tagged memory but, at least with Linux, we do this at boot irrespective of whether any application will use MTE or not. Future architecture versions may address this problem. > The kernel documentation for MTE suggests that in order to take advantage > of it, software must be modified and recompiled. That means that users that > don't want to use MTE won't get to exercise MTE because they won't be using > MTE enabled software, but they will pay the overhead regardless. This of > course assumes that going forward software won't be using MTE by default. Not all software needs to be recompiled. It's sufficient most of the time to replace the glibc with an MTE-aware one. I have a slight preference for MTE default in kvmtool, maybe with an option to disable it if one doesn't care about the feature or we find the overhead to be significant (I don't think it would be). -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel