[PATCH 3/4] KVM: arm64: Rename SCTLR_ELx_FLAGS to SCTLR_EL2_FLAGS

Will Deacon will at kernel.org
Wed Mar 10 16:15:47 GMT 2021


On Wed, Mar 10, 2021 at 04:05:17PM +0000, Marc Zyngier wrote:
> On Wed, 10 Mar 2021 15:46:26 +0000,
> Will Deacon <will at kernel.org> wrote:
> > 
> > On Wed, Mar 10, 2021 at 03:26:55PM +0000, Marc Zyngier wrote:
> > > Only the nVHE EL2 code is using this define, so let's make it
> > > plain that it is EL2 only.
> > > 
> > > Signed-off-by: Marc Zyngier <maz at kernel.org>
> > > ---
> > >  arch/arm64/include/asm/sysreg.h    | 2 +-
> > >  arch/arm64/kvm/hyp/nvhe/hyp-init.S | 2 +-
> > >  2 files changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
> > > index dfd4edbfe360..9d1aef631646 100644
> > > --- a/arch/arm64/include/asm/sysreg.h
> > > +++ b/arch/arm64/include/asm/sysreg.h
> > > @@ -579,7 +579,7 @@
> > >  #define SCTLR_ELx_A	(BIT(1))
> > >  #define SCTLR_ELx_M	(BIT(0))
> > >  
> > > -#define SCTLR_ELx_FLAGS	(SCTLR_ELx_M  | SCTLR_ELx_A | SCTLR_ELx_C | \
> > > +#define SCTLR_EL2_FLAGS	(SCTLR_ELx_M  | SCTLR_ELx_A | SCTLR_ELx_C | \
> > >  			 SCTLR_ELx_SA | SCTLR_ELx_I | SCTLR_ELx_IESB)
> > >  
> > >  /* SCTLR_EL2 specific flags. */
> > > diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-init.S b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
> > > index 4eb584ae13d9..7423f4d961a4 100644
> > > --- a/arch/arm64/kvm/hyp/nvhe/hyp-init.S
> > > +++ b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
> > > @@ -122,7 +122,7 @@ alternative_else_nop_endif
> > >  	 * as well as the EE bit on BE. Drop the A flag since the compiler
> > >  	 * is allowed to generate unaligned accesses.
> > >  	 */
> > > -	mov_q	x0, (SCTLR_EL2_RES1 | (SCTLR_ELx_FLAGS & ~SCTLR_ELx_A))
> > > +	mov_q	x0, (SCTLR_EL2_RES1 | (SCTLR_EL2_FLAGS & ~SCTLR_ELx_A))
> > 
> > Can we just drop SCTLR_ELx_A from SCTLR_EL2_FLAGS instead of clearing it
> > here?
> 
> Absolutely. That'd actually be an improvement.

In fact, maybe just define INIT_SCTLR_EL2_MMU_ON to mirror what we do for
EL1 (i.e. including the RES1 bits) and then use that here?

Will



More information about the linux-arm-kernel mailing list