On Tuesday 28 Jan 2020 at 17:37:04 (+0000), Valentin Schneider wrote: > Hi Suzuki, > > On 28/01/2020 17:26, Suzuki Kuruppassery Poulose wrote: > >> So, providing I didn't get completely lost on the way, I have to ask: > >> why do we use CPACR_EL1 here? Couldn't we use CPTR_EL2 directly? > > > > Part of the reason is, CPTR_EL2 has different layout depending on > > whether HCR_EL2.E2H == 1. e.g, CPTR_EL2.TTA move from Bit[28] to Bit[20]. > > > > So, to keep it simple, CPTR_EL2 is used for non-VHE code with the shifts > > as defined by the "CPTR_EL2 when E2H=0" > > > > if E2H == 1, CPTR_EL2 takes the layout of CPACR_EL1 and "overrides" some > > of the RES0 bits in CPACR_EL1 with EL2 controls (e.g: TAM, TCPAC). > > Thus we use CPACR_EL1 to keep the "shifts" non-conflicting (e.g, ZEN) > > and is the right thing to do. > > > > It is a bit confusing, but we are doing the right thing. May be we could improve the comment like : > > > > /* > > * With VHE (HCR.E2H == 1), CPTR_EL2 has the same layout as > > * CPACR_EL1, except for some missing controls, such as TAM. > > * And accesses to CPACR_EL1 are routed to CPTR_EL2. > > * Also CPTR_EL2.TAM has the same position with or without > > * HCR.E2H == 1. Therefore, use CPTR_EL2.TAM here for > > * trapping the AMU accesses. > > */ > > Thanks Suzuki, this makes sense! Ionela. > > Thanks for clearing this up! I also bothered MarcZ in the meantime who > also cleared up some of my confusion (including which layout takes effect). > > So yeah, I think what we want here is to keep using CPTR_EL2_TAM but have a > comment that explains why (which you just provided!). > > > Suzuki
