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=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 15572C433E0 for ; Wed, 24 Jun 2020 10:34:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E51C720CC7 for ; Wed, 24 Jun 2020 10:34:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390460AbgFXKeR (ORCPT ); Wed, 24 Jun 2020 06:34:17 -0400 Received: from foss.arm.com ([217.140.110.172]:59702 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388005AbgFXKeR (ORCPT ); Wed, 24 Jun 2020 06:34:17 -0400 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 96EF61FB; Wed, 24 Jun 2020 03:34:16 -0700 (PDT) Received: from arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 62DE83F6CF; Wed, 24 Jun 2020 03:34:15 -0700 (PDT) Date: Wed, 24 Jun 2020 11:34:13 +0100 From: Dave Martin To: Catalin Marinas Cc: Peter Maydell , Marc Zyngier , lkml - Kernel Mailing List , Steven Price , kvmarm@lists.cs.columbia.edu, Thomas Gleixner , Will Deacon , arm-mail-list Subject: Re: [RFC PATCH 0/2] MTE support for KVM guest Message-ID: <20200624103412.GD25945@arm.com> References: <20200617123844.29960-1-steven.price@arm.com> <20200624093846.GA11863@gaia> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200624093846.GA11863@gaia> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 24, 2020 at 10:38:48AM +0100, Catalin Marinas wrote: > On Tue, Jun 23, 2020 at 07:05:07PM +0100, Peter Maydell wrote: > > On Wed, 17 Jun 2020 at 13:39, Steven Price wrote: > > > These patches add support to KVM to enable MTE within a guest. It is > > > based on Catalin's v4 MTE user space series[1]. > > > > > > [1] http://lkml.kernel.org/r/20200515171612.1020-1-catalin.marinas%40arm.com > > > > > > Posting as an RFC as I'd like feedback on the approach taken. > > > > What's your plan for handling tags across VM migration? > > Will the kernel expose the tag ram to userspace so we > > can copy it from the source machine to the destination > > at the same time as we copy the actual ram contents ? > > Qemu can map the guest memory with PROT_MTE and access the tags directly > with LDG/STG instructions. Steven was actually asking in the cover > letter whether we should require that the VMM maps the guest memory with > PROT_MTE as a guarantee that it can access the guest tags. > > There is no architecturally visible tag ram (tag storage), that's a > microarchitecture detail. If userspace maps the guest memory with PROT_MTE for dump purposes, isn't it going to get tag check faults when accessing the memory (i.e., when dumping the regular memory content, not the tags specifically). Does it need to map two aliases, one with PROT_MTE and one without, and is that architecturally valid? Cheers ---Dave