[PATCH 2/3] arm64: KVM: Allow unaligned accesses at EL2

Marc Zyngier marc.zyngier at arm.com
Wed Jun 7 03:11:30 PDT 2017


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...



More information about the linux-arm-kernel mailing list