Thread (49 messages) 49 messages, 8 authors, 2014-03-15
STALE4475d

[PATCH 03/18] arm64: boot protocol documentation update for GICv3

From: Will Deacon <hidden>
Date: 2014-02-26 15:31:42

On Wed, Feb 26, 2014 at 02:37:00PM +0000, Marc Zyngier wrote:
On 25/02/14 18:06, Will Deacon wrote:
quoted
On Wed, Feb 05, 2014 at 01:30:35PM +0000, Marc Zyngier wrote:
quoted
Linux has some requirements that must be satisfied in order to boot
on a system built with a GICv3.

Signed-off-by: Marc Zyngier <redacted>
---
 Documentation/arm64/booting.txt | 7 +++++++
 1 file changed, 7 insertions(+)
diff --git a/Documentation/arm64/booting.txt b/Documentation/arm64/booting.txt
index a9691cc..4a02ebd 100644
--- a/Documentation/arm64/booting.txt
+++ b/Documentation/arm64/booting.txt
@@ -131,6 +131,13 @@ Before jumping into the kernel, the following conditions must be met:
   the kernel image will be entered must be initialised by software at a
   higher exception level to prevent execution in an UNKNOWN state.
 
+  For systems with a GICv3 interrupt controller, it is expected that:
+  - ID_AA64PFR0_EL1.GIC (bits [27:24]) must have the value 0b0001
Since ID_AA64PFR0_EL1 is read-only at all exception levels, I don't see the
value of this statement.
Think virtualization. A hypervisor can control reads of ID_AA64PFR0_EL1
by setting HCR_EL2.TID3, and report whatever it wants.
Sure, but it seems unreasonable to me that we require a hypervisor to tell a
guest about GICv3 if the system happens to have one. What if it wants to
emulate a GICv2? In other words, requiring this in booting.txt seems
superflous.

Will
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help