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/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
