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::144; helo=mail-it1-x144.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-it1-x144.google.com (mail-it1-x144.google.com [IPv6:2607:f8b0:4864:20::144]) (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 6A01C2117D76C for ; Mon, 26 Nov 2018 09:50:22 -0800 (PST) Received: by mail-it1-x144.google.com with SMTP id x19so29686276itl.1 for ; Mon, 26 Nov 2018 09:50:22 -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=lAOoGRjCVBJ5f2wgWBZDTmSh9coniykw9sx1s2wWZEc=; b=I+ytdFIrZQkR3Y7a2WLdOvREnVqFzW/VorIsBqrP9yguyvBBaTEViSV+zpTlm4x7G6 nP8MlqExBnfjc6MjRzCAQoH5MA1k9D1tOR1LmtNjyobstumlY6YBC6W+LPkhR+1JLkfE 0BvOl3jD3UETepFyjUAmfQoXTJuoj8B1cltv8= 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=lAOoGRjCVBJ5f2wgWBZDTmSh9coniykw9sx1s2wWZEc=; b=aa+4mihfvZHm9/Gr07m0jNMwQC08FAl1XkUzKbiUESBalJUS7dGjDDEnCGiiWcG0jK FX18Zvtr6sFp+ZbZs3/qWwYGkMt7Sk3nzlE+W6cts/R+Vi63rKKKhBaOw60oDQx7LQQa a7811sWuOtMm9aDNt/oOmlzPWhE56VnM/b2EiNlXL5PmZeiqg6+YoIsl2S6sx6+6Czoe 4MckoMC7/qNX79Z7fLgnwPm8PX59fnXG53enFeD2LnE/dtnAI/OL4jb6a2dWLR29xrRg gms2aLZkHh0jxoEDqaENU8rbGMcGQXrDlVz1LNe5v6sWWGPxeeWJ1CRsf9Wa3fL9rSUy Tqdw== X-Gm-Message-State: AA+aEWZMI79HGDMFYcqwu1eaj0WwwVxUlS/1FIIlR4QprgR6zm1FTi1d usw7rjtUmETK3bHF3XZfM4g3MTlSEejuprTCv8S/iQ== X-Google-Smtp-Source: AFSGD/ULn3Bl0IsC4ElQVkblSAnAI+bNQ0Sop8DRvKHpLgH1yIq2WU+S3vlBHYw9DwEe3lT2I3yqrR428UB6O3Bwkc0= X-Received: by 2002:a02:4c9:: with SMTP id 192mr24571110jab.2.1543254621600; Mon, 26 Nov 2018 09:50:21 -0800 (PST) MIME-Version: 1.0 References: <20181123121431.22353-1-ard.biesheuvel@linaro.org> <20181123121431.22353-3-ard.biesheuvel@linaro.org> <20181126174555.rv7xul3sxvvdposh@bivouac.eciton.net> In-Reply-To: <20181126174555.rv7xul3sxvvdposh@bivouac.eciton.net> From: Ard Biesheuvel Date: Mon, 26 Nov 2018 18:50:09 +0100 Message-ID: To: Leif Lindholm Cc: "edk2-devel@lists.01.org" , Laszlo Ersek , Auger Eric , Andrew Jones , =?UTF-8?Q?Philippe_Mathieu=2DDaud=C3=A9?= , Julien Grall 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:50:22 -0000 Content-Type: text/plain; charset="UTF-8" On Mon, 26 Nov 2018 at 18:46, Leif Lindholm wrote: > > 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 :| > I am reworking this so PcdPrePiCpuMemorySize retains its meaning. Instead, I will add something like this to ArmLib.h // // ARM_MMU_IDMAP_LIMIT defines the maximum size of the identity mapping // that covers the entire address space when running in UEFI. This is limited // to what can architecturally be mapped using a 4 KB granule, even if the // hardware is capable of mapping more using larger pages. // #ifdef MDE_CPU_ARM #define ARM_MMU_IDMAP_LIMIT (MAX_UINT32) #else #define ARM_MMU_IDMAP_LIMIT (1ULL << 48) #endif and use that in the MMU code as an upper bound in case the CPU supports 52 bits.