Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp574846ybt; Wed, 24 Jun 2020 06:19:35 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyCKFsl3Rx94BR8zdgZqTwtqg902MmBkuYdsnswF+M1k41ABv2oDuRJ9D7qi4D3AaJwBFN6 X-Received: by 2002:a17:906:434f:: with SMTP id z15mr24462467ejm.178.1593004775439; Wed, 24 Jun 2020 06:19:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1593004775; cv=none; d=google.com; s=arc-20160816; b=pPtGwuy22ucCIDv08Z0iFu5/WyA/jI8hng27QXVXTZrSGiOUfYZkQHTKM/i/qIGaEu I/QeQxNuRVoTEULqYZ+so2uBsaFNyBumDnq0i8mdspmGVVHNHeryYwEadCqpqYqcgjaf zACSUaSy7kPh2+IJcTKWt/1x7kKzfbMNDgDQmYC8wW4Ag8UiKPv8HXjbFuU63e4c+mTY xtUpvvPVhe/Q7LPkwIxhnxu8JXTmumvuB3RMDNtmLHhndkS0lE2PuL1kiWLhFw2ypPFW WpHkc1opFaZt7mCIsk4tbeQBmq9amQHOR3vcRr6HqPKh7lg0Dm9UrXd9fYFsRfCxirs4 ffdw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=hrq4bU7gW/zMadgffXP6inYxHXZqoA5vMZOPEq8EPJg=; b=hto6ndxFkiHLYn+80hv8YT6WoaGoO4HFQJi3kkiOg2zMimzRQQ/SN5aw0cdjZFDj/f fdfjsA1OXe9eL7Uq9PAUaO1z412I+kUCZKmlSsggp5ma9w1WzYOKi8P5Zkbb9oI53abD uezoAf7PGsYY520cpJ9rHuN0Vx7xKs6Z43N8lWAf3TAYsYCL4Y5RccsZmdfsCGgmzpyw iq8WsOEMdkstiJt3O9oTo+PlEa+X4JseCg/EReczZYPVZcjU8Y+XLjEDOKBg2UVL0+qU MnwWk98LZosHe8IiS4Zd0D9oOjr/yD06ChilxdqNtoyAkFzK2h86WNfNcr0Ljpf6Eeku dxwQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=SNkQbmm6; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id oq5si4934353ejb.110.2020.06.24.06.19.12; Wed, 24 Jun 2020 06:19:35 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=SNkQbmm6; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388126AbgFXNQ4 (ORCPT + 99 others); Wed, 24 Jun 2020 09:16:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39194 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728794AbgFXNQz (ORCPT ); Wed, 24 Jun 2020 09:16:55 -0400 Received: from mail-oi1-x241.google.com (mail-oi1-x241.google.com [IPv6:2607:f8b0:4864:20::241]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1B86EC061573 for ; Wed, 24 Jun 2020 06:16:53 -0700 (PDT) Received: by mail-oi1-x241.google.com with SMTP id s10so1542617oih.10 for ; Wed, 24 Jun 2020 06:16:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hrq4bU7gW/zMadgffXP6inYxHXZqoA5vMZOPEq8EPJg=; b=SNkQbmm6GBRU2KhBaTQKfcfmn3IqVyo1IEsawGEMXu1m/zaaJfewRLW+JgQxzyNplo PMxdiHAHUJj1jcLrCJu0EMigY/jpaqGRCjn9eKfBNn9ASxC662tvzS+E+WsmVKZ3s9t6 NrRZIGxw9m88UnZv/NKxQWD5/cTP5KjXmezEvqgj+jMn3++GyHopD3hTboMCLUQVqj5/ UMP41AzRmIsaMtAw6crTx5unAExkCuX3t+OXDZpMJKrjD9+bLYiMdGeEtS7Xq5lDB1sS xprDV5SPobMBnB9pS/vy+Vaf9C1Pruluatlv2PWS/VaTGPus5vwEvqkJyBc64kFKRbIy QHow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hrq4bU7gW/zMadgffXP6inYxHXZqoA5vMZOPEq8EPJg=; b=X09C70BlCQr3PjjjBQzaAAiBATrGw7k7s+GEMaRdmPAQOlbHwDuepZ5xEcToKEubsn 45FAO93sjA1HPiFww5ea7P2QYmlUWTL9cOJ8qscvUP6azqQJPqI9MiK02UvsIkgVt7n5 CHNHqrJRx+FjUoZx4Pbbst4769X8P+YIe3FDN/afKGZcL+ttGQeqUC+a3nLnkpoNgTHx xc3uVY2AARSA6nNarIRpVLWf7/vnEtX4MLeTqdAMVStpvL4xFy1fiKtIce8IxKY+BGKI M+cqYQXphmAlZmPQDqqyXORnWQhwjz6pQk5r59X9ck4awMfYkKJ8NS6db42kmA0YAUkO AlJw== X-Gm-Message-State: AOAM530QuCQFPyKuNf9R2ijZUOUKdg0iIOHMlrVEXvxsSFH3DSXL2OgQ i5hmxVzFuxGZSDnSqwEFpeRbweogeq5iVa08DYMysQ== X-Received: by 2002:a54:4694:: with SMTP id k20mr4411799oic.146.1593004612263; Wed, 24 Jun 2020 06:16:52 -0700 (PDT) MIME-Version: 1.0 References: <20200617123844.29960-1-steven.price@arm.com> <20200624093846.GA11863@gaia> <20200624103412.GD25945@arm.com> <20200624110904.GB11863@gaia> <904edac0-3de7-35a6-a9bc-b983ccd3490c@arm.com> In-Reply-To: <904edac0-3de7-35a6-a9bc-b983ccd3490c@arm.com> From: Peter Maydell Date: Wed, 24 Jun 2020 14:16:41 +0100 Message-ID: Subject: Re: [RFC PATCH 0/2] MTE support for KVM guest To: Steven Price Cc: Catalin Marinas , Dave P Martin , Marc Zyngier , lkml - Kernel Mailing List , "kvmarm@lists.cs.columbia.edu" , Thomas Gleixner , Will Deacon , arm-mail-list Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 24 Jun 2020 at 12:18, Steven Price wrote: > Ah yes, similar to (1) but much lower overhead ;) That's probably the > best option - it can be hidden in a memcpy_ignoring_tags() function. > However it still means that the VMM can't directly touch the guest's > memory which might cause issues for the VMM. That's kind of awkward, since in general QEMU assumes it can naturally just access guest RAM[*] (eg emulation of DMAing devices, virtio, graphics display, gdb stub memory accesses). It would be nicer to be able to do it the other way around, maybe, so that the current APIs give you the "just the memory" and if you really want to do tagged accesses to guest ram you can do it with tag-specific APIs. I haven't thought about this very much though and haven't read enough of the MTE spec recently enough to make much sensible comment. So mostly what I'm trying to encourage here is that the people implementing the KVM/kernel side of this API also think about the userspace side of it, so we get one coherent design rather than a half-a-product that turns out to be awkward to use :-) [*] "guest ram is encrypted" also breaks this assumption, of course; I haven't looked at the efforts in that direction that are already in QEMU to see how they work, though. thanks -- PMM