From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 5D5D321A16E4D for ; Tue, 23 May 2017 03:23:37 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id g126so16724210ith.0 for ; Tue, 23 May 2017 03:23:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=FXwWwISVPf3aXRHM1d9JKkk/6XS2BgR7+ugLXI2vtWw=; b=Yt+zl70KSx9ALwM3keYGU25C02oiTDcoj1JdAzQoWP9wur4wTEURdIU+ECU9ntOqB7 L5wO1EtUJr8OLEH3uuKJGHL8wxiqhNgtxNSYfhrsXTAAeRPFIFoOoIni6PHaPnBFamH9 t//Evaq+r3lrlXqeY+qdcWgIs0YDF8TzTlGsw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=FXwWwISVPf3aXRHM1d9JKkk/6XS2BgR7+ugLXI2vtWw=; b=CtkZAEhIVwrxb+uBGsynN8QqbeT+jZ4yDP8e5HHWXYM4VB3fSeMm6LloOmUvUlPQy8 XLCSm78PyEgaxEU48zWoPAZkBmAYCiGXGdrhkcRJoq1dRz81ZR+SHpUpR3SC8supgQVj sjTFsTu+Faphd56hNW1d99ExjzD+nhG6wxj9efd3WO2q0msVtxnp6QqSYHUSJ5DCM/SR HGjGhFoMX23ggFnwfwFucSqnjBwJKKvSRMJmxNfNxhTS3rRKnvGcE8x16b/EsZZk/ldL yEZhUZw5xT4zN9czhxKnlEde3LXksZK+GEXn0QAJH1yYLFnKC75AA8wxpGOkQOzSvcId bKeA== X-Gm-Message-State: AODbwcD0AqnD6CDDF3fk98AQFaOhSCUfRFu3LAt02JH56Q64fLUKnV1P Va+worPTv5/IjSQfIkPA/tIbcv6Ei8IC X-Received: by 10.36.237.72 with SMTP id r69mr2022401ith.98.1495535016328; Tue, 23 May 2017 03:23:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.24 with HTTP; Tue, 23 May 2017 03:23:35 -0700 (PDT) In-Reply-To: <20170522174512.GK1657@bivouac.eciton.net> References: <1494903391-716-1-git-send-email-s.temerkhanov@gmail.com> <20170519102622.GC1657@bivouac.eciton.net> <20170522174512.GK1657@bivouac.eciton.net> From: Ard Biesheuvel Date: Tue, 23 May 2017 03:23:35 -0700 Message-ID: To: Leif Lindholm Cc: Sergei Temerkhanov , "edk2-devel@lists.01.org" Subject: Re: [PATCH] Arm: GICv3: Don't access GIC_ICDIPR for interrupts 0..31 X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 10:23:37 -0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 22 May 2017 at 10:45, Leif Lindholm 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 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 >> >> wrote: >> >> > On 16 May 2017 at 03:56, Sergey Temerkhanov 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 =3D 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: =E2=80=A2 GICR_IPRIORITYR is used instead of GICD_IPRIORIT= YR where >> >> n =3D 0 to 7 (that is, for SGIs and PPIs). =E2=80=A2 GICD_IPRIORITYR = is RAZ/WI >> >> where n =3D 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. --=20 Ard.