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 526D9D80111 for ; Wed, 9 Aug 2023 23:06:18 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=bJUD1vR5vB9kNuzxpBlwquMMMabSr15gQlTlDaK6rdM=; c=relaxed/simple; d=groups.io; h=From:Message-id:MIME-version:Subject:Date:In-reply-to:Cc:To:References:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-type; s=20140610; t=1691622377; v=1; b=Q+2+V7Jl6tohtZmP+rEOBnXXUuNvK5zWgzwy9kyv6TLsaYGpVbvq+CaULhTQHBYkqJ/id3n4 5nhkvqIGv6IRcqyq16Dyj124zv/CRRcbbuQ5pcrtmTaCLXpgK0Uo74ZYiUfc8JXiiRsYTwdXtH0 OlfsYAGlZmB/X6rSvHAuxOyU= X-Received: by 127.0.0.2 with SMTP id 3PGMYY7687511xXk0TrJOcg6; Wed, 09 Aug 2023 16:06:17 -0700 X-Received: from ma-mailsvcp-mx-lapp01.apple.com (ma-mailsvcp-mx-lapp01.apple.com [17.32.222.22]) by mx.groups.io with SMTP id smtpd.web10.5607.1691622376297745636 for ; Wed, 09 Aug 2023 16:06:16 -0700 X-Received: from ma-mailsvcp-mta-lapp02.corp.apple.com (ma-mailsvcp-mta-lapp02.corp.apple.com [10.226.18.134]) by ma-mailsvcp-mx-lapp01.apple.com (Oracle Communications Messaging Server 8.1.0.23.20230328 64bit (built Mar 28 2023)) with ESMTPS id <0RZ500F4RC6F5N20@ma-mailsvcp-mx-lapp01.apple.com> for devel@edk2.groups.io; Wed, 09 Aug 2023 16:06:15 -0700 (PDT) X-Proofpoint-GUID: 9fjksETRFXPfIKZcJJ7lnXO25CzvUlLd X-Proofpoint-ORIG-GUID: 9fjksETRFXPfIKZcJJ7lnXO25CzvUlLd X-Received: from ma-mailsvcp-mmp-lapp03.apple.com (ma-mailsvcp-mmp-lapp03.apple.com [17.32.222.16]) by ma-mailsvcp-mta-lapp02.corp.apple.com (Oracle Communications Messaging Server 8.1.0.23.20230328 64bit (built Mar 28 2023)) with ESMTPS id <0RZ5011BFC6FHC10@ma-mailsvcp-mta-lapp02.corp.apple.com>; Wed, 09 Aug 2023 16:06:15 -0700 (PDT) X-Received: from process_milters-daemon.ma-mailsvcp-mmp-lapp03.apple.com by ma-mailsvcp-mmp-lapp03.apple.com (Oracle Communications Messaging Server 8.1.0.23.20230328 64bit (built Mar 28 2023)) id <0RZ500V00C60D500@ma-mailsvcp-mmp-lapp03.apple.com>; Wed, 09 Aug 2023 16:06:15 -0700 (PDT) X-Va-A: X-Va-T-CD: 4e19b10d6aa77bb3e7d825d48d1852e1 X-Va-E-CD: fd250f2b9252e1f14324d0c4381da44e X-Va-R-CD: 1779e576d42523525493d597fd9bfdb6 X-Va-ID: e64b7532-edf3-44f6-b2fd-83b17e814586 X-Va-CD: 0 X-V-A: X-V-T-CD: 4e19b10d6aa77bb3e7d825d48d1852e1 X-V-E-CD: fd250f2b9252e1f14324d0c4381da44e X-V-R-CD: 1779e576d42523525493d597fd9bfdb6 X-V-ID: d6e60fee-4d67-40c2-8154-6bab44801d59 X-V-CD: 0 X-Received: from smtpclient.apple (unknown [17.232.204.207]) by ma-mailsvcp-mmp-lapp03.apple.com (Oracle Communications Messaging Server 8.1.0.23.20230328 64bit (built Mar 28 2023)) with ESMTPSA id <0RZ500GAOC6E1B00@ma-mailsvcp-mmp-lapp03.apple.com>; Wed, 09 Aug 2023 16:06:15 -0700 (PDT) From: "Andrew Fish via groups.io" Message-id: MIME-version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Subject: Re: [edk2-devel] Runtime Page Granularity on ARM64 Date: Wed, 09 Aug 2023 19:06:04 -0400 In-reply-to: Cc: Ard Biesheuvel To: edk2-devel-groups-io , osde@linux.microsoft.com References: 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,afish@apple.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: kF9yMYpjgI4HdBBNs0wUdCrBx7686176AA= Content-type: multipart/alternative; boundary="Apple-Mail=_B647A40C-92EE-4133-8D00-A8EE1F37C9BC" X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=Q+2+V7Jl; spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io; dmarc=none --Apple-Mail=_B647A40C-92EE-4133-8D00-A8EE1F37C9BC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Oliver, My understanding is that AArch64 (ARMv8) supports 3 page table granules: 4K= B, 16KB, and 64KB [1]. These granules represent the smallest range for a pa= ge table, and this granule changes which bits of the VA index into what lev= el of paging. On x86 this indexing was fixed an a 2 MiB page table just liv= eds higher up in the same hierarchy.=20 While AArch64 supports all 3 granule sizes, how many granule sizes are supp= orted by a given CPU is implementation defined. So it is legal for an AArch= 64 CPU to only support 64KB pages. You can always do 4K pages on Intel, so = that is the difference.=20 [1] https://developer.arm.com/documentation/101811/0103/Translation-granule Thanks, Andrew Fish > On Aug 9, 2023, at 5:35 PM, Oliver Smith-Denny = wrote: >=20 > Hi Ard, >=20 > 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). >=20 > 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. >=20 > 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? >=20 > 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. >=20 > Any light you can shed here would be greatly appreciated. >=20 > Thanks, > Oliver >=20 >=20 >=20 >=20 >=20 >=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 (#107660): https://edk2.groups.io/g/devel/message/107660 Mute This Topic: https://groups.io/mt/100652665/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/leave/12367111/7686176/19134562= 12/xyzzy [rebecca@openfw.io] -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- --Apple-Mail=_B647A40C-92EE-4133-8D00-A8EE1F37C9BC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Oliver,

My = understanding is that AArch64 (ARMv8) supports 3 page table granules: = 4KB, 16KB, and 64KB [1]. These granules represent the smallest range f= or a page table, and this granule changes which bits of the VA index into w= hat level of paging. On x86 this indexing was fixed an a 2 MiB page table j= ust liveds higher up in the same hierarchy. 

= While AArch64 supports all 3 granule sizes, how many granule sizes are supp= orted by a given CPU is implementation defined. So it is legal for an AArch= 64 CPU to only support 64KB pages. You can always do 4K pages on Intel, so = that is the difference. 


Thanks,

And= rew Fish

On Aug 9, 2023, at 5:35= PM, Oliver Smith-Denny <osde@linux.microsoft.com> wrote:

Hi Ard,

I just sent out = a patch (MdeModulePkg: HeapGuard: Don't Assume Pool Head
Allocated In Fi= rst Page) to fix HeapGuard GuardAlignedToTail behavior on
ARM64. However= , this raised a question of why ARM64 sets
RUNTIME_PAGE_ALLOCATION_GRANU= LARITY to 64k when X64 does not. You added
this in ProcessorBind.h for A= RM64, 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 nee= d 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 th= en all 4k pages within that 64K page
need the same memory attributes, wh= ich makes sense.

Is this runtime granularity just to satisfy that re= quirement that the
memory attributes are the same or is there an additio= nal reason that
we need to use the 64k granularity on ARM64?

In a= ny 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.

Thanks,
Oliver






_._,_._,_
Groups.io Links:

=20 You receive all messages sent to this group. =20 =20

View/Reply Online (#107660) | =20 | Mute= This Topic | New Topic
Your Subscriptio= n | Contact Group Owner | Unsubscribe [rebecca@openfw.io]

_._,_._,_
--Apple-Mail=_B647A40C-92EE-4133-8D00-A8EE1F37C9BC--