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 X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 65396C4167B for ; Tue, 8 Dec 2020 18:22:40 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 1AFF323B46 for ; Tue, 8 Dec 2020 18:22:40 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1AFF323B46 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Message-ID:References:In-Reply-To:Subject:To:From: Date:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=rXA5PKQiIcPtmgLik1Msa99ZWpj3SRAmjFAQTKeeLuk=; b=It62f+jaensvADu6/R8Jo+2si 6vT6Nm72aZvaGbrSWbACVnetKP4tRdN+CoLEDlezKWtealXWsIOCFv3XyRrJE0tkzZNigfDRY+SEk 6dPRnl6nWm+2Ssdy5AVnferK4H8cOosKFWL0dV4SIbbQ+5iahp4Kqcrsj1hBG1ATARLwdheTM23lk sdtKEbS4UYOrA/UJ9WWlhb5WNMkGEhyI+xy8vC12wG5aTnS71xsAXjMxmuognA8XJg6pyLM09YbIp tUqvbTdWP1WB5czqzyj4Y366GYjM+j3jegFRQVKLV46sJ51QxiySn9WhYsapcqYyFUtRSu4jIDkH+ mbb2DH6uQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kmhby-0001Qe-Ub; Tue, 08 Dec 2020 18:21:18 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kmhbv-0001Pq-RC for linux-arm-kernel@lists.infradead.org; Tue, 08 Dec 2020 18:21:16 +0000 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id A5E3823B46; Tue, 8 Dec 2020 18:21:14 +0000 (UTC) Received: from disco-boy.misterjones.org ([51.254.78.96] helo=www.loen.fr) by disco-boy.misterjones.org with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94) (envelope-from ) id 1kmhbs-00H9Yx-CO; Tue, 08 Dec 2020 18:21:12 +0000 MIME-Version: 1.0 Date: Tue, 08 Dec 2020 18:21:12 +0000 From: Marc Zyngier To: Catalin Marinas Subject: Re: [PATCH v5 0/2] MTE support for KVM guest In-Reply-To: <20201208172143.GB13960@gaia> References: <20201119184248.4bycy6ouvaxqdiiy@kamzik.brq.redhat.com> <46fd98a2-ee39-0086-9159-b38c406935ab@arm.com> <0d0eb6da6a11f76d10e532c157181985@kernel.org> <20201207163405.GD1526@gaia> <874kkx5thq.wl-maz@kernel.org> <20201208172143.GB13960@gaia> User-Agent: Roundcube Webmail/1.4.9 Message-ID: <7ff14490e253878d0735633b792e1ea9@kernel.org> X-Sender: maz@kernel.org X-SA-Exim-Connect-IP: 51.254.78.96 X-SA-Exim-Rcpt-To: catalin.marinas@arm.com, steven.price@arm.com, peter.maydell@linaro.org, haibo.xu@linaro.org, linux-kernel@vger.kernel.org, quintela@redhat.com, richard.henderson@linaro.org, qemu-devel@nongnu.org, dgilbert@redhat.com, tglx@linutronix.de, will@kernel.org, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, Dave.Martin@arm.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201208_132116_039954_E8E858CF X-CRM114-Status: GOOD ( 31.09 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Juan Quintela , QEMU Developers , Dave Martin , Richard Henderson , lkml - Kernel Mailing List , Steven Price , arm-mail-list , Haibo Xu , Thomas Gleixner , Will Deacon , kvmarm , "Dr. David Alan Gilbert" 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 2020-12-08 17:21, Catalin Marinas wrote: > On Mon, Dec 07, 2020 at 07:03:13PM +0000, Marc Zyngier wrote: >> On Mon, 07 Dec 2020 16:34:05 +0000, >> Catalin Marinas wrote: >> > On Mon, Dec 07, 2020 at 04:05:55PM +0000, Marc Zyngier wrote: >> > > What I'd really like to see is a description of how shared memory >> > > is, in general, supposed to work with MTE. My gut feeling is that >> > > it doesn't, and that you need to turn MTE off when sharing memory >> > > (either implicitly or explicitly). >> > >> > The allocation tag (in-memory tag) is a property assigned to a physical >> > address range and it can be safely shared between different processes as >> > long as they access it via pointers with the same allocation tag (bits >> > 59:56). The kernel enables such tagged shared memory for user processes >> > (anonymous, tmpfs, shmem). >> >> I think that's one case where the shared memory scheme breaks, as we >> have two kernels in charge of their own tags, and they obviously can't >> be synchronised > > Yes, if you can't trust the other entity to not change the tags, the > only option is to do an untagged access. > >> > What we don't have in the architecture is a memory type which allows >> > access to tags but no tag checking. To access the data when the tags >> > aren't known, the tag checking would have to be disabled via either a >> > prctl() or by setting the PSTATE.TCO bit. >> >> I guess that's point (3) in Steven's taxonomy. It still a bit ugly to >> fit in an existing piece of userspace, specially if it wants to use >> MTE for its own benefit. > > I agree it's ugly. For the device DMA emulation case, the only sane way > is to mimic what a real device does - no tag checking. For a generic > implementation, this means that such shared memory should not be mapped > with PROT_MTE on the VMM side. I guess this leads to your point that > sharing doesn't work for this scenario ;). Exactly ;-) >> > The kernel accesses the user memory via the linear map using a match-all >> > tag 0xf, so no TCO bit toggling. For user, however, we disabled such >> > match-all tag and it cannot be enabled at run-time (at least not easily, >> > it's cached in the TLB). However, we already have two modes to disable >> > tag checking which Qemu could use when migrating data+tags. >> >> I wonder whether we will have to have something kernel side to >> dump/reload tags in a way that matches the patterns used by live >> migration. > > We have something related - ptrace dumps/resores the tags. Can the same > concept be expanded to a KVM ioctl? Yes, although I wonder whether we should integrate this deeply into the dirty-log mechanism: it would be really interesting to dump the tags at the point where the page is flagged as clean from a dirty-log point of view. As the page is dirtied, discard the saved tags. It is probably expensive, but it ensures that the VMM sees consistent tags (if the page is clean, the tags are valid). Of course, it comes with the added requirement that the VMM allocates enough memory to store the tags, which may be a tall order. I'm not sure how to give a consistent view to userspace otherwise. It'd be worth looking at how much we can reuse from the ptrace (and I expect swap?) code to implement this. Thanks, M. -- Jazz is not dead. It just smells funny... _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel