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 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 926F8C433DF for ; Wed, 24 Jun 2020 10:34:22 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id 08F832082F for ; Wed, 24 Jun 2020 10:34:21 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 08F832082F Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvmarm-bounces@lists.cs.columbia.edu Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 6F49B4B155; Wed, 24 Jun 2020 06:34:21 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Km4Zets+VTsx; Wed, 24 Jun 2020 06:34:20 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 40DE64B157; Wed, 24 Jun 2020 06:34:20 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 545294B147 for ; Wed, 24 Jun 2020 06:34:18 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HqH92EMpVwBi for ; Wed, 24 Jun 2020 06:34:17 -0400 (EDT) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 15CDE4B13F for ; Wed, 24 Jun 2020 06:34:16 -0400 (EDT) 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 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-Disposition: inline In-Reply-To: <20200624093846.GA11863@gaia> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Marc Zyngier , lkml - Kernel Mailing List , Steven Price , Thomas Gleixner , Will Deacon , kvmarm@lists.cs.columbia.edu, arm-mail-list X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu 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 _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm 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=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,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 D3F1AC433E0 for ; Wed, 24 Jun 2020 10:36:07 +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 A1CB320644 for ; Wed, 24 Jun 2020 10:36:07 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="jYsZ8PCo" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A1CB320644 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com 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-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject: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=w+QWOVOi0Rul/Xu+m7dyq0WhrkAq5b1LnyT7FCrG3CQ=; b=jYsZ8PCo3js970/1V4pe9weUE pGjkTpvwEMyOXHn9XkmV7D/A9CKPEhkNLS/D7PO8Eifzzf+cCTLfh91vEN8vrEJ97klcBDF9PE5yE RxaEPtW924Y5QrDjQQ4J3qDw0ilprhp/DF+bwBnyWOY8XRUM6AtJR1XtggvDfaCxjzrYjPHfhmeOg sCey4u1td/5cNStyKV5S7aEvVYcaCUTV0n35Mp6Y3Sefe3/OlDxATmfMD/yjfTnXTjr3HOB0UoOky AYqhkuBEpvithr7o6kIfMYL8XXmYUYrO3m90Sqfwxk/taDDB+NlHEKtkzu7SXykZWXcGIb7SDxiop 2lwhWaRCA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jo2jU-00032z-Ai; Wed, 24 Jun 2020 10:34:20 +0000 Received: from foss.arm.com ([217.140.110.172]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jo2jR-000320-6Y for linux-arm-kernel@lists.infradead.org; Wed, 24 Jun 2020 10:34:18 +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 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 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-Disposition: inline In-Reply-To: <20200624093846.GA11863@gaia> User-Agent: Mutt/1.5.23 (2014-03-12) 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 , Marc Zyngier , lkml - Kernel Mailing List , Steven Price , Thomas Gleixner , Will Deacon , kvmarm@lists.cs.columbia.edu, arm-mail-list 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, 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel