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::344; helo=mail-wm1-x344.google.com; envelope-from=leif.lindholm@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-wm1-x344.google.com (mail-wm1-x344.google.com [IPv6:2a00:1450:4864:20::344]) (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 D4B8C2117FD54 for ; Mon, 26 Nov 2018 09:57:59 -0800 (PST) Received: by mail-wm1-x344.google.com with SMTP id r11-v6so19136827wmb.2 for ; Mon, 26 Nov 2018 09:57:59 -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=Pw4MsWyqkefqIwYyzluls7rMsTjgolDeisIpC85y564=; b=AGLzOUc8ota/0ZnAPKCr039L/CK5clUodU9AkgwzyLuS0MiJ9mrxmlNIymPrITTYEV SvxNB2TRl+h7Jv4Y3K3ivIVz86Qrkn9KYKb8e4MEDm5/RJSNllOCYxIDHw+ZZuWTnLoM aalN4D4vBTtTYQbarnSpxURhfZdtqRLwhnixo= 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=Pw4MsWyqkefqIwYyzluls7rMsTjgolDeisIpC85y564=; b=BAxlYao78AYlz9LXGpjH0JhRGmYhlfgjgtQG7TkDF9sy7/URUc4y3jaQPvOthEhet1 kt5jyu5NYIHewXX/46mTtS5/NpXqaPhBXhwR6/Sz8ja1emjwub1/Y0mwm5nVQXGIxQ9n h/oy0C9DznM+24yV83JRiIKQI+mXpyTclGoMI66NJLsSgYcuOVc6k/WvLCXTN1pBmsj7 OpKQKagVkJI8m/8OfXjSuAp6+T+qrOq44qjD2ZREK1SiBu6l7g06m5csurLjtHT0RXIb OhVwK3eyoWlugfoBPcNjKhO1KMcVt6dt8TYG/BI87pA6/WYvj/GrsUqU7raKP8wHObEB Bc3Q== X-Gm-Message-State: AGRZ1gKCRn6WNqL07ZBk2v12Z7ZwX5zzzoUKRDFR/mzcP11swHYGw6jq 9SkgbIdhLBo/PxEpm0G+IPREHQ== X-Google-Smtp-Source: AJdET5fJuwa/lpH0pLpz7ImWrTf453UgUTYl4a55jWyUpAg5tIRVKmcNW5vzf3964yuV9ELoiTuFlA== X-Received: by 2002:a1c:7601:: with SMTP id r1mr24040951wmc.98.1543255078056; Mon, 26 Nov 2018 09:57: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 r12sm959396wrq.3.2018.11.26.09.57.56 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 26 Nov 2018 09:57:56 -0800 (PST) Date: Mon, 26 Nov 2018 17:57:55 +0000 From: Leif Lindholm To: Ard Biesheuvel Cc: "edk2-devel@lists.01.org" , Laszlo Ersek , Auger Eric , Andrew Jones , Philippe =?iso-8859-1?Q?Mathieu-Daud=E9?= , Julien Grall Message-ID: <20181126175754.mbf42gg4jedbdxej@bivouac.eciton.net> References: <20181123121431.22353-1-ard.biesheuvel@linaro.org> <20181123121431.22353-3-ard.biesheuvel@linaro.org> <20181126174555.rv7xul3sxvvdposh@bivouac.eciton.net> MIME-Version: 1.0 In-Reply-To: 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:58:00 -0000 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Nov 26, 2018 at 06:50:09PM +0100, Ard Biesheuvel wrote: > 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. OK, that works for me. And gets you off the hook for Pcd name bikesheding :) / Leif