On 07/06/17 10:56, Christoffer Dall wrote: > On Wed, Jun 07, 2017 at 10:16:29AM +0100, Marc Zyngier wrote: >> On 06/06/17 21:09, Christoffer Dall wrote: >>> On Tue, Jun 06, 2017 at 07:08:34PM +0100, Marc Zyngier wrote: >>>> We currently have the SCTLR_EL2.A bit set, trapping unaligned accesses >>>> at EL2, but we're not really prepared to deal with it. So far, this >>>> has been unnoticed, until GCC 7 started emitting those (in particular >>>> 64bit writes on a 32bit boundary). >>>> >>>> Since the rest of the kernel is pretty happy about that, let's follow >>>> its example and set SCTLR_EL2.A to zero. Modern CPUs don't really >>>> care. >>> >>> Why do we set the A flag via SCTLR_ELx_FLAGS in the first place, only to >>> drop that flag later on for both EL1 and EL2 ? >> >> That flag is always cleared at EL1, never set. Actually, only EL2 uses >> that macro to *set* flags. An alternative would be to do away with the >> macro and use the individual flags, like the 32bit side does. >> >> What do you think? >> > I don't understand why the A bit is part of SCTLR_ELx_FLAGS then? Is it > used as a mask, is that why? Yes. See arch/arm64/kernel/cpu-reset.S for example, where the macro is used to clear all these flags in one go. SCTLR_EL1.A was never set the first place (it was cleared at boot time in __cpu_setup). We could remove the A bit from SCTLR_ELx_FLAGS altogether, and it wouldn't have any observable effect (or so I believe). This would be another way to fix this problem. > In terms of these patches, I think we should apply these, because they > solve the problem and do the same thing. OK. Thanks, M. -- Jazz is not dead. It just smells funny...
