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. Thanks, Oliver -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#107657): https://edk2.groups.io/g/devel/message/107657 Mute This Topic: https://groups.io/mt/100652665/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
