From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 631AC2500AA; Thu, 3 Apr 2025 14:15:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1743689751; cv=none; b=vDu0kguJrsjcz6zI/bB8WCgGLXIeV6mRAk0Y7FeowueWaDj/KgC3DKEmuNafd+4x17m3p1MWhotEk47nmMU2AH0fHNTc2gs0z8Af7yHzu8EI8K0NWibf/VGyuIyqCBBx/Jrl8WCfyk43OEXq2c09JJPPVqkxf9pZKnXk5hRnXZw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1743689751; c=relaxed/simple; bh=GmslQeJnel+/tjfSpT8PmCAKRMGRuhx9GKezcLoTBA8=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=UmbNObyMnAvvq/Eygwsd5FKdGE+9s2CQVCkPI5J1BK/iwxwBEi/0+2eFqu56Axi0kCDPTzPb9zugNLdjDxATxjKR8YCc2o7bxsTAuASIOUQ1OtNOd1AajPtOV0wD/vfDXLRtFm+Va3C5UuiCTp52RJLBeNDIUCHinnCTsT9u1ug= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com 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 65B3F1C00; Thu, 3 Apr 2025 07:15:52 -0700 (PDT) Received: from e129823.cambridge.arm.com (e129823.arm.com [10.1.197.6]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 0BB683F59E; Thu, 3 Apr 2025 07:15:46 -0700 (PDT) From: Yeoreum Yun To: catalin.marinas@arm.com, will@kernel.org, broonie@kernel.org, anshuman.khandual@arm.com, joey.gouly@arm.com, yury.khrustalev@arm.com, maz@kernel.org, oliver.upton@linux.dev, frederic@kernel.org, shameerali.kolothum.thodi@huawei.com, james.morse@arm.com, mark.rutland@arm.com, huangxiaojia2@huawei.com, akpm@linux-foundation.org, surenb@google.com, robin.murphy@arm.com Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, Yeoreum Yun Subject: [PATCH 3/3] Documentation/arm64: reflects FEAT_MTE_TAGGED_FAR description Date: Thu, 3 Apr 2025 15:15:35 +0100 Message-Id: <20250403141535.23496-4-yeoreum.yun@arm.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20250403141535.23496-1-yeoreum.yun@arm.com> References: <20250403141535.23496-1-yeoreum.yun@arm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit When FEAT_MTE_TAGGED_FAR feature is supported, the value of address bits [63:60] is preserved on synchronous tag check fault. This patch reflects the above feature in the documentation. Signed-off-by: Yeoreum Yun --- Documentation/arch/arm64/tagged-pointers.rst | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/Documentation/arch/arm64/tagged-pointers.rst b/Documentation/arch/arm64/tagged-pointers.rst index 81b6c2a770dd..73c59a9c7a63 100644 --- a/Documentation/arch/arm64/tagged-pointers.rst +++ b/Documentation/arch/arm64/tagged-pointers.rst @@ -60,11 +60,12 @@ that signal handlers in applications making use of tags cannot rely on the tag information for user virtual addresses being maintained in these fields unless the flag was set. -Due to architecture limitations, bits 63:60 of the fault address -are not preserved in response to synchronous tag check faults -(SEGV_MTESERR) even if SA_EXPOSE_TAGBITS was set. Applications should -treat the values of these bits as undefined in order to accommodate -future architecture revisions which may preserve the bits. +If FEAT_MTE_TAGGED_FAR (Armv8.9) is supported, bits 63:60 of the fault address +are preserved in response to synchronous tag check faults (SEGV_MTESERR) +otherwise not preserved even if SA_EXPOSE_TAGBITS was set. +Applications should interpret the values of these bits based on +the support for the 'mte_far' hwcap. If the support is not present, +the values of these bits should be considered as undefined otherwise valid. For signals raised in response to watchpoint debug exceptions, the tag information will be preserved regardless of the SA_EXPOSE_TAGBITS -- LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}