From: "Oliver Smith-Denny" <osde@linux.microsoft.com>
To: devel@edk2.groups.io, michael.d.kinney@intel.com,
"dhaval@rivosinc.com" <dhaval@rivosinc.com>,
Michael Kubacki <mikuback@linux.microsoft.com>
Subject: Re: [edk2-devel] [PATCH v3 1/1] MdeModulePkg: Add the EFI_RESOURCE_ATTRIBUTE_SPECIAL_PURPOSE attribute
Date: Tue, 11 Jun 2024 10:53:36 -0700 [thread overview]
Message-ID: <f2ed9259-426b-44a8-8f2a-cdef22f01f72@linux.microsoft.com> (raw)
In-Reply-To: <CO1PR11MB492949805AA4A98F57CE7977D2C72@CO1PR11MB4929.namprd11.prod.outlook.com>
Hi Mike,
This conversation has gotten a little fragmented across this thread and
Dhaval put up a PR I commented on :).
On 6/11/2024 10:30 AM, Michael D Kinney wrote:
> Hi Oliver,
>
> The DXE Core already has a policy to auto convert untested memory to
> tested memory if the DXE Core runs out of memory.
>
Yeah, this was my suggestion on Dhaval's PR, that we follow a similar
memory promotion with EFI_MEMORY_SP as we do with untested memory. I
was planning to write this up, but haven't gotten to it yet.
> Should we have a different memory type to allocate memory with the
> EFI_MEMORY_SP attribute?
There is a lot of ambiguity in the PI/UEFI specs around what memory
types EFI_MEMORY_SP can be. This is further complicated by the CDAT
spec which uses EDKII-isms in defining the memory type (which it
probably shouldn't).
Amongst the various groups I have been chatting with (OS folks, this
mailing thread, firmware folks), there does seem to be a consensus that
the UEFI spec, at least, needs clarification here, as currently it just
says this attribute means special memory, which of course in and of
itself means nothing :).
However, these systems don't really exist yet. As these discussions
continue, I am changing my opinion to say less is more, for now. I think
we can't do too much architecting yet without knowing what these systems
are going to look like and what OSes will expect. If we get to a point
where we have systems with only remote attached memory (or the vast
majority remote attached memory) then having a separate memory type
probably does make sense. It would also solve the unenlightened OS
case where it wouldn't use SP memory if it was a new memory type,
whereas just the attribute on EfiConventionalMemory will have an
unenlightened OS use the memory.
>
> What would be the side effects of performing general allocations from
> memory with the EFI_MEMORY_SP attribute? If there are potentially bad
> side effects, then the DXE Core should never allocate from those
> ranges and it is up to the platform to make sure there is enough normal
> memory to boot.
>
Right, I think we don't know enough yet, and so defaulting to UEFI not
using the memory and letting these systems mature a bit makes sense.
Inevitably if we build something now before these systems are fleshed
out, we will have built something that doesn't quite work.
Thanks,
Oliver
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#119553): https://edk2.groups.io/g/devel/message/119553
Mute This Topic: https://groups.io/mt/106165072/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
prev parent reply other threads:[~2024-06-11 17:53 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-18 0:57 [edk2-devel] [PATCH v3 1/1] MdeModulePkg: Add the EFI_RESOURCE_ATTRIBUTE_SPECIAL_PURPOSE attribute Michael Kubacki
2024-05-22 3:40 ` Du Lin
2024-05-22 15:03 ` Oliver Smith-Denny
2024-05-23 9:17 ` Du Lin
2024-05-23 21:05 ` Oliver Smith-Denny
2024-05-31 3:44 ` Du Lin
2024-05-31 17:00 ` Oliver Smith-Denny
2024-06-03 1:27 ` Du Lin
2024-06-10 1:44 ` Dhaval Sharma
2024-06-11 17:03 ` Oliver Smith-Denny
2024-06-11 17:30 ` Michael D Kinney
2024-06-11 17:53 ` Oliver Smith-Denny [this message]
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=f2ed9259-426b-44a8-8f2a-cdef22f01f72@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