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, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, 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 271C8C4167B for ; Wed, 9 Dec 2020 15:28:44 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E3DAF23AC4 for ; Wed, 9 Dec 2020 15:28:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730263AbgLIP2g (ORCPT ); Wed, 9 Dec 2020 10:28:36 -0500 Received: from mail.kernel.org ([198.145.29.99]:40734 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730205AbgLIP22 (ORCPT ); Wed, 9 Dec 2020 10:28:28 -0500 Date: Wed, 9 Dec 2020 15:27:41 +0000 From: Catalin Marinas To: Marc Zyngier Cc: Steven Price , Peter Maydell , Haibo Xu , lkml - Kernel Mailing List , Juan Quintela , Richard Henderson , QEMU Developers , "Dr. David Alan Gilbert" , Thomas Gleixner , Will Deacon , kvmarm , arm-mail-list , Dave Martin 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-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.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