Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp4142602ybl; Mon, 13 Jan 2020 08:32:52 -0800 (PST) X-Google-Smtp-Source: APXvYqzXRBRe5IxlqJ3+qkme29NbkkZeqc+lS5BeFVK1T3IAnuWPF4eUSPH1LeMzPI6kfCN3cy7u X-Received: by 2002:a9d:6f82:: with SMTP id h2mr13434845otq.69.1578933172853; Mon, 13 Jan 2020 08:32:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1578933172; cv=none; d=google.com; s=arc-20160816; b=Pplx9xdtUV5R3WG1kCWqfa0Z9apKLdu06LjZeRzNEGk/yWD36o9zMAUIDGMLedzo3Y MtaLFRznumC2eJzxWNM7jU4urN8AcOOCMM7UR/fXZARJ1VHTnV0l38DoU/wJCpr5LtpP SPuToJFDdF0AvOzwhdvXRr4+d1ASQfqmDNUZHHfqKtELYlR1j+6hz9WGl3pYD4We74Gi 2BK7S6pcsKLGYU84OA1H5JyaHmSBQi2MfdwqVjGKXSqC2SDcEnofv9rmlL3OWC2BN95G CVgsvoaqw40XFmSQ/kZCzXjW3sl9UrcXazyYg/gHpbh5EyoOMJCKXWVdhSYgCzzhPiIH jmGg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=xRTTch1AiWid/zzkz344hzmB84RgvoMxT7J6RVLrM7A=; b=keQy+NuzqX26470A2XydEMGujtTVgP5SW5zG6kvnXAMw5NPnZJ0CkSefv86URqL9ag NmB5l6MQE2WnyoT5fodDEPpZeYXouzungnQL6ZmEIUekZoJGI9JWJpMEeRZrGHR4+ncg EcSCJnxXCs4vsKT17QqAPQZg0lPqsSpkqMLe75PUAKbfQotZnYgrhJq1uaNXpXHQ08yM ugHA+96dx6VlcxZ+6Jn5AclO1cErdw5xKVRwgJJjQbu1DTqmmkYbS3xrLz7soxSclECM hKxbtAwt2gOyQfpSIhfqOUyPisK2exv1ScvjIIxVwQ2WJgqgvh7SdpjBDHlcbAXqOwmi rF2A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 30si6742737otr.75.2020.01.13.08.32.39; Mon, 13 Jan 2020 08:32:52 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728957AbgAMQbm (ORCPT + 99 others); Mon, 13 Jan 2020 11:31:42 -0500 Received: from foss.arm.com ([217.140.110.172]:41536 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726567AbgAMQbl (ORCPT ); Mon, 13 Jan 2020 11:31:41 -0500 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 3EC1011B3; Mon, 13 Jan 2020 08:31:41 -0800 (PST) Received: from localhost (unknown [10.37.6.20]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A69683F534; Mon, 13 Jan 2020 08:31:40 -0800 (PST) Date: Mon, 13 Jan 2020 16:31:38 +0000 From: Andrew Murray To: Marc Zyngier Cc: Catalin Marinas , Will Deacon , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Sudeep Holla , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v2 10/18] arm64: KVM/debug: use EL1&0 stage 1 translation regime Message-ID: <20200113163138.GP42593@e119886-lin.cambridge.arm.com> References: <20191220143025.33853-1-andrew.murray@arm.com> <20191220143025.33853-11-andrew.murray@arm.com> <86d0cgir74.wl-maz@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86d0cgir74.wl-maz@kernel.org> User-Agent: Mutt/1.10.1+81 (426a6c1) (2018-08-26) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Dec 22, 2019 at 10:34:55AM +0000, Marc Zyngier wrote: > On Fri, 20 Dec 2019 14:30:17 +0000, > Andrew Murray wrote: > > > > From: Sudeep Holla > > > > Now that we have all the save/restore mechanism in place, lets enable > > the translation regime used by buffer from EL2 stage 1 to EL1 stage 1 > > on VHE systems. > > > > Signed-off-by: Sudeep Holla > > [ Reword commit, don't trap to EL2 ] > > Not trapping to EL2 for the case where we don't allow SPE in the > guest is not acceptable. > > > Signed-off-by: Andrew Murray > > --- > > arch/arm64/kvm/hyp/switch.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c > > index 67b7c160f65b..6c153b79829b 100644 > > --- a/arch/arm64/kvm/hyp/switch.c > > +++ b/arch/arm64/kvm/hyp/switch.c > > @@ -100,6 +100,7 @@ static void activate_traps_vhe(struct kvm_vcpu *vcpu) > > > > write_sysreg(val, cpacr_el1); > > > > + write_sysreg(vcpu->arch.mdcr_el2 | 3 << MDCR_EL2_E2PB_SHIFT, mdcr_el2); > > write_sysreg(kvm_get_hyp_vector(), vbar_el1); > > } > > NOKPROBE_SYMBOL(activate_traps_vhe); > > @@ -117,6 +118,7 @@ static void __hyp_text __activate_traps_nvhe(struct kvm_vcpu *vcpu) > > __activate_traps_fpsimd32(vcpu); > > } > > > > + write_sysreg(vcpu->arch.mdcr_el2 | 3 << MDCR_EL2_E2PB_SHIFT, mdcr_el2); > > There is a _MASK macro that can replace this '3', and is in keeping > with the rest of the code. > > It still remains that it looks like the wrong place to do this, and > vcpu_load seems much better. Why should you write to mdcr_el2 on each > entry to the guest, since you know whether it has SPE enabled at the > point where it gets scheduled? For nVHE, the only reason we'd want to change E2PB on entry/exit of guest would be if the host is also using SPE. If the host is using SPE whilst the vcpu is 'loaded' but we're not in the guest, then host SPE could raise an interrupt - we need the E2PB bits to allow access from EL1 (host). Thanks, Andrew Murray > > M. > > -- > Jazz is not dead, it just smells funny.