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=-5.2 required=3.0 tests=BAYES_00,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 E32D7C4361B for ; Wed, 9 Dec 2020 18:41: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 64B8B22B4B for ; Wed, 9 Dec 2020 18:41:00 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 64B8B22B4B Authentication-Results: mail.kernel.org; dmarc=fail (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=GHrY8GDZoV4MBD6O4EvjxC0FYCfzxt0Utbv+WghxWlU=; b=WedplgThYm1riWgKvRhqbk/HK RxUirM/4/tU3DgqQ7EIyrOgLgpQNR6zyfx6KpUm5RQvyFcZtm0Xye5edRNrr/42IYLiGmAsb+Fz1c mAnIaxUiIFM0B5DM+tSHKz7iUyWa59MXjHvnPsss6RYp/+uoSedFm+o9mXqLPlVDLkakesEAc933/ 1eSBIBG4x/VQcQ1pZ/cRE4a1MHio3lS5ETQMTXADd127Sjir0btzzceGyvmbo/IiAq1pp2J5a+QDY qkK6ubp9maTwdNJxlyNKJuow+QDPjVNKlH0SgNCHvphLDyCNUWd6gBIJVJziYzfjOIsFQqciieJr8 TOsskqHtg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kn4N7-0007Df-A9; Wed, 09 Dec 2020 18:39:29 +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 1kn4N4-0007DA-2W for linux-arm-kernel@lists.infradead.org; Wed, 09 Dec 2020 18:39:26 +0000 Date: Wed, 9 Dec 2020 18:39:20 +0000 From: Catalin Marinas To: Richard Henderson Subject: Re: [PATCH v5 0/2] MTE support for KVM guest Message-ID: <20201209183920.GI13566@gaia> References: <0d0eb6da6a11f76d10e532c157181985@kernel.org> <20201207163405.GD1526@gaia> <874kkx5thq.wl-maz@kernel.org> <20201208172143.GB13960@gaia> <7ff14490e253878d0735633b792e1ea9@kernel.org> <20201209124443.GB13566@gaia> <20201209152741.GC13566@gaia> <8c39b104-39c3-7cca-82b9-2e47d7cb9a9a@linaro.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <8c39b104-39c3-7cca-82b9-2e47d7cb9a9a@linaro.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201209_133926_194479_1888A491 X-CRM114-Status: GOOD ( 19.98 ) 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 , Marc Zyngier , lkml - Kernel Mailing List , Steven Price , arm-mail-list , Haibo Xu , Thomas Gleixner , Will Deacon , kvmarm , "Dr. David Alan Gilbert" , Dave Martin 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, Dec 09, 2020 at 12:27:59PM -0600, Richard Henderson wrote: > On 12/9/20 9:27 AM, Catalin Marinas wrote: > > On Wed, Dec 09, 2020 at 01:25:18PM +0000, Marc Zyngier wrote: > >> Would this syscall operate on the guest address space? Or on the VMM's > >> own mapping? > ... > > Whatever is easier for the VMM, I don't think it matters as long as the > > host kernel can get the actual physical address (and linear map > > correspondent). Maybe simpler if it's the VMM address space as the > > kernel can check the access permissions in case you want to hide the > > guest memory from the VMM for other reasons (migration is also off the > > table). > > Indeed, such a syscall is no longer specific to vmm's and may be used for any > bulk move of tags that userland might want. For CRIU, I think the current ptrace interface would do. With VMMs, the same remote VM model doesn't apply (the "remote" VM is actually the guest memory). I'd keep this under a KVM ioctl() number rather than a new, specific syscall. > > Without syscalls, an option would be for the VMM to create two mappings: > > one with PROT_MTE for migration and the other without for normal DMA > > etc. That's achievable using memfd_create() or shm_open() and two mmap() > > calls, only one having PROT_MTE. The VMM address space should be > > sufficiently large to map two guest IPAs. > > I would have thought that the best way is to use TCO, so that we don't have to > have dual mappings (and however many MB of extra page tables that might imply). The problem appears when the VMM wants to use MTE itself (e.g. linked against an MTE-aware glibc), toggling TCO is no longer generic enough, especially when it comes to device emulation. -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel