From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4D9482A1CF; Fri, 16 Aug 2024 10:37:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1723804647; cv=none; b=BQvxVebOnF2xSJk1KifB4O1Mqmnf5MHfMGwcY3B4uPQ1P3LfCsGqCZerkxMmuJCfa+EHdC4Ru708zPByUGo/s/UEFiMsm3ao4JVSpQa2KJk1y1MEwB9cg+pEp0p4hagvozSgrfuPnZvv53FCWmccaQYzzWt+kdhcL7Y3V0RY2a0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1723804647; c=relaxed/simple; bh=2SqZBMShpMFdkkFGruZbe4h3zcLtotowYjTioO8i3yM=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=ka1CLvTsrtdvxXfHrDrGGI3SxtI+8cNGxAuMM/Z+Cqqlso5dUu0KaReNpmgAIEdtTG9ih9+NvT4EHKQvm5hGrmWpiMQsIcanxEJguY6rMYdC8nyTu+ERVBrlPEWqV0MxmEs3FmhfuJq5t4wTjOU03euSTwZEg5lHnzrpdu4ejAw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=tGQVcvR3; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="tGQVcvR3" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B815FC32782; Fri, 16 Aug 2024 10:37:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1723804646; bh=2SqZBMShpMFdkkFGruZbe4h3zcLtotowYjTioO8i3yM=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=tGQVcvR3u7AfkW6fQ+jSzSqX7zvmBOQiyr1pM/fXBxX6nIWseFYBGENVy095A2zYq WN1DfblC/XVYZVa8ge/Tvv/Io5o/HV2rvgwj0B+iLpyKUaDsvagYuK/KuwCmROxy5x 2Y5jINgNQ7y9zdVPwaHT0gTx1D1uxqP13KfzY7TKQKxTsNo14mV2XaNsdt+g3Gumyh Ma2WmXzy9GW72udh64WQP4/MWjpXyL5vtYc7OvqkFvGC8Y3ZbLsbRAPpSmIIaj3/fY BR26v40/4xJPTDpofRJ/2mAZs2exrsWFICFevXaLFbhbuMe82mljOzuY9yJbUMsHKx U7Jw/uqevTskQ== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1seuKi-004FDh-GX; Fri, 16 Aug 2024 11:37:24 +0100 Date: Fri, 16 Aug 2024 11:37:24 +0100 Message-ID: <86le0wzrbv.wl-maz@kernel.org> From: Marc Zyngier To: Alexandru Elisei 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 , Anshuman Khandual , Przemyslaw Gaj Subject: Re: [PATCH v3 14/18] KVM: arm64: nv: Add SW walker for AT S1 emulation In-Reply-To: References: <20240813100540.1955263-1-maz@kernel.org> <20240813100540.1955263-15-maz@kernel.org> <86msldzlly.wl-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/29.4 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: alexandru.elisei@arm.com, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, james.morse@arm.com, suzuki.poulose@arm.com, oliver.upton@linux.dev, yuzenghui@huawei.com, joey.gouly@arm.com, anshuman.khandual@arm.com, pgaj@cadence.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Hi Alex, On Fri, 16 Aug 2024 10:22:43 +0100, Alexandru Elisei wrote: >=20 > Hi Marc, >=20 > On Thu, Aug 15, 2024 at 07:28:41PM +0100, Marc Zyngier wrote: > >=20 > > Hi Alex, > >=20 > > On Thu, 15 Aug 2024 17:44:02 +0100, > > Alexandru Elisei wrote: [...] > > > > +static bool par_check_s1_perm_fault(u64 par) > > > > +{ > > > > + u8 fst =3D FIELD_GET(SYS_PAR_EL1_FST, par); > > > > + > > > > + return ((fst & ESR_ELx_FSC_TYPE) =3D=3D ESR_ELx_FSC_PERM && > > > > + !(par & SYS_PAR_EL1_S)); > > >=20 > > > ESR_ELx_FSC_PERM =3D 0x0c is a permission fault, level 0, which Arm A= RM says can > > > only happen when FEAT_LPA2. I think the code should check that the va= lue for > > > PAR_EL1.FST is in the interval (ESR_ELx_FSC_PERM_L(0), ESR_ELx_FSC_PE= RM_L(3)]. > >=20 > > I honestly don't want to second-guess the HW. If it reports something > > that is the wrong level, why should we trust the FSC at all? >=20 > Sorry, I should have been clearer. >=20 > It's not about the hardware reporting a fault on level 0 of the translati= on > tables, it's about the function returning false if the hardware reports a > permission fault on levels 1, 2 or 3 of the translation tables. >=20 > For example, on a permssion fault on level 3, PAR_EL1. FST =3D 0b001111 = =3D 0x0F, > which means that the condition: >=20 > (fst & ESR_ELx_FSC_TYPE) =3D=3D ESR_ELx_FSC_PERM (which is 0x0C) is false= and KVM > will fall back to the software walker. >=20 > Does that make sense to you? I'm afraid I still don't get it. =46rom the kernel source: #define ESR_ELx_FSC_TYPE (0x3C) This is a mask covering all fault types. #define ESR_ELx_FSC_PERM (0x0C) This is the value for a permission fault, not encoding a level. Taking your example: (fst & ESR_ELx_FSC_TYPE) =3D=3D (0x0F & 0x3C) =3D=3D 0x0C =3D=3D ESR_ELx_FS= C_PERM As I read it, the condition is true, as it catches a permission fault on any level between 0 and 3. You're obviously seeing something I don't, and I'm starting to question my own sanity... Thanks, M. --=20 Without deviation from the norm, progress is not possible.