From: "Wu, Hao A" <hao.a.wu@intel.com>
To: "devel@edk2.groups.io" <devel@edk2.groups.io>,
"spbrogan@outlook.com" <spbrogan@outlook.com>,
"kun.q@outlook.com" <kun.q@outlook.com>,
"Yao, Jiewen" <jiewen.yao@intel.com>
Cc: "Wang, Jian J" <jian.j.wang@intel.com>,
"Dong, Eric" <eric.dong@intel.com>, "Ni, Ray" <ray.ni@intel.com>
Subject: Re: [edk2-devel] [PATCH v1 0/1] Introduce DxeMmUnblockMemoryLib Interface
Date: Fri, 5 Feb 2021 02:52:39 +0000 [thread overview]
Message-ID: <BN8PR11MB3666BD13671E72A63364214ACAB29@BN8PR11MB3666.namprd11.prod.outlook.com> (raw)
In-Reply-To: <DM6PR19MB4010DAEFCCC854C02E1CE228C8B29@DM6PR19MB4010.namprd19.prod.outlook.com>
> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Sean
> Sent: Friday, February 5, 2021 10:37 AM
> To: devel@edk2.groups.io; Wu, Hao A <hao.a.wu@intel.com>;
> kun.q@outlook.com; Yao, Jiewen <jiewen.yao@intel.com>
> Cc: Wang, Jian J <jian.j.wang@intel.com>; Dong, Eric <eric.dong@intel.com>;
> Ni, Ray <ray.ni@intel.com>
> Subject: Re: [edk2-devel] [PATCH v1 0/1] Introduce
> DxeMmUnblockMemoryLib Interface
>
> 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.
Thanks Sean.
Sorry for a question, do you have an example for the drivers with potential
compatibility opens? It would be helpful to have a better understanding of the
purpose of this library.
Best Regards,
Hao Wu
>
> 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
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
> >
> >
> >
>
>
>
>
next prev parent reply other threads:[~2021-02-05 2:53 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-02 22:16 [PATCH v1 0/1] Introduce DxeMmUnblockMemoryLib Interface Kun Qin
2021-02-05 2:17 ` [edk2-devel] " Wu, Hao A
2021-02-05 2:37 ` Sean
2021-02-05 2:52 ` Wu, Hao A [this message]
2021-02-05 3:10 ` Kun Qin
2021-02-05 7:11 ` Wu, Hao A
2021-02-06 2:48 ` Kun Qin
2021-02-07 0:44 ` Wu, Hao A
2021-02-08 18:15 ` Kun Qin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=BN8PR11MB3666BD13671E72A63364214ACAB29@BN8PR11MB3666.namprd11.prod.outlook.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox