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 5E59FC433FE for ; Wed, 9 Dec 2020 15:28:59 +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 1EFE3233F8 for ; Wed, 9 Dec 2020 15:28:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1EFE3233F8 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=QMHurI6t15/LhtyDrLois0HbcmyXuS8FjpJCLJkEzj4=; b=syh6nJb1ukeM2lbFGoXkAH6gh a8idwfIiQbZVaAGxyxKNSsiIO3JxKSW070IRvO/PEpqpqGoO6AmOZLofXkhbcqbTCLhJmu8/+rQ36 fiYZaloF3wSR1UiyRh9JwtAK7olQ2aXEo9NR5LytKbIKdhrMv2+awTQNlHUFFXQmy+aZnto3aXESM R0Eb58I5MKrd/l7DddLUSQFx1E6IXu3fpWjIkCtXCb5TeUTo9JGjE7sSQZSPDOAibvQGtCBfb9vz0 JYFhBuzCQs8mECJjBn26PJjzDwyfC866+alWT7rPuR6oiVKGpxwD/tBItZVjCYHDSdz5B7sZi1ezz g35UVeV8A==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kn1Nf-00048H-2J; Wed, 09 Dec 2020 15:27:51 +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 1kn1Nb-00046q-0D for linux-arm-kernel@lists.infradead.org; Wed, 09 Dec 2020 15:27:48 +0000 Date: Wed, 9 Dec 2020 15:27:41 +0000 From: Catalin Marinas To: Marc Zyngier Subject: Re: [PATCH v5 0/2] MTE support for KVM guest Message-ID: <20201209152741.GC13566@gaia> References: <46fd98a2-ee39-0086-9159-b38c406935ab@arm.com> <0d0eb6da6a11f76d10e532c157181985@kernel.org> <20201207163405.GD1526@gaia> <874kkx5thq.wl-maz@kernel.org> <20201208172143.GB13960@gaia> <7ff14490e253878d0735633b792e1ea9@kernel.org> <20201209124443.GB13566@gaia> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: 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_102747_209084_B88229E8 X-CRM114-Status: GOOD ( 25.68 ) 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-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 01:25:18PM +0000, Marc Zyngier wrote: > On 2020-12-09 12:44, Catalin Marinas wrote: > > On Tue, Dec 08, 2020 at 06:21:12PM +0000, Marc Zyngier wrote: > > > On 2020-12-08 17:21, Catalin Marinas wrote: > > > > On Mon, Dec 07, 2020 at 07:03:13PM +0000, Marc Zyngier wrote: > > > > > 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. > > > > From the VMM perspective, the tags can be treated just like additional > > (meta)data in a page. We'd only need the tags when copying over. It can > > race with the VM dirtying the page (writing tags would dirty it) but I > > don't think the current migration code cares about this. If dirtied, it > > copies it again. > > > > The only downside I see is an extra syscall per page both on the origin > > VMM and the destination one to dump/restore the tags. Is this a > > performance issue? > > I'm not sure. Migrating VMs already has a massive overhead, so an extra > syscall per page isn't terrifying. But that's the point where I admit > not knowing enough about what the VMM expects, nor whether that matches > what happens on other architectures that deal with per-page metadata. > > 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). 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. -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel