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::143; helo=mail-it1-x143.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-it1-x143.google.com (mail-it1-x143.google.com [IPv6:2607:f8b0:4864:20::143]) (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 E35F321B02822 for ; Tue, 27 Nov 2018 04:13:27 -0800 (PST) Received: by mail-it1-x143.google.com with SMTP id m123-v6so9570086ita.4 for ; Tue, 27 Nov 2018 04:13:27 -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=PPSlH0SsS2BjUmFzIKE24nVl/rSV44V13Jn1U/8Skd0=; b=Tj6ipb7/rsILwr1Qq+hfgk7M5pztl8HHSYcO6qjLo4FGAjZnVOAchzxTw8J/GW8Ujh CYw46erBqj4YjW7YyKk/oZ9OZDz+/Yfulj5p3S1ssXf8IS9Ndb9caPAOEdSQd1NZ9ETA muPiNUE8tlfh0RiNkpm2jPvWqxjvJ+9Rv/Rnk= 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=PPSlH0SsS2BjUmFzIKE24nVl/rSV44V13Jn1U/8Skd0=; b=rKi6eS9G3frqsxWESrtBccp8u/KPMvK8bPGEmSenYE9aIyU2Cg3PCkDRKakba1CciQ gfFKLL7SomYWpLbNbfDPS4OYyUE1esiDoOZ14QnB5wnXFBST3g3KimaRrq9T+h5i1sti m3x/wG69sWIeIFRqq1EwF9leMxW1UvWZvCTx1dkLeDB2br1taBmSudfMEHM3XeUhb31G xgbuRtTADczjRVlATpxQlSIEfMMmV5BP1sn2UuGj80oc+41nOmM0rDNGWNG50dRmh327 S77vaZgk/ZEYoGJBk8aaYXkysWaZVqsA70zkwtZjUgnyywUPAmpiHJfboJHW7VeX7cbQ KD1w== X-Gm-Message-State: AGRZ1gK5d0Fh+iiIW3+WJyYK/3tP3QOLwjFjh1MuHYkQMgaQyDFkXjeQ 3LaboCcD9e6iNMnfCkUpAY1mLz7yHouNh4hgWuNX4g== X-Google-Smtp-Source: AFSGD/UUvyHd2OYA4pPNRc7os78eknVLhgBDJfVps3MNZ31SXf3BYcNnoS1yGleHOu8J/R56AuUJCoYDOP39MxizXKs= X-Received: by 2002:a24:710:: with SMTP id f16mr24398577itf.121.1543320806929; Tue, 27 Nov 2018 04:13:26 -0800 (PST) MIME-Version: 1.0 References: <20181126223801.17121-1-ard.biesheuvel@linaro.org> <006d48a9-8102-3e57-1f3b-20e8082ae612@redhat.com> In-Reply-To: <006d48a9-8102-3e57-1f3b-20e8082ae612@redhat.com> From: Ard Biesheuvel Date: Tue, 27 Nov 2018 13:13:15 +0100 Message-ID: To: Laszlo Ersek Cc: "edk2-devel@lists.01.org" , Leif Lindholm , Auger Eric , Andrew Jones , =?UTF-8?Q?Philippe_Mathieu=2DDaud=C3=A9?= , Julien Grall Subject: Re: [PATCH v2 00/13] ArmPkg, ArmVirtPkg: lift 40-bit IPA space limit 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: Tue, 27 Nov 2018 12:13:28 -0000 Content-Type: text/plain; charset="UTF-8" On Tue, 27 Nov 2018 at 13:11, Laszlo Ersek wrote: > > On 11/26/18 23:37, Ard Biesheuvel wrote: > > The ArmVirtQemu targets currently limit the size of the IPA space to > > 40 bits because that is all what KVM supports. However, this is about > > to change, and so we need to update the code if we want to ensure that > > our UEFI firmware builds can keep running on systems that set values > > other than 40 (which could be > 40 or < 40) > > > > So refactor the way we deal with this limit, both for bare metal and for > > virtual targets, so that > > a) the range of the GCD memory map is based directly on the CPU's PA range > > b) the range of the 1:1 mapping in the page tables is based on the CPU's PA > > range (unless it exceeds what the architecture permits for 4k pages) > > c) PcdPrePiCpuMemorySize is no longer needed, and can be removed. > > > > Patch #1 introduces ARM_MMU_IDMAP_RANGE and ArmGetPhysicalAddressBits () > > in ArmLib. > > OK, so the crucial piece of info I missed under v1 was that given the > fixed 4KB page size under UEFI, we might not be able to identity map all > the memory that the CPU would otherwise be capable of addressing > (assuming the OS set up a larger page size). > > However... that seems to leave us with a conundrum. (I'm 100% sure it is > nothing new to you, but it is new to me.) > > If we size the GCD memory space map exactly to what we can identity map > under UEFI, then the UEFI memmap will not advertize the rest of the RAM > to the OS, and the memory will be unusable. > > On the other hand, if we size the GCD to the exact RAM size (part of > which could be out of reach for the CPU *under UEFI*, using 4KB pages), > then the OS will be happy. But, what happens when gBS->AllocatePages() > is served from such a high (>48bits) address range, and then the client > module tries to access the (not mapped) chunk? > That is an excellent question, given that IA32 and ARM are in exactly the same boat with [L]PAE. > Hm... Actually, once this becomes a practical problem, I think we can > take care of it, in a platform PEIM. Namely, just pre-allocate the > entire inaccessible / unmappable range (beyond 48-bits) as Boot Services > Data type memory. That will keep the rest of the firmware out (no > well-behaving module will read or write memory that it didn't allocate), > and the OS will be happy to release and reuse that memory. > > Does this make sense? > I will look into how IA32 and ARM deal with this at the moment. Well spotted! > I'd like to be sure that I understand this right, before starting my v2 > review. > > Thanks! > Laszlo