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=-7.7 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=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 DA4BDC433DF for ; Tue, 25 Aug 2020 10:56:16 +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 A0E2B2068E for ; Tue, 25 Aug 2020 10:56:16 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="z1ctEb/f" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A0E2B2068E Authentication-Results: mail.kernel.org; dmarc=none (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=i+oChFsoWUq65a0XufqbjhR4ZUWVISYaTYGuJHuq048=; b=z1ctEb/f2gkuA75q4GV05BzUo ozt6prk6He7/llBMSN4JQX1pf9zKLkMX8xJzaZdDmak4KEv2RNerNhNMUZnO1Ri22tX22E3YeXGWg 3+vUYcA8ywR+Hlg0fkB+c3ldj48kXi7MaKNJFhvUMZW99HGMMRVFs4+wSZZpaXC1JBTDxlZI8lcJI eBE69btYkg6i9vpKCGLthe6nQ/XI1Bj7vhpPp9mzGTL/bMefFFcZzgQTYta1HxvLr8YzhyGC+HF25 E4mI4Yrl4awGgNr9fJr3Z0pIWD3lzAZbquPqj08VyyZKD4zNX2O+c5mYgDAO1mWgK+zptLLYjey6P 9T6z120SQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kAWbW-00089q-Gm; Tue, 25 Aug 2020 10:55:02 +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 1kAWbU-00089B-1K for linux-arm-kernel@lists.infradead.org; Tue, 25 Aug 2020 10:55:00 +0000 Received: from C02TF0J2HF1T.local (unknown [213.205.240.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id ECA0F2068E; Tue, 25 Aug 2020 10:54:53 +0000 (UTC) Date: Tue, 25 Aug 2020 11:54:50 +0100 From: Catalin Marinas To: Marc Zyngier Subject: Re: [PATCH v8 03/28] arm64: mte: CPU feature detection and initial sysreg configuration Message-ID: <20200825105450.GA22233@C02TF0J2HF1T.local> References: <20200824182758.27267-1-catalin.marinas@arm.com> <20200824182758.27267-4-catalin.marinas@arm.com> <61bba3c1948651a5221b87f2dfa2872f@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <61bba3c1948651a5221b87f2dfa2872f@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200825_065500_171215_9AAEEC52 X-CRM114-Status: GOOD ( 21.07 ) 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: linux-arch@vger.kernel.org, Suzuki K Poulose , Szabolcs Nagy , Andrey Konovalov , Kevin Brodsky , Peter Collingbourne , linux-mm@kvack.org, Andrew Morton , Vincenzo Frascino , Will Deacon , Dave P Martin , linux-arm-kernel@lists.infradead.org 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 Tue, Aug 25, 2020 at 09:53:16AM +0100, Marc Zyngier wrote: > On 2020-08-24 19:27, Catalin Marinas wrote: > > diff --git a/arch/arm64/include/asm/kvm_arm.h > > b/arch/arm64/include/asm/kvm_arm.h > > index 8a1cbfd544d6..6c3b2fc922bb 100644 > > --- a/arch/arm64/include/asm/kvm_arm.h > > +++ b/arch/arm64/include/asm/kvm_arm.h > > @@ -78,7 +78,7 @@ > > HCR_AMO | HCR_SWIO | HCR_TIDCP | HCR_RW | HCR_TLOR | \ > > HCR_FMO | HCR_IMO) > > #define HCR_VIRT_EXCP_MASK (HCR_VSE | HCR_VI | HCR_VF) > > -#define HCR_HOST_NVHE_FLAGS (HCR_RW | HCR_API | HCR_APK) > > +#define HCR_HOST_NVHE_FLAGS (HCR_RW | HCR_API | HCR_APK | HCR_ATA) > > #define HCR_HOST_VHE_FLAGS (HCR_RW | HCR_TGE | HCR_E2H) > > Why is HCR_ATA only set for nVHE? HCR_EL2.ATA seems to apply to both, > doesn't it? We need HCR_EL2.ATA to be set when !VHE so that the host kernel can use MTE. That said, I think we need to turn it off when running a guest. Even if we hide the ID register, the guest may still attempt to enable tags on some memory that doesn't support it, leading to unpredictable behaviour (well, only if we expose device memory to guests directly; Steve's patches will deal with this but for now we just disable MTE in guests). With VHE, HCR_EL2.ATA only affects the guests, so it can stay off. The host's use of tags is controlled by SCTLR_EL1/EL2.ATA (i.e. HCR_EL2.ATA has no effect if E2H and TGE are both 1; qemu has a bug here which I discovered yesterday). > > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c > > index 077293b5115f..59b91f58efec 100644 > > --- a/arch/arm64/kvm/sys_regs.c > > +++ b/arch/arm64/kvm/sys_regs.c > > @@ -1131,6 +1131,8 @@ static u64 read_id_reg(const struct kvm_vcpu > > *vcpu, > > if (!vcpu_has_sve(vcpu)) > > val &= ~(0xfUL << ID_AA64PFR0_SVE_SHIFT); > > val &= ~(0xfUL << ID_AA64PFR0_AMU_SHIFT); > > + } else if (id == SYS_ID_AA64PFR1_EL1) { > > + val &= ~(0xfUL << ID_AA64PFR1_MTE_SHIFT); > > Hiding the capability is fine, but where is the handling of trapping > instructions done? They should result in an UNDEF being injected. They are a few new MTE-specific MSR/MRS which are trapped at EL2 but since KVM doesn't understand them yet, shouldn't it already inject undef back at EL1? That would be safer regardless of MTE support. -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel