public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Oliver Smith-Denny" <osde@linux.microsoft.com>
To: Ard Biesheuvel <ardb@kernel.org>, devel@edk2.groups.io
Cc: Leif Lindholm <quic_llindhol@quicinc.com>,
	Sami Mujawar <sami.mujawar@arm.com>,
	Liming Gao <gaoliming@byosoft.com.cn>
Subject: Re: [edk2-devel][PATCH v1 1/1] MdeModulePkg: DxeCore: Don't Guard Large Runtime Granularity Allocations
Date: Thu, 15 Feb 2024 11:55:53 -0800	[thread overview]
Message-ID: <b1c0838b-ec73-4946-9321-6161950298eb@linux.microsoft.com> (raw)
In-Reply-To: <CAMj1kXGPkDPK1b=07yquRRiXJ0C4kEVqMGbGWe05ThQBMco4jg@mail.gmail.com>

On 2/14/2024 11:50 PM, Ard Biesheuvel wrote:
> I looked at the EFI spec again, and EfiACPIReclaimMemory is not
> actually listed as a memory type that has this 64k alignment
> requirement. This makes sense, given that this memory type has no
> significance to the firmware itself, only to the OS. OTOH, reserved
> memory does appear there.
> 
> So I suggest we fix that first, and then drop any mention of
> EfiACPIReclaimMemory from this patch. At least we'll have heap guard
> coverage for ACPI table allocations on arm64 going forward.
> 
> The logic in question was added in 2007 in commit 28a00297189c, so
> this was probably the rule on Itanium, but that support is long gone.
> 

I wanted to understand this a little bit further. I do see that the spec
does not call out EfiACPIReclaimMemory as needing 64k alignment.
However, your statement that the memory type does not have have
significance to the FW, only to the OS, so we don't need the 64k
alignment is confusing to me. Isn't the 64k alignment needed only for
regions that the OS does care about? In order to read this information
at their 64k page granularity, doesn't this need to be aligned to 64k?

Or are you saying the OS can just read the 64k page(s) containing these
4k aligned EfiACPIReclaimMemory pages and then start reading at the
calculated offset from within the larger page, since these pages don't
have any pointers to outside memory, unlike image sections?

Thanks,
Oliver


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#115533): https://edk2.groups.io/g/devel/message/115533
Mute This Topic: https://groups.io/mt/104364784/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-



  parent reply	other threads:[~2024-02-15 19:55 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-15  0:34 [edk2-devel][PATCH v1 1/1] MdeModulePkg: DxeCore: Don't Guard Large Runtime Granularity Allocations Oliver Smith-Denny
2024-02-15  7:50 ` Ard Biesheuvel
2024-02-15 17:08   ` Oliver Smith-Denny
2024-02-15 17:21     ` Ard Biesheuvel
2024-02-15 19:01       ` Oliver Smith-Denny
2024-02-15 19:55   ` Oliver Smith-Denny [this message]
2024-02-15 22:17     ` Ard Biesheuvel
2024-02-15 22:39       ` Oliver Smith-Denny

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b1c0838b-ec73-4946-9321-6161950298eb@linux.microsoft.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox