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 CB720C27C6E for ; Fri, 14 Jun 2024 02:25:12 +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:Content-Transfer-Encoding: Content-Type:In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date: Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=++lRrPZIeU62FCvvPHTaFsXIUe2gLeEhO5BLdzO/nxw=; b=z6XjuQdOKCBDfCMA+3MsMM2UkL ICHF4TueorEtrE4m7QYdV9P+D7rnbNJbQq3lKYpZBJOxGhDpDRJvLxy4pK9TtV81max/1Tnt1MYhg qb67qB13jcuWS8L9+YRvgHiNGfUtzepfGY6YUJmAnVQMAN0Ry4OIFqMMbkpU3T6AempUJQTGe46PC 3f7fAiQ0zskaZOKmiU3jbsJ777HOssT6phVuG8OQNLLz8Sxra4KU9Iw116TGO7K0vCFF2NP1zfAmv h3QbICLRtOV9EgGgZtV9LJ86saVU8Gkui3mi1hRwnkM0lZVjJbQRP2q881WkzM3ogNf/c8TqXHFi3 +LngtNtQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sHwch-000000017F7-0wWP; Fri, 14 Jun 2024 02:25:03 +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 1sHwcd-000000017E3-2KyZ for linux-arm-kernel@lists.infradead.org; Fri, 14 Jun 2024 02:25:01 +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 9DB4DFEC; Thu, 13 Jun 2024 19:25:22 -0700 (PDT) Received: from [10.162.16.42] (a077893.blr.arm.com [10.162.16.42]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 0FFCA3F73B; Thu, 13 Jun 2024 19:24:55 -0700 (PDT) Message-ID: Date: Fri, 14 Jun 2024 07:54:53 +0530 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] arm64/mm: Drop ESR_ELx_FSC_TYPE Content-Language: en-US To: Marc Zyngier Cc: linux-arm-kernel@lists.infradead.org, mark.rutland@arm.com, ryan.roberts@arm.com, Catalin Marinas , Will Deacon , linux-kernel@vger.kernel.org References: <20240613094538.3263536-1-anshuman.khandual@arm.com> <86y179jdbx.wl-maz@kernel.org> From: Anshuman Khandual In-Reply-To: <86y179jdbx.wl-maz@kernel.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240613_192459_675473_25DA465E X-CRM114-Status: GOOD ( 12.16 ) 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 On 6/13/24 16:53, Marc Zyngier wrote: > On Thu, 13 Jun 2024 10:45:38 +0100, > Anshuman Khandual wrote: >> >> Fault status codes at page table level 0, 1, 2 and 3 for access, permission >> and translation faults are architecturally organized in a way, that masking >> out ESR_ELx_FSC_TYPE, fetches Level 0 status code for the respective fault. >> >> Helpers like esr_fsc_is_[translation|permission|access_flag]_fault() mask >> out ESR_ELx_FSC_TYPE before comparing against corresponding Level 0 status >> code as the kernel does not yet care about the page table level, the fault >> really occurred previously. >> >> This scheme is starting to crumble after FEAT_LPA2 when level -1 got added. >> Fault status code for translation fault at level -1 is 0x2B which does not >> follow ESR_ELx_FSC_TYPE, requiring esr_fsc_is_translation_fault() changes. >> >> This changes above helpers to compare against individual fault status code >> values for each page table level and drop ESR_ELx_FSC_TYPE which is losing >> its value as a common mask. > > I'd rather we do not drop the existing #defines, for a very > self-serving reason: > > NV requires an implementation to synthesise fault syndromes, and these > definition are extensively used to compose the syndrome information > (see the NV MMU series at [1]). This is also heavily use to emulate > the AT instructions (fault reporting in PAR_EL1.FST). > > Having additional helpers is fine. Dropping the base definitions > isn't, and I'd like to avoid reintroducing them. You would like to just leave behind all the existing level 0 syndrome macro definitions in place ? #define ESR_ELx_FSC_ACCESS (0x08) #define ESR_ELx_FSC_FAULT (0x04) #define ESR_ELx_FSC_PERM (0x0C) Or which are rather #define ESR_ELx_FSC_ACCESS ESR_ELx_FSC_ACCESS_L0 #define ESR_ELx_FSC_FAULT ESR_ELx_FSC_FAULT_L0 #define ESR_ELx_FSC_PERM ESR_ELx_FSC_PERM_L0 But just wondering why cannot ESR_ELx_FSC_[ACCESS|FAULT|PERM]_L0 definitions be used directly in new use cases ? > > Thanks, > > M. > > [1] http://lore.kernel.org/r/20240529145628.3272630-1-maz@kernel.org >