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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 49ADCC3DA64 for ; Wed, 31 Jul 2024 09:53:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=rg+I/9+wk3j3iFMU9KY0tBFPPps0Y6HB5AX1tMmY23U=; b=h12HPnsuZsLlhUsG47cT5sXotw 1ROfSSSQNMiSNFs0E7md0hse9Nwykcthd/Uz2cNficvX39wgrNOd9lHjGq3qCUEG+V4FdNwFvur0P 5CUDraK2V0x2LLE+tGVGW7PtzVvTzvea07IrcH5eNXbQESQerHLRUBm/Y7JOS73jebJXQ5ndEhNTD 53kdLE59Q+D9e0qW5UtaThK6XMT/AYktGvc+iGYqTanwlAZewRNdTvI4hpQG4/64MG5EkQ6o+Fhll Pr61hsVe8AW8JRJb6NGcCYTY0jssMdcH8gyXs381SjqVF9PTE3hkkVpmTUezm+AUHXTuEOokK4gq1 T6qaGCWA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sZ61m-00000000d3w-1d2r; Wed, 31 Jul 2024 09:53:50 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sZ61J-00000000cud-3lRB for linux-arm-kernel@lists.infradead.org; Wed, 31 Jul 2024 09:53:23 +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 CD5831007; Wed, 31 Jul 2024 02:53:44 -0700 (PDT) Received: from raptor (usa-sjc-mx-foss1.foss.arm.com [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 7C40C3F5A1; Wed, 31 Jul 2024 02:53:17 -0700 (PDT) Date: Wed, 31 Jul 2024 10:53:14 +0100 From: Alexandru Elisei To: Marc Zyngier Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, James Morse , Suzuki K Poulose , Oliver Upton , Zenghui Yu , Joey Gouly Subject: Re: [PATCH 10/12] KVM: arm64: nv: Add SW walker for AT S1 emulation Message-ID: References: <20240625133508.259829-1-maz@kernel.org> <20240708165800.1220065-1-maz@kernel.org> <86v80m0wlb.wl-maz@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86v80m0wlb.wl-maz@kernel.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240731_025322_059984_F4347C3B X-CRM114-Status: GOOD ( 33.02 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi, On Wed, Jul 31, 2024 at 09:55:28AM +0100, Marc Zyngier wrote: > On Mon, 29 Jul 2024 16:26:00 +0100, > Alexandru Elisei wrote: > > > > Hi Marc, > > > > On Mon, Jul 08, 2024 at 05:57:58PM +0100, Marc Zyngier wrote: > > > In order to plug the brokenness of our current AT implementation, > > > we need a SW walker that is going to... err.. walk the S1 tables > > > and tell us what it finds. > > > > > > Of course, it builds on top of our S2 walker, and share similar > > > concepts. The beauty of it is that since it uses kvm_read_guest(), > > > it is able to bring back pages that have been otherwise evicted. > > > > > > This is then plugged in the two AT S1 emulation functions as > > > a "slow path" fallback. I'm not sure it is that slow, but hey. > > > > > > Signed-off-by: Marc Zyngier > > > --- > > > arch/arm64/kvm/at.c | 538 ++++++++++++++++++++++++++++++++++++++++++-- > > > 1 file changed, 520 insertions(+), 18 deletions(-) > > > > > > diff --git a/arch/arm64/kvm/at.c b/arch/arm64/kvm/at.c > > > index 71e3390b43b4c..8452273cbff6d 100644 > > > --- a/arch/arm64/kvm/at.c > > > +++ b/arch/arm64/kvm/at.c > > > @@ -4,9 +4,305 @@ > > > * Author: Jintack Lim > > > */ > > > > > > +#include > > > + > > > +#include > > > #include > > > #include > > > > > > +struct s1_walk_info { > > > + u64 baddr; > > > + unsigned int max_oa_bits; > > > + unsigned int pgshift; > > > + unsigned int txsz; > > > + int sl; > > > + bool hpd; > > > + bool be; > > > + bool nvhe; > > > + bool s2; > > > +}; > > > + > > > +struct s1_walk_result { > > > + union { > > > + struct { > > > + u64 desc; > > > + u64 pa; > > > + s8 level; > > > + u8 APTable; > > > + bool UXNTable; > > > + bool PXNTable; > > > + }; > > > + struct { > > > + u8 fst; > > > + bool ptw; > > > + bool s2; > > > + }; > > > + }; > > > + bool failed; > > > +}; > > > + > > > +static void fail_s1_walk(struct s1_walk_result *wr, u8 fst, bool ptw, bool s2) > > > +{ > > > + wr->fst = fst; > > > + wr->ptw = ptw; > > > + wr->s2 = s2; > > > + wr->failed = true; > > > +} > > > + > > > +#define S1_MMU_DISABLED (-127) > > > + > > > +static int setup_s1_walk(struct kvm_vcpu *vcpu, struct s1_walk_info *wi, > > > + struct s1_walk_result *wr, const u64 va, const int el) > > > +{ > > > + u64 sctlr, tcr, tg, ps, ia_bits, ttbr; > > > + unsigned int stride, x; > > > + bool va55, tbi; > > > + > > > + wi->nvhe = el == 2 && !vcpu_el2_e2h_is_set(vcpu); > > > > Where 'el' is computed in handle_at_slow() as: > > > > /* > > * We only get here from guest EL2, so the translation regime > > * AT applies to is solely defined by {E2H,TGE}. > > */ > > el = (vcpu_el2_e2h_is_set(vcpu) && > > vcpu_el2_tge_is_set(vcpu)) ? 2 : 1; > > > > I think 'nvhe' will always be false ('el' is 2 only when E2H is > > set). > > Yeah, there is a number of problems here. el should depend on both the > instruction (some are EL2-specific) and the HCR control bits. I'll > tackle that now. Yeah, also noticed that how sctlr, tcr and ttbr are chosen in setup_s1_walk() doesn't look quite right for the nvhe case. > > > I'm curious about what 'el' represents. The translation regime for the AT > > instruction? > > Exactly that. Might I make a suggestion here? I was thinking about dropping the (el, wi-nvhe*) tuple to represent the translation regime and have a wi->regime (or similar) to unambiguously encode the regime. The value can be an enum with three values to represent the three possible regimes (REGIME_EL10, REGIME_EL2, REGIME_EL20). Just a thought though, feel free to ignore at your leisure. *wi->single_range on the kvm-arm64/nv-at-pan-WIP branch. Thanks, Alex