[bootwrapper PATCH] aarch64: Enable BRBE for the non-secure world
Mark Rutland
mark.rutland at arm.com
Tue Jan 18 02:34:29 PST 2022
On Tue, Jan 18, 2022 at 08:12:39AM +0530, Anshuman Khandual wrote:
> On 1/17/22 6:55 PM, Mark Rutland wrote:
> > On Mon, Jan 17, 2022 at 04:06:44PM +0530, Anshuman Khandual wrote:
> >> On 1/13/22 3:54 PM, Mark Rutland wrote:
> >>> On Thu, Jan 13, 2022 at 03:11:08PM +0530, Anshuman Khandual wrote:
> >>>> +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 for this!
> >
> > Just to check, my understanding, there's nothing else that we need to
> > initialize to ensure that BRBE won't start recording unexpectedly
> > out-of-reset, becuase in BRBCR_EL* the E*BRE bits all warm-reset to 0
> > and hence prevent recording in any of EL0/EL1/EL2 (and BRBE never
> > records at EL3). Is that right?
>
> Right, that is my understanding as well. Those required bits that start
> BRBE recording, always warm-reset to 0.
Thanks for confirming!
I've applied this and pushed it out.
Mark.
More information about the linux-arm-kernel
mailing list