On Fri, 23 Nov 2018 at 14:16, Andrew Jones <[email protected]> wrote: > > On Fri, Nov 23, 2018 at 01:14:27PM +0100, Ard Biesheuvel wrote: > > Add a helper function that returns the maximum physical address space > > size as supported by the current CPU. > > > > Contributed-under: TianoCore Contribution Agreement 1.1 > > Signed-off-by: Ard Biesheuvel <[email protected]> > > --- > > ArmPkg/Include/Library/ArmLib.h | 6 ++++++ > > ArmPkg/Library/ArmLib/AArch64/ArmLibSupport.S | 16 ++++++++++++++++ > > ArmPkg/Library/ArmLib/Arm/ArmLibSupport.S | 8 ++++++++ > > 3 files changed, 30 insertions(+) > > > > diff --git a/ArmPkg/Include/Library/ArmLib.h > > b/ArmPkg/Include/Library/ArmLib.h > > index ffda50e9d767..9a804c15fdb6 100644 > > --- a/ArmPkg/Include/Library/ArmLib.h > > +++ b/ArmPkg/Include/Library/ArmLib.h > > @@ -733,4 +733,10 @@ ArmWriteCntvOff ( > > UINT64 Val > > ); > > > > +UINTN > > +EFIAPI > > +ArmGetPhysicalAddressBits ( > > + VOID > > + ); > > + > > #endif // __ARM_LIB__ > > diff --git a/ArmPkg/Library/ArmLib/AArch64/ArmLibSupport.S > > b/ArmPkg/Library/ArmLib/AArch64/ArmLibSupport.S > > index 1ef2f61f5979..75ab8dade485 100644 > > --- a/ArmPkg/Library/ArmLib/AArch64/ArmLibSupport.S > > +++ b/ArmPkg/Library/ArmLib/AArch64/ArmLibSupport.S > > @@ -196,4 +196,20 @@ ASM_FUNC(ArmWriteSctlr) > > 3:msr sctlr_el3, x0 > > 4:ret > > > > +ASM_FUNC(ArmGetPhysicalAddressBits) > > + mrs x0, id_aa64mmfr0_el1 > > + adr x1, .LPARanges > > + and x0, x0, #7 > > + ldrb w0, [x1, x0] > > + ret > > + > > +// > > +// Bits 0..2 of the AA64MFR0_EL1 system register encode the size of the > > +// physical address space support on this CPU: > > +// 0 == 32 bits, 1 == 36 bits, etc etc > > +// 6 and 7 are reserved > > +// > > +.LPARanges: > > + .byte 32, 36, 40, 42, 44, 48, -1, -1 > > Hi Ard, > > One of the things I was wondering is how much it matters what the > firmware's opinion of highest physical address is vs. the guest > kernel. Do they need to match? This patch series implies they do, > or at least that 40-bits won't always be sufficient for firmware.
Yes. The size of the GCD space limits how much memory we can report as present to the OS. So it only matters if there is DRAM there. > However, guests using 64k pages running on supporting hardware can > use 52-bits. Considering ArmVirtPkg only uses 4k pages, that's not > an option for it, and that justifies not defining index 6 == 52 in > the above array, but will that also restrict the guest? > At the moment, yes. UEFI support for 52-bit/64k pages is still under discussion, and is presently not supported. > > diff --git a/ArmPkg/Library/ArmLib/Arm/ArmLibSupport.S > > b/ArmPkg/Library/ArmLib/Arm/ArmLibSupport.S > > index f2a517671f0a..f2f3c9a25991 100644 > > --- a/ArmPkg/Library/ArmLib/Arm/ArmLibSupport.S > > +++ b/ArmPkg/Library/ArmLib/Arm/ArmLibSupport.S > > @@ -165,4 +165,12 @@ ASM_FUNC(ArmWriteCpuActlr) > > isb > > bx lr > > > > +ASM_FUNC (ArmGetPhysicalAddressBits) > > + mrc p15, 0, r0, c0, c1, 4 // MMFR0 > > + and r0, r0, #0xf // VMSA [3:0] > > + cmp r0, #5 // >5 implies LPAE support > > + movlt r0, #32 // 32 bits if no LPAE > > + movge r0, #40 // 40 bits if LPAE > > + bx lr > > + > > ASM_FUNCTION_REMOVE_IF_UNREFERENCED > > -- > > 2.17.1 > > _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
