From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.groups.io (mail02.groups.io [66.175.222.108]) by spool.mail.gandi.net (Postfix) with ESMTPS id C0A147803CC for ; Wed, 9 Aug 2023 23:40:16 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=lOerSws/hS2cKZVeBKzL3gHpnjvFSlZPhFBlQOQW2ZU=; c=relaxed/simple; d=groups.io; h=DKIM-Filter:Message-ID:Date:MIME-Version:User-Agent:Subject:To:References:From:In-Reply-To:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Language:Content-Type:Content-Transfer-Encoding; s=20140610; t=1691624415; v=1; b=O8j+ZKx3IgglLhm2o5AB2pAjorJ76BYHqxJ/1594UK3vtHHnINdZC516cvsabyoFbDM1euID UKCl/aD7cpOXc5R+ml/t1jJaaXFzpyR/gE7A60/ivvHHNR0UCFlRUzt2+I15VqKJcZzx/OxTkPz jlFQOftWh0iC8Cw8Tv7NAD6Y= X-Received: by 127.0.0.2 with SMTP id fT7YYY7687511xqQ98KdAPLm; Wed, 09 Aug 2023 16:40:15 -0700 X-Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mx.groups.io with SMTP id smtpd.web11.6243.1691624414745959773 for ; Wed, 09 Aug 2023 16:40:14 -0700 X-Received: from [10.137.194.171] (unknown [131.107.1.171]) by linux.microsoft.com (Postfix) with ESMTPSA id 374A72086958; Wed, 9 Aug 2023 16:40:14 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 374A72086958 Message-ID: Date: Wed, 9 Aug 2023 16:40:14 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [edk2-devel] Runtime Page Granularity on ARM64 To: devel@edk2.groups.io, ardb@kernel.org, Andrew Fish References: From: "Oliver Smith-Denny" In-Reply-To: Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Reply-To: devel@edk2.groups.io,osde@linux.microsoft.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: 18XlxnRNkXNbPwcC3rpwKRx6x7686176AA= Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=O8j+ZKx3; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=linux.microsoft.com (policy=none); spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io Thanks Ard and Andrew, I appreciate the info! That clears things up for me. Oliver On 8/9/2023 3:56 PM, Ard Biesheuvel wrote: > Hi, >=20 > On Wed, 9 Aug 2023 at 23:35, Oliver Smith-Denny > wrote: >> >> Hi Ard, >> >> I just sent out a patch (MdeModulePkg: HeapGuard: Don't Assume Pool Head >> Allocated In First Page) to fix HeapGuard GuardAlignedToTail behavior on >> ARM64. However, this raised a question of why ARM64 sets >> RUNTIME_PAGE_ALLOCATION_GRANULARITY to 64k when X64 does not. You added >> this in ProcessorBind.h for ARM64, so I am hoping to get some additional >> context from you (or anyone on the mailing list who has insight). >> >> I understand that on ARM64 we can have 64k pages in the OS, but what I >> do not understand is why we need to map in 64k chunks in UEFI. I see the >> UEFI spec says that ARM allows for 64K pages and that if runtime code >> or data is within a 64KB page then all 4k pages within that 64K page >> need the same memory attributes, which makes sense. >> >> Is this runtime granularity just to satisfy that requirement that the >> memory attributes are the same or is there an additional reason that >> we need to use the 64k granularity on ARM64? >> >> In any case, I am confused why this is not an issue on X64 or if we >> have 2MB pages in the OS? I'm not as familiar with the mechanisms an >> OS will use to map runtime services within its space, but they will be >> virtualized and the OS will have its own page tables, so it doesn't >> quite follow to me why the OS cares all that much what UEFI has done. >> >> Any light you can shed here would be greatly appreciated. >> >=20 > It is not about how UEFI maps them at boot time at all, and we happily > use 1GB or 2MB mappings for runtime regions if the permission > attributes allow it. It is simply about the granularity of regions > that the OS needs to care about, i.e., those with the > EFI_MEMORY_RUNTIME attribute set in the EFI memory map, as well as > memory used for ACPI tables or mapped at runtime by the AML > interpreter. >=20 > There are two important differences with X64: > - arm64 supports 16k and 64k pages > - arm64 does not tolerate aliases with mismatched attributes >=20 > If a EFI_MEMORY_RUNTIME region is not aligned to 64k, the OS is > generally forced to round outwards if it is running with a page size > > 4k.This means that some adjacent physical pages will be covered by > [typically] a writeback cacheable mapping even though the memory map > may describe them differently. For instance, a EFI reserved region > used by the ACPI parking protocol requires non-cacheable mappings, and > even if such a mapping is created elsewhere in the OS's virtual > address space, if it overlaps with a cacheable mapping of the same > physical 64k, the result is unpredictable. (The uncached accesses are > likely to hit in the cache inadvertently if a [speculative] access via > the cached alias pulled in the data) >=20 > Whether or not the architecture or OS supports 2 MB pages is not > really relevant, given that it will never be forced to use those for > regions that are not aligned to 2 MB. A 64k pagesize OS simply has no > smaller granule available, and so it has to round outwards (*) >=20 > The least impactful way to achieve this in EDK2 was to increase the > page allocation granularity for runtime memory types (and rework the > pool allocator to make better use of memory that is allocated in > larger chunks). I imagine there might be other ways to ensure that > EFI_MEMORY_RUNTIME regions are aligned sufficiently, e.g., by > reasoning about whether or not adjacent regions may require different > attributes, and permitting misalignment if they don't. But this will > be a lot more hassle, and a lot more room for error. >=20 -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#107661): https://edk2.groups.io/g/devel/message/107661 Mute This Topic: https://groups.io/mt/100652665/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-