Re: [PATCH] Arm: GICv3: Don't access GIC_ICDIPR for interrupts 0..31

[Ard Biesheuvel <ard.biesheuvel@linaro.org>]

On 22 May 2017 at 10:45, Leif Lindholm <leif.lindholm@linaro.org> wrote:
> On Fri, May 19, 2017 at 05:31:36PM +0300, Sergei Temerkhanov wrote:
>> On Fri, May 19, 2017 at 1:26 PM, Leif Lindholm <leif.lindholm@linaro.org> wrote:
>> > On Fri, May 19, 2017 at 05:37:02AM +0300, Sergei Temerkhanov wrote:
>> >> On Thu, May 18, 2017 at 7:08 PM, Ard Biesheuvel
>> >> <ard.biesheuvel@linaro.org> wrote:
>> >> > On 16 May 2017 at 03:56, Sergey Temerkhanov <s.temerkhanov@gmail.com> wrote:
>> >> >> These registers are reserved for PPIs and unimplemented on
>> >> >> some architectures
>> >> >>
>> >> >
>> >> >
>> >> > What do you mean by 'architectures'?
>> >>
>> >> GIC core implementations.
>> >>
>> >> > Could you elaborate on which SoC
>> >> > needs this?
>> >> At least Cavium ThunderX/OcteonTX need it.
>> >>
>> >> The GICv3 spec says this on the subject:
>> >>
>> >> 8.9.12 GICD_IPRIORITYR, Interrupt Priority Registers, n = 0 - 254
>> >>
>> >> "These registers are always used when affinity routing is not enabled.
>> >> When affinity routing is enabled for the Security state of an
>> >> interrupt: • GICR_IPRIORITYR is used instead of GICD_IPRIORITYR where
>> >> n = 0 to 7 (that is, for SGIs and PPIs). • GICD_IPRIORITYR is RAZ/WI
>> >> where n = 0 to 7."
>> >
>> > Since they are RAZ/WI, why is this change needed?
>>
>> B/c for some GICv3 cores accessing these registers result in exceptions
>
> Right, so that's architecturally non-compliant.
>
> At which point, as a workaround for a hardware erratum, I think this
> should either be a configurable option (ArmPkg Pcd), or the code
> should be modified to use GICR_IPRIORITYR as the text describes (if
> applicable).
>

That is a good point. The intention of the code is to disable all
interrupt sources, so it is incorrect to begin with, given that PPIs
and SGIs need to be disabled at the respective redistributor of each
CPU. Fix that, and it should no longer raise exceptions on the broken
hardware.

-- 
Ard.