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 D717EC433EF for ; Mon, 17 Jan 2022 10:38:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Owner; bh=Kh7yywtzGz1RI1FMFpcJzv8NXazNjnyOvupXaI8Et5I=; b=NibsYy4zCKCrWAjIB+yyeTAObb XzQY6eoHnKLhU05XuHGXVIuEoZuLdpzIqQ49uTLS1/jTp2n/2ddnh/XcmD8M3S/a7dUBedY3xOi22 ++GdCqdvU00A0J5W/9dJMpOQJjM8zLvHLH+5Gq8PRLXr0OiB05EVo6tObuzSenQTFFH28Oq0HCD9u 31Zaoyrm3yR1tBwXL3h8tIXYK8FpyWFX5u/+AbdmlSfP5RfLaWDmo5HMl49bZmIdXqwvZYEZwwUV1 1GkMvPFSJSA0M4VvWD0SBBLl2WGFtYbinyxTwbyR4Mavm8YU9NDdXgSLcPY2mSnJj2zWv1PiABAeQ /IddKPgQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1n9PNd-00EWXr-Pb; Mon, 17 Jan 2022 10:36:53 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1n9PNZ-00EWXG-IR for linux-arm-kernel@lists.infradead.org; Mon, 17 Jan 2022 10:36:51 +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 266DC6D; Mon, 17 Jan 2022 02:36:46 -0800 (PST) Received: from [10.163.73.173] (unknown [10.163.73.173]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B1F3E3F73D; Mon, 17 Jan 2022 02:36:43 -0800 (PST) Subject: Re: [bootwrapper PATCH] aarch64: Enable BRBE for the non-secure world To: Mark Rutland Cc: linux-arm-kernel@lists.infradead.org, andre.przywara@arm.com, robin.murphy@arm.com References: <1642066868-23151-1-git-send-email-anshuman.khandual@arm.com> From: Anshuman Khandual Message-ID: Date: Mon, 17 Jan 2022 16:06:44 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220117_023649_718477_93450867 X-CRM114-Status: GOOD ( 26.24 ) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 1/13/22 3:54 PM, Mark Rutland wrote: > Hi Anshuman, > > This looks fine structurally, I'm just not sure of a couple of details because > I can't find the relevant documentation -- more on that below. > > On Thu, Jan 13, 2022 at 03:11:08PM +0530, Anshuman Khandual wrote: >> MDCR_EL3.SBRBE resets to an UNKNOWN value. Configure it to allow the BRBE >> buffer usage and direct register access in the non-secure world. But just >> before that, check AA64DFR0_EL1.BRBE and make sure BRBE is implemented. We >> still continue to reset MDCR_EL3 register to zero with the exception of >> MDCR_EL3.NSPB, MDCR_EL3.NSTB and MDCR_EL3.SBRBE. > > I'm struggling to find where the BRBE system register fields are documented. > > I looked at the latest ARM ARM (DDI 0487G.b): > > https://developer.arm.com/documentation/ddi0487/gb/ > > ... and the Armv9 supplement (DDI 0608A.a): > > https://developer.arm.com/documentation/ddi0608/aa/ > > ... but AFAICT, neither of those describe the bit-positions of the relevant > fields, so I can't check that those are correct. The other extensions (at leat > TME) describe that in the supplement, so this looks like a bug/oversight. > > Am I looking at the right documents? If this is meant to be in the supplement, > could you please raise a bug report to get that fixed? Please find the MDCR_EL3.SBRBE definition here. https://developer.arm.com/documentation/ddi0601/2021-12/AArch64-Registers/ MDCR-EL3--Monitor-Debug-Configuration-Register--EL3-?lang=en#fieldset_0-33_32-1 > >> >> Signed-off-by: Anshuman Khandual >> --- >> arch/aarch64/boot.S | 8 ++++++++ >> 1 file changed, 8 insertions(+) >> >> diff --git a/arch/aarch64/boot.S b/arch/aarch64/boot.S >> index bfbb6ec..ca1b292 100644 >> --- a/arch/aarch64/boot.S >> +++ b/arch/aarch64/boot.S >> @@ -103,6 +103,14 @@ ASM_FUNC(_start) >> ldr x1, =(0x3 << 24) >> orr x0, x0, x1 >> >> +1: mrs x1, id_aa64dfr0_el1 >> + ubfx x1, x1, #52, #4 >> + cbz x1, 1f >> + >> + // Enable BRBE for the non-secure world. >> + ldr x1, =(0x3 << 32) >> + orr x0, x0, x1 >> + > > I assume this is the `SBRBE` field, which naming-wise sounds like it controls > Secure rather than Non-Secure (e,g. by way of comparison to `NSPB`). Is that Right, that is some what counter-intuitive. > correct? What effect does the value 0x3 have? As per the definition above. 0b11 This control does not cause any direct accesses to BRBE registers or instruction to be trapped, and does not cause any Exception levels to be a prohibited region. This basically allows BRBE usage in EL2/EL1. > > Thanks, > Mark. > >> 1: msr mdcr_el3, x0 // Disable traps to EL3 >> >> mrs x0, id_aa64pfr0_el1 >> -- >> 2.7.4 >> _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel