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

["Wu, Hao A" <hao.a.wu@intel.com>]

[-- Attachment #1: Type: text/plain, Size: 1565 bytes --]

Thanks Kun,

If my understanding is correct, this proposed library will not have any consumer until the implementation of blocking the access of unregistered memory access in MM is made.
If this is the case, my take for this sent patch is that it is a RFC to the SMM drivers owners on the library API interface.
And the actual patch for adding this library will come together will the implementation to block unregistered memory access within MM.

Best Regards,
Hao Wu

From: Kun Qin <kun.q@outlook.com>
Sent: Friday, February 5, 2021 11:11 AM
To: Wu; Wu, Hao A <hao.a.wu@intel.com>; devel@edk2.groups.io
Subject: Re: [edk2-devel] [PATCH v1 0/1] Introduce DxeMmUnblockMemoryLib Interface

Hi Hao,

As mentioned in the cover letter and in BZ-3168, VariableStandaloneMm and Tcg2Smm would need this capability to unblock certain regions in order to access either variable runtime cache or NVS region patched into ACPI table, if non-MMRAM region is blocked for access.

Just as a preview (error handling needs better polishing), the example usages for the 2 drivers above could be found here:
1. Variable DXE SMM change that unblocks runtime cache regions is posted here: https://github.com/kuqin12/mu_basecore/commit/189f90318d1256c2e72a1a67d31e3176588d8e5b
2. Tcg2Smm change example, which breaks one module into 2 and then unblock NVS region, is posted here: https://github.com/kuqin12/mu_basecore/commit/c0784f95ffe31d4d65f6230657adfc63294a693d

The change should be relatively minor but critical for the standalone Mm model.

Thanks,
Kun

[-- Attachment #2: Type: text/html, Size: 4342 bytes --]