Re: [edk2-devel] [PATCH v1 0/1] Introduce DxeMmUnblockMemoryLib Interface

["Sean" <spbrogan@outlook.com>]

Hao wu,

I agree that for reviewing this change that would provide more confidence.
The real issue is that there is no x64 mm standalone solution that
blocks memory access in edk2 today.  So implementing this interface in 
edk2 doesn't make sense.  It would just rot with no users, validation, 
or maintenance.

The interface is needed because this is a compatibility point in other 
drivers.  Without it, those other drivers need to be forked and then 
maintained and that is not in the best interest of anyone.

To push a new standalone x64 mm model up that blocks dxe memory space is 
not small task and we are working on it and are happy to contribute it 
to edk2 / open source but it will not happen quickly.  So step 1 is get 
a compatible abstraction/interface added.  Step 2 is work to upstream 
the core modules.

We may be able to share the core modules with you if you want to see 
them for review purposes but we need more dev work before upstreaming 
the change to edk2.

Thanks
Sean




On 2/4/2021 6:17 PM, Wu, Hao A wrote:
>> -----Original Message-----
>> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Kun Qin
>> Sent: Wednesday, February 3, 2021 6:16 AM
>> To: devel@edk2.groups.io
>> Cc: Wang, Jian J <jian.j.wang@intel.com>; Wu, Hao A <hao.a.wu@intel.com>;
>> Dong, Eric <eric.dong@intel.com>; Ni, Ray <ray.ni@intel.com>; Yao, Jiewen
>> <jiewen.yao@intel.com>
>> Subject: [edk2-devel] [PATCH v1 0/1] Introduce DxeMmUnblockMemoryLib
>> Interface
>>
>> The interface proposed in this patch series intends to provide an abstraction
>> layer for DXE drivers to request certain memory regions to be accessible from
>> inside MM environment that applies total memory blockage.
>>
>> This abstraction could pave way for models such as Standalone MM to
>> manage memory resources without having knowledge of DXE memory map
>> inside MM environment.
>>
>> Example usages of it can be NVS region in Tcg2Smm and runtime variable
>> cache regions in VariableSmmRuntimeDxe.
> 
> 
> My thought is that it might be more helpful if the whole implementation proposal
> to address BZ-3168 can be provided before reviewing the interfaces for the new
> library (or the library itself).
> 
> Hello Jiewen,
> 
> Do you have comments on the approach on implementing the BZ-3168
> (https://bugzilla.tianocore.org/show_bug.cgi?id=3168) feature?
> Thanks in advance.
> 
> Best Regards,
> Hao Wu
> 
> 
>>
>> Patch v1 branch: https://github.com/kuqin12/edk2/tree/unblock_mem_v1
>>
>> Cc: Jian J Wang <jian.j.wang@intel.com>
>> Cc: Hao A Wu <hao.a.wu@intel.com>
>> Cc: Eric Dong <eric.dong@intel.com>
>> Cc: Ray Ni <ray.ni@intel.com>
>> Cc: Jiewen Yao <jiewen.yao@intel.com>
>>
>> Kun Qin (1):
>>    MdeModulePkg: DxeMmUnblockMemoryLib: Added definition and null
>>      instance
>>
>>
>> MdeModulePkg/Library/DxeMmUnblockMemoryLib/DxeMmUnblockMemo
>> ryLibNull.c   | 40 ++++++++++++++++++++
>>   MdeModulePkg/Include/Library/DxeMmUnblockMemoryLib.h                     |
>> 40 ++++++++++++++++++++
>>
>> MdeModulePkg/Library/DxeMmUnblockMemoryLib/DxeMmUnblockMemo
>> ryLibNull.inf | 29 ++++++++++++++
>>   MdeModulePkg/MdeModulePkg.dec                                            |  5 +++
>>   MdeModulePkg/MdeModulePkg.dsc                                            |  2 +
>>   5 files changed, 116 insertions(+)
>>   create mode 100644
>> MdeModulePkg/Library/DxeMmUnblockMemoryLib/DxeMmUnblockMemo
>> ryLibNull.c
>>   create mode 100644
>> MdeModulePkg/Include/Library/DxeMmUnblockMemoryLib.h
>>   create mode 100644
>> MdeModulePkg/Library/DxeMmUnblockMemoryLib/DxeMmUnblockMemo
>> ryLibNull.inf
>>
>> --
>> 2.30.0.windows.1
>>
>>
>>
>>
>>
> 
> 
> 
> 
> 
>