[edk2-devel] [PATCH v1 2/2] StandaloneMmPkg: Fix HOB space and heap space conflicted issue

[Nhi Pham via groups.io]

On 9/6/2023 1:33 PM, Ni, Ray wrote:
> [EXTERNAL EMAIL NOTICE: This email originated from an external sender. 
> Please be mindful of safe email handling and proprietary information 
> protection practices.]
> 
> I am a bit confused.
> 
> The HOB list in standalone MM is read-only. Why could any module call 
> BuildGuidHob() to modify the HOB.
> 
> I saw Oliver mentioned something about StMM. I don't know what that is. 
> But it seems that's ARM specific. Then, I don't think it's proper to 
> modify code here for a specific arch ARM.

The HOB creation is available in the 
StandaloneMmPkg/Library/StandaloneMmHobLib/StandaloneMmHobLib.inf. If 
other architectures also use that instance, I think the issue is not 
specific to ARM.

Regards,
-Nhi
> 
> Thanks,
> Ray
> ------------------------------------------------------------------------
> *From:* devel at edk2.groups.io <devel at edk2.groups.io> on behalf of Oliver 
> Smith-Denny <osde at linux.microsoft.com>
> *Sent:* Wednesday, September 6, 2023 5:29 AM
> *To:* Nhi Pham <nhi at amperemail.onmicrosoft.com>; devel at edk2.groups.io 
> <devel at edk2.groups.io>; nhi at os.amperecomputing.com 
> <nhi at os.amperecomputing.com>; Ard Biesheuvel <ardb at kernel.org>
> *Cc:* huangming at linux.alibaba.com <huangming at linux.alibaba.com>; Sami 
> Mujawar <sami.mujawar at arm.com>; Ard Biesheuvel 
> <ardb+tianocore at kernel.org>; Yao, Jiewen <jiewen.yao at intel.com>; 
> Supreeth Venkatesh <supreeth.venkatesh at arm.com>; ming.huang- at outlook.com 
> <ming.huang- at outlook.com>
> *Subject:* Re: [edk2-devel] [PATCH v1 2/2] StandaloneMmPkg: Fix HOB 
> space and heap space conflicted issue
> On 9/4/2023 7:20 PM, Nhi Pham wrote:
>> On 9/2/2023 3:43 AM, Oliver Smith-Denny wrote:
>>> On 8/31/2023 1:20 AM, Nhi Pham via groups.io wrote:
>>>
>>> If I am understanding this correctly, this is only an issue when
>>> HOBs are created in StMM, i.e. not from HOBs that are passed in. Is this
>>> correct?
>> Yes, the issue only occurs when HOB are created in StandaloneMM by the 
>> HOB library instance 
>> StandaloneMmPkg/Library/StandaloneMmHobLib/StandaloneMmHobLib.inf
>>>
>>> If so, is HOB creation in StMM and supported use case? The only instance
>> I think it is intended to work as the CreateHob() function is implemented.
> 
> Well, that may just be a copy/paste sort of thing :).
> 
>>> a quick search turns up is the ARM StMM Core entry, where some
>>> information from TF-A is converted to HOB format. Do we have any other
>>> use cases (and curious more on this use case). My thought process would
>>> be that StMM would not create any HOBs. Depending on FW configuration,
>>> it may receive HOBs from PEI.
>> 
>> I have a use case when enabling the UEFI Variable driver running in 
>> StandaloneMM. Instead of using the PCDs, the in-memory NVRAM region is 
>> allocated **dynamically** at boot time in the StMM secure memory. Then, 
>> they will be passed into the gVariableFlashInfoHobGuid for being 
>> consumed by other variable MM drivers.
>> 
> 
> I do believe that per the PI spec, we should have HOB producer and HOB
> consumer phases, where in this case PEI (if it was the launching entity
> for StMM) is the HOB producer and StMM is the HOB producer. This is the
> same pattern the PI spec details for PEI and DXE, where DXE is not
> intended to create new HOBs, but just to consume information from the
> previous phase.
> 
> As I mentioned, there are other interfaces for passing information
> within a phase, such as protocols, dynamic PCDs, variables, etc. that
> are built for this application. I think it is useful to adhere to the
> model for HOBs (which are hand off blocks, one phase handing information
> to another phase) and that we will create more issues if we rely on
> HOB consumer phases producing HOBs.
> 
> My proposal would be to remove the HOB creation code from StMM
> completely. I believe in your use case that you are describing a dynamic
> PCD or a protocol could work to pass the information.
> 
> If we are saying that prior to your patch that HOB creation in StMM was
> completely broken, anyway, it seems that folks were not relying on this
> code?
> 
> Thanks,
> Oliver
> 
> 
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#108311): https://edk2.groups.io/g/devel/message/108311
Mute This Topic: https://groups.io/mt/89020085/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-