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 3D586C433FE for ; Wed, 9 Dec 2020 15:29:16 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (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 DDFFC233F8 for ; Wed, 9 Dec 2020 15:29:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DDFFC233F8 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:36474 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kn1P1-0002lP-1L for qemu-devel@archiver.kernel.org; Wed, 09 Dec 2020 10:29:15 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:37896) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kn1Nh-000293-F5 for qemu-devel@nongnu.org; Wed, 09 Dec 2020 10:27:53 -0500 Received: from mail.kernel.org ([198.145.29.99]:39778) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kn1Ne-0000IW-K3 for qemu-devel@nongnu.org; Wed, 09 Dec 2020 10:27:52 -0500 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-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Received-SPF: pass client-ip=198.145.29.99; envelope-from=cmarinas@kernel.org; helo=mail.kernel.org X-Spam_score_int: -66 X-Spam_score: -6.7 X-Spam_bar: ------ X-Spam_report: (-6.7 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 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" Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" 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