From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:4864:20::141; helo=mail-it1-x141.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-it1-x141.google.com (mail-it1-x141.google.com [IPv6:2607:f8b0:4864:20::141]) (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 EED8A21163248 for ; Fri, 23 Nov 2018 05:23:48 -0800 (PST) Received: by mail-it1-x141.google.com with SMTP id c9so17943244itj.1 for ; Fri, 23 Nov 2018 05:23:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ecUISDjOj+osXRLgNyc1XrvEGPHC2XlFE2fO7NGkcmQ=; b=C2Pd2O5l0fH+4n7nYp4G15J5/S3y2YgAZya8KMjyx6FC6f7Ax9hYNHHAqm+FdC8dfG kyf2vLaSu01sIQ+V+jel5VpDxmqvjao518nQwpcB1Zq5B9s5UIjAw/xCB+jr3XGIVZFl 1LJUCDzuxYZeyv02D5hiyQnHFNjNiXGyFijiw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ecUISDjOj+osXRLgNyc1XrvEGPHC2XlFE2fO7NGkcmQ=; b=MRnwmlW5iagkOAiCSKLtzUGoBYvUaXGXuuh6ePPwNSLz9A78shKTDn8WlMqKxiG6if baaPIKBVwbUmAlvA1R7/4yRBFWlJlYJpTXVuMhfMxB4ejsR5ZQhHgm8OVGFRXBCxyrNg hA/okjT+WmMjnKYIWLGN/J0eULR2M8tqk9Cl2wCzMFNblzkkoZXcuNKt1nf9/Lzby683 WZGx+2BL38DI9mAb0IMDdPVJ3kseE7/uyjOo6KpplUEiMrnddHrW3VVEB0XTkYRg2634 2lGYGZDx0Zv0in1XU/s7BWn1T0gYXMKKQjCn5RLc8NnJLzDHkhkZP7YfzJ41GV5adtht 2cdg== X-Gm-Message-State: AGRZ1gL08CXsfWUyI7dr1JWBhFsX4tjH25xF1Pv8ZDMKKYGkMlvrlN2X hJIexLnj2dgHMiEW/mwjr5R6e4tLfbjq5CkAp0AgDA== X-Google-Smtp-Source: AFSGD/XyiYKFLYAWlF8OcCsl8MyCgckna7pbthbRYeTe1FmRerKBjTxrbCwA5T6cpnobXblXAS8fnW4OubkqrHhzLJQ= X-Received: by 2002:a24:710:: with SMTP id f16mr11768589itf.121.1542979427934; Fri, 23 Nov 2018 05:23:47 -0800 (PST) MIME-Version: 1.0 References: <20181123121431.22353-1-ard.biesheuvel@linaro.org> <20181123121431.22353-2-ard.biesheuvel@linaro.org> <20181123131631.ionb53xqzlyepaue@hawk.localdomain> In-Reply-To: From: Ard Biesheuvel Date: Fri, 23 Nov 2018 14:23:36 +0100 Message-ID: To: Andrew Jones Cc: "edk2-devel@lists.01.org" , Laszlo Ersek , Leif Lindholm , Auger Eric , =?UTF-8?Q?Philippe_Mathieu=2DDaud=C3=A9?= , Julien Grall Subject: Re: [PATCH 1/5] ArmPkg/ArmLib: add support for reading the max physical address space size X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2018 13:23:49 -0000 Content-Type: text/plain; charset="UTF-8" On Fri, 23 Nov 2018 at 14:20, Ard Biesheuvel wrote: > > On Fri, 23 Nov 2018 at 14:16, Andrew Jones 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 > > > --- > > > 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. > ... which btw doesn't mean we can't report that much memory in the GCD memory map, we just can't map it in UEFI. There were some discussions about how to proceed here, since there appear to be some SoC vendors that want to use bit 51 to distinguish between DRAM and MMIO regions, which implies that we have to support it to be able to boot such systems (and the architecture does not forbid or discourage the practice)