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=-10.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 8C96EC4361A for ; Thu, 3 Dec 2020 17:00:36 +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 08DDF207A4 for ; Thu, 3 Dec 2020 17:00:35 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 08DDF207A4 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=m5GT4/EU4XFwVuW8gNLh80gfZbrKz+Swo2dcS/1EQso=; b=NkeJgU82ADc2Q15QjvQ7LPdPH LrVU4BCfTGj+yZvlpN4uYk36O9SsoV0127md8gT8HLwtzTeebk7sZqtMbLBWYUP3DCXKvGtuMqES9 7D+MZe+Kz1enfKleDhDe37UbzJjKej21Zw1JyxhMK9pYRqImHwR55Uy3ATFZRGuDW2At32Kc94wKp 8AR2mQ7miKipD4tD+3sRz74Z3EEysraGdx3fJky7emXZ075ictiTjJlBnVWcYJXWPAXvd1/7Ys5Ed vFgckv0dHBd0q9bzu4zbRWVEchM4ymUd6zr35X/1ncc820rf8XYhzm+mGKITz5+alenRnVMEGcqWi 6FMiYXFIA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kkrwh-00028B-Mf; Thu, 03 Dec 2020 16:59:07 +0000 Received: from foss.arm.com ([217.140.110.172]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kkrwe-00027r-Lh for linux-arm-kernel@lists.infradead.org; Thu, 03 Dec 2020 16:59:05 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 24ADA11D4; Thu, 3 Dec 2020 08:59:03 -0800 (PST) Received: from C02TD0UTHF1T.local (unknown [10.57.0.87]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 495BC3F575; Thu, 3 Dec 2020 08:59:00 -0800 (PST) Date: Thu, 3 Dec 2020 16:58:56 +0000 From: Mark Rutland To: Steven Price Subject: Re: [PATCH v6 0/2] MTE support for KVM guest Message-ID: <20201203165856.GH96754@C02TD0UTHF1T.local> References: <20201127152113.13099-1-steven.price@arm.com> <20201203160943.GG96754@C02TD0UTHF1T.local> <77e65f06-563b-3b30-ab36-9670e8cc03a4@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <77e65f06-563b-3b30-ab36-9670e8cc03a4@arm.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201203_115904_834622_C450431E X-CRM114-Status: GOOD ( 29.00 ) 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 , "Dr. David Alan Gilbert" , Andrew Jones , Haibo Xu , Suzuki K Poulose , qemu-devel@nongnu.org, Catalin Marinas , Juan Quintela , Richard Henderson , linux-kernel@vger.kernel.org, Dave Martin , James Morse , linux-arm-kernel@lists.infradead.org, Marc Zyngier , Thomas Gleixner , Will Deacon , kvmarm@lists.cs.columbia.edu, Julien Thierry 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 Thu, Dec 03, 2020 at 04:49:49PM +0000, Steven Price wrote: > On 03/12/2020 16:09, Mark Rutland wrote: > > On Fri, Nov 27, 2020 at 03:21:11PM +0000, Steven Price wrote: > > > It's been a week, and I think the comments on v5 made it clear that > > > enforcing PROT_MTE requirements on the VMM was probably the wrong > > > approach. So since I've got swap working correctly without that I > > > thought I'd post a v6 which hopefully addresses all the comments so far. > > > > > > This series adds support for Arm's Memory Tagging Extension (MTE) to > > > KVM, allowing KVM guests to make use of it. This builds on the existing > > > user space support already in v5.10-rc4, see [1] for an overview. > > > > > arch/arm64/include/asm/kvm_emulate.h | 3 +++ > > > arch/arm64/include/asm/kvm_host.h | 8 ++++++++ > > > arch/arm64/include/asm/pgtable.h | 2 +- > > > arch/arm64/include/asm/sysreg.h | 3 ++- > > > arch/arm64/kernel/mte.c | 18 +++++++++++++----- > > > arch/arm64/kvm/arm.c | 9 +++++++++ > > > arch/arm64/kvm/hyp/include/hyp/sysreg-sr.h | 14 ++++++++++++++ > > > arch/arm64/kvm/mmu.c | 16 ++++++++++++++++ > > > arch/arm64/kvm/sys_regs.c | 20 +++++++++++++++----- > > > include/uapi/linux/kvm.h | 1 + > > > 10 files changed, 82 insertions(+), 12 deletions(-) > > > > I note that doesn't fixup arch/arm64/kvm/inject_fault.c, where in > > enter_exception64() we have: > > > > | // TODO: TCO (if/when ARMv8.5-MemTag is exposed to guests) > > > > ... and IIUC when MTE is present, TCO should be set when delivering an > > exception, so I believe that needs to be updated to set TCO. > > Well spotted! As you say TCO should be set when delivering an exception, so > we need the following: > > - // TODO: TCO (if/when ARMv8.5-MemTag is exposed to guests) > + if (kvm_has_mte(vcpu->kvm)) > + new |= PSR_TCO_BIT; Something of that sort, yes. It'd be worth a look for any mention of TCO or MTE in case there are other bits that need a fixup. > > Given that MTE-capable HW does that unconditionally, this is going to be > > a mess for big.LITTLE. :/ > > I'm not sure I follow. Either all CPUs support MTE in which this isn't a > problem, or the MTE feature just isn't exposed. We don't support a mix of > MTE and non-MTE CPUs. There are several aspects of MTE which effective mean > it's an all-or-nothing feature for the system. So long as the host requires uniform MTE support, I agree that's not a problem. The fun is that the CPUs themselves will set TCO upon a real exception regardless of whether the host is aware, and on a mismatched system some CPUs will do that while others will not. In such a case the host and guest will end up seeing the SPSR TCO bit set sometimes upon exceptions from EL1 or EL2, and I hope that MTE-unaware CPUs ignore the bit upon ERET, or we're going to have significant problems. Thanks, Mark. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel