From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2a00:1450:4864:20::342; helo=mail-wm1-x342.google.com; envelope-from=leif.lindholm@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com [IPv6:2a00:1450:4864:20::342]) (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 026892115C07D for ; Mon, 26 Nov 2018 09:46:00 -0800 (PST) Received: by mail-wm1-x342.google.com with SMTP id n133so2676796wmd.4 for ; Mon, 26 Nov 2018 09:46:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=UFW3VpvxmYVauhEiUcz2EV+YyGVDnCwI0E0FnbjcA58=; b=hkDM79zvCwQxwiumgnmfVtWrbR0WShL1rFWFNkrfw2672lyF1nF+MlvNpvTvFjYR8o ygDAzF/TqeE7MCb8YPp5NC627R6/AAGXeaNsrvCi8B46ruziTAUP3Dy2YTAnsRoDEtIO HAR0kpNI9IXcpOqv9ilF4/xR+ELzBSyAN0U30= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=UFW3VpvxmYVauhEiUcz2EV+YyGVDnCwI0E0FnbjcA58=; b=dIGnmVWdCjRoFqNaQuc4GGEyZNScUFmhxeaLsQ/BQE5sEDTEP0wzV1AQKRc6kJVdW6 DRkfirdMeyN0qKIVii33HPIXC43Bumb09wMYJTWPm1Z1Aq6AuhGge8bDOjxRrrnRfpOu y/HaKlaSSa1K9UvPPeAwoWuSp6xQeF+PfWCp5oYxHTURHer7ofSNW8GaZbJk416TH2to l4NJStwvspnMbVIfjr1iXDSwNwlnpOnL7QzH7bxGP1GBQ36YYxMhejneIP7wfAar4fnn bzU2QUiAtvS4prT8aOxR0S8uV+4oyKeYcANDljP3bex26WnolRyAMuGg/1Iwck/A3rXl 52bg== X-Gm-Message-State: AGRZ1gJv1jreK1N92+DYfVPBdb2T7Pgtbp0vJbLD9YyUTuiv6EscQ3FF bDdad1TpPNV5KILix3kRb9RccQ== X-Google-Smtp-Source: AJdET5cHMqbQ5Ub6PTCStI/qgmIpbsScE7eKq4NY4REgLWGxS8PAEflaEmIMLpSV+44/tjlcB8cxmg== X-Received: by 2002:a1c:ef08:: with SMTP id n8mr26039903wmh.114.1543254358366; Mon, 26 Nov 2018 09:45:58 -0800 (PST) Received: from bivouac.eciton.net (bivouac.eciton.net. [2a00:1098:0:86:1000:23:0:2]) by smtp.gmail.com with ESMTPSA id c12sm562509wrs.82.2018.11.26.09.45.57 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 26 Nov 2018 09:45:57 -0800 (PST) Date: Mon, 26 Nov 2018 17:45:55 +0000 From: Leif Lindholm To: Ard Biesheuvel Cc: edk2-devel@lists.01.org, Laszlo Ersek , Eric Auger , Andrew Jones , Philippe Mathieu-Daude , Julien Grall Message-ID: <20181126174555.rv7xul3sxvvdposh@bivouac.eciton.net> References: <20181123121431.22353-1-ard.biesheuvel@linaro.org> <20181123121431.22353-3-ard.biesheuvel@linaro.org> MIME-Version: 1.0 In-Reply-To: <20181123121431.22353-3-ard.biesheuvel@linaro.org> User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: [PATCH 2/5] ArmPkg/ArmMmuLib: take the CPU supported maximum PA space into account 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: Mon, 26 Nov 2018 17:46:01 -0000 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Nov 23, 2018 at 01:14:28PM +0100, Ard Biesheuvel wrote: > In preparation of permitting the virt code to define a larger PA space > size via gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize than what the > CPU actually supports, take the CPU's capabilities into account when > setting up the page tables. This is necessary because KVM will shortly > support variable PA space sizes, and to support running the same UEFI > binaries regardless of that limit, PcdPrePiCpuMemorySize needs to be > treated as an upper bound rather than a fixed size. Why do we keep PcdPrePiCpuMemorySize at all? (I.e., rather than just using the probed value? Mainly for the purpose of being able to restrict ourselves to 32/48 bits? If we keep it, should we rename PcdPrePiCpuMemorySize -> PcdPrePiCpuMemoryBits and PcdPrePiCpuIoSize -> PcdPrePiCpuIoBits ? Argument against this would be that later consumers still refer to the value extracted from the HOB as SizeOf*Space, and happily shifts 1s around by it :| / Leif > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ard Biesheuvel > --- > ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c b/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c > index 4b62ecb6a476..a4fde9b59383 100644 > --- a/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c > +++ b/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c > @@ -593,6 +593,7 @@ ArmConfigureMmu ( > { > VOID* TranslationTable; > UINT32 TranslationTableAttribute; > + UINTN MaxAddressBits; > UINT64 MaxAddress; > UINTN T0SZ; > UINTN RootTableEntryCount; > @@ -605,7 +606,9 @@ ArmConfigureMmu ( > } > > // Cover the entire GCD memory space > - MaxAddress = (1UL << PcdGet8 (PcdPrePiCpuMemorySize)) - 1; > + MaxAddressBits = MIN (ArmGetPhysicalAddressBits (), > + PcdGet8 (PcdPrePiCpuMemorySize)); > + MaxAddress = (1UL << MaxAddressBits) - 1; > > // Lookup the Table Level to get the information > LookupAddresstoRootTable (MaxAddress, &T0SZ, &RootTableEntryCount); > -- > 2.17.1 >