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

["Nhi Pham via groups.io" <nhi=os.amperecomputing.com@groups.io>]

On 9/6/2023 4:29 AM, Oliver Smith-Denny wrote:

> 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.
Thanks Oliver for the explanation. That makes sense to me.
>
> 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.
I think the dynamic PCD is supposed to not being supported in 
StandaloneMM and protocol does not fit because the Variable Flash Info 
is created in PEI for UEFI variable non-MM flow and in StMM for UEFI 
variable MM flow.
>
> 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?

Right, it is just my curiosity that I don't see any showcase for 
Variable MM + Variable Flash Info HOB in StandaloneMM.

Adding Michael Kubacki as the owner of the Variable Flash Info HOB for 
getting further input.

>
> Thanks,
> Oliver


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