Thanks for the quick response. Agree that the PI and UEFI specs are vague on SP. That is also why I opted to minimize code changes to DXE core for SP support in patch https://edk2.groups.io/g/devel/message/118712.
Would it make more sense to let the caller determine if SP memory is available for UEFI via EFI resource types (e.g., EFI_RESOURCE_SYSTEM_MEMORY vs EFI_RESOURCE_MEMORY_RESERVED)? CDAT can be read in PEI phase via DOE method and CDAT is important to support CXL 2.0. I believe CDAT spec is referencing EFI_MEMORY_TYPE and Memory Attributes defined in UEFI spec section 7.2. "EfiConventionalMemory Type with EFI_MEMORY_SP Attribute" may suggest that the memory type shall be EfiConventionalMemory and the attribute shall have SP set when reporting the memory to OS. And the concern is whether this combination can still be supported if we always mark resource HOBs with SP set as EfiGcdMemoryTypeReserved. BRs, Lin, Du -----Original Message----- From: Oliver Smith-Denny <o...@linux.microsoft.com> Sent: Wednesday, May 22, 2024 11:04 PM To: devel@edk2.groups.io; Lin, Du <du....@intel.com>; mikub...@linux.microsoft.com Cc: Liming Gao <gaolim...@byosoft.com.cn>; Kinney, Michael D <michael.d.kin...@intel.com>; Ni, Ray <ray...@intel.com> Subject: Re: [edk2-devel] [PATCH v3 1/1] MdeModulePkg: Add the EFI_RESOURCE_ATTRIBUTE_SPECIAL_PURPOSE attribute On 5/21/2024 8:40 PM, Du Lin wrote: > Coherent Device Attribute Table (CDAT) specification defines a EFI memory > type and attribute "EfiConventionalMemory Type with EFI_MEMORY_SP Attribute". > Can we still support this type if assigning the GCD memory type > "EfiGcdMemoryTypeReserved" for resource HOBs with the SPECIAL_PURPOSE > attribute set? > > CDAT 1.04 specification: > https://uefi.org/sites/default/files/resources/Coherent%20Device%20Att > ribute%20Table_1.04%20published_0.pdf Thanks for pointing out the CDAT specification. I think one of the issues here is that the PI and UEFI specs are very vague on EFI_MEMORY_SP, to the point that there is no user story on it. This CDAT spec helps close some of the gap, but I think the PI and UEFI spec should be updated to be more verbose in the intended usage of this flag. Does any CDAT code exist in edk2? A naive search didn't turn up anything (and even looking at some of the CXL structures I didn't see any usage outside of the header). Is the intention that the CDAT would be read in PEI and a resource descriptor HOB created from it? If so, I agree this would prevent EfiConventionalMemory from being set. I think the CDAT spec should not be referencing EFI memory types if that is the case, because resource descriptor HOBs deal with resource types, not EFI types, so there is a mismatch. If the CDAT is read at a different time and a resource descriptor HOB is not created from it, then this should not affect it. The reason that GCD reserved type was chosen here was that the assumption for CXL or other remote memory is that UEFI would not want to use it (what if the bus went down and DXE core was allocated there). By marking it reserved with the EFI_MEMORY_SP bit set, we ensure that UEFI does not use it and that the OS knows that this is usable, but the kernel itself may not want to use it, for the same reason (or for performance). Again, the UEFI spec does not describe what memory type this should be, so if there is a different use case here, please do share. Thanks, Oliver -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#119137): https://edk2.groups.io/g/devel/message/119137 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] -=-=-=-=-=-=-=-=-=-=-=-
