Date   

回复: [edk2-devel] 回复: [Patch edk2-platforms V2] Intel/BoardModulePkg: sort load option in the first boot

gaoliming
 

Zhiguang:
This is the common platform usage. I suggest to apply the same solution. My solution is to define this PCD PcdBootState in MdeModulePkg.dec, and add MdeModule.dsc.inc file that defines this PCD as DynamicHii PCD, platform DSC includes MdeModule.dsc.inc file, platform modules consume this PCD (set/get).

Thanks
Liming

-----邮件原件-----
发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 Zhiguang Liu
发送时间: 2021年3月16日 9:57
收件人: devel@edk2.groups.io; gaoliming@byosoft.com.cn; Ni, Ray
<ray.ni@intel.com>
抄送: Dong, Eric <eric.dong@intel.com>; Desimone, Nathaniel L
<nathaniel.l.desimone@intel.com>; Agyeman, Prince
<prince.agyeman@intel.com>; Gao, Zhichao <zhichao.gao@intel.com>
主题: Re: [edk2-devel] 回复: [Patch edk2-platforms V2]
Intel/BoardModulePkg: sort load option in the first boot

Hi Liming,

Thanks for the comments. This patch is merged before this comment, but I can
still send another patch to modify if needed.

However, I think the implement in this patch is more simple.
The implement in QuarkPlatformPkg need changes in inf, dec and dsc files,
and is not as intuitive as just getting and setting a variable.
It may be simpler if the implements can reuse a same DynamicHiiPcd, do you
think it is possible?
If I misunderstand anything, please correct me.

Thanks
Zhiguang

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of
gaoliming
Sent: Monday, March 15, 2021 9:36 AM
To: Ni, Ray <ray.ni@intel.com>; Liu, Zhiguang <zhiguang.liu@intel.com>;
devel@edk2.groups.io
Cc: Dong, Eric <eric.dong@intel.com>; Desimone, Nathaniel L
<nathaniel.l.desimone@intel.com>; Agyeman, Prince
<prince.agyeman@intel.com>; Gao, Zhichao <zhichao.gao@intel.com>
Subject: [edk2-devel] 回复: [Patch edk2-platforms V2]
Intel/BoardModulePkg: sort load option in the first boot

Zhiguang:
I see QuarkPlatformPkg uses PCD
gQuarkPlatformTokenSpaceGuid.PcdBootState
to decide whether current boot is the first boot or not.
This PCD is configured as DynamicHiiPcd, and be set in
Platform\Intel\QuarkPlatformPkg\Library\PlatformBootManagerLib\Platfor
mBootM
anager.c

Can you use the same solution in Intel BoardModulePkg?

Thanks
Liming
-----邮件原件-----
发件人: Ni, Ray <ray.ni@intel.com>
发送时间: 2021年3月10日 17:56
收件人: Liu, Zhiguang <zhiguang.liu@intel.com>; devel@edk2.groups.io
抄送: Dong, Eric <eric.dong@intel.com>; Liming Gao
<gaoliming@byosoft.com.cn>; Desimone, Nathaniel L
<nathaniel.l.desimone@intel.com>; Agyeman, Prince
<prince.agyeman@intel.com>; Gao, Zhichao <zhichao.gao@intel.com>
主题: RE: [Patch edk2-platforms V2] Intel/BoardModulePkg: sort load
option in the first boot

1. DataSIze should be set to sizeof (BOOLEAN) before calling
GetVariable()

+ Status = gRT->GetVariable (
+ L"IsFirstBoot",
2. Can you please define a macro in this C file for IsFirstBoot string?
e.g.: #define IS_FIRST_BOOT_VAR_NAME L"IsFirstBoot"

+ if (IsFirstBoot == TRUE) {
3. Please remove "== TRUE". Just use "If (IsFirstBoot)".

+ L"IsFirstBoot",
4. Please use the macro defined as above.


+ &gEfiCallerIdGuid,

+ EFI_VARIABLE_NON_VOLATILE |
EFI_VARIABLE_RUNTIME_ACCESS |
EFI_VARIABLE_BOOTSERVICE_ACCESS,

5. Please remove "EFI_VARIABLE_RUNTIME_ACCESS".

+ 1,
6. Please use sizeof (BOOLEAN) instead of "1".









[PATCH] SecurityPkg/Tcg2Config: hide PCR Bank SHA1 checkbox

Qi Zhang
 

wrap SHA1 related by DISABLE_SHA1_DEPRECATED_INTERFACES.

Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Qi Zhang <qi1.zhang@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Signed-off-by: Qi Zhang <qi1.zhang@intel.com>
---
SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigImpl.c | 2 ++
1 file changed, 2 insertions(+)

diff --git a/SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigImpl.c b/SecurityPkg/Tcg/=
Tcg2Config/Tcg2ConfigImpl.c
index 2946f95db0..81a4d3fa6a 100644
--- a/SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigImpl.c
+++ b/SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigImpl.c
@@ -710,9 +710,11 @@ SetConfigInfo (
)=0D
{=0D
switch (TpmAlgHash) {=0D
+#ifndef DISABLE_SHA1_DEPRECATED_INTERFACES=0D
case TPM_ALG_SHA1:=0D
Tcg2ConfigInfo->Sha1Supported =3D TRUE;=0D
break;=0D
+#endif=0D
case TPM_ALG_SHA256:=0D
Tcg2ConfigInfo->Sha256Supported =3D TRUE;=0D
break;=0D
--=20
2.26.2.windows.1


Re: [PATCH] ShellPkg/Library: Fix bug in Pci.c

Gao, Zhichao
 

Hi Ian/Vincent,

Sorry, I just notice the NextCapabilityOffset starts from base address of the PCI config space. So the comment I give in previous patch is incorrect.
And refer the PCIe spec, its valid value should be 0x100 to (0x1000 - sizeof (PCI_EXP_EXT_HDR)) or 0x0 (to terminate the list of capabilities).

The title of the patch is too common. The title should give a tiny description of the change.
Here is an example:
ShellPkg/Pci: Add valid check for PCI extended config space parser

If you have a better title, just update your own style.

Thanks,
Zhichao

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of IanX
Kuo
Sent: Saturday, April 10, 2021 1:35 AM
To: devel@edk2.groups.io
Cc: Ke, VincentX <vincentx.ke@intel.com>
Subject: [edk2-devel] [PATCH] ShellPkg/Library: Fix bug in Pci.c

From: VincentX Ke <vincentx.ke@intel.com>

Bugzilla: 3262 (https://bugzilla.tianocore.org/show_bug.cgi?id=3262)

No need to print PCIe details while CapabilityId is 0xFFFF.
Limit the NextCapabilityOffset value to AllocatePool() memory.

Signed-off-by: VincentX Ke <vincentx.ke@intel.com>
---
ShellPkg/Library/UefiShellDebug1CommandsLib/Pci.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/ShellPkg/Library/UefiShellDebug1CommandsLib/Pci.c
b/ShellPkg/Library/UefiShellDebug1CommandsLib/Pci.c
index a2f04d8db5..9ebf1c26ef 100644
--- a/ShellPkg/Library/UefiShellDebug1CommandsLib/Pci.c
+++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/Pci.c
@@ -2038,12 +2038,14 @@ LocatePciCapability (
@param[in] PciExpressCap PCI Express capability buffer. @param[in]
ExtendedConfigSpace PCI Express extended configuration space.+
@param[in] ExtendedConfigSize PCI Express extended configuration size.
@param[in] ExtendedCapability PCI Express extended capability ID to
explain. **/ VOID PciExplainPciExpress ( IN PCI_CAPABILITY_PCIEXP
*PciExpressCap, IN UINT8 *ExtendedConfigSpace,+ IN
UINTN ExtendedConfigSize, IN CONST UINT16
ExtendedCapability ); @@ -2921,6 +2923,7 @@ ShellCommandRunPci (
PciExplainPciExpress ( (PCI_CAPABILITY_PCIEXP *) ((UINT8 *)
&ConfigSpace + PcieCapabilityPtr), ExtendedConfigSpace,+
ExtendedConfigSize, ExtendedCapability ); }@@ -5698,12
+5701,14 @@ PrintPciExtendedCapabilityDetails(
@param[in] PciExpressCap PCI Express capability buffer. @param[in]
ExtendedConfigSpace PCI Express extended configuration space.+
@param[in] ExtendedConfigSize PCI Express extended configuration size.
@param[in] ExtendedCapability PCI Express extended capability ID to
explain. **/ VOID PciExplainPciExpress ( IN PCI_CAPABILITY_PCIEXP
*PciExpressCap, IN UINT8 *ExtendedConfigSpace,+ IN
UINTN ExtendedConfigSize, IN CONST UINT16
ExtendedCapability ) {@@ -5786,7 +5791,7 @@ PciExplainPciExpress (
} ExtHdr = (PCI_EXP_EXT_HDR*)ExtendedConfigSpace;- while (ExtHdr-
CapabilityId != 0 && ExtHdr->CapabilityVersion != 0) {+ while (ExtHdr-
CapabilityId != 0 && ExtHdr->CapabilityVersion != 0 && ExtHdr-
CapabilityId != 0xFFFF) { // // Process this item //@@ -5800,7 +5805,7
@@ PciExplainPciExpress (
// // Advance to the next item if it exists //- if (ExtHdr-
NextCapabilityOffset != 0) {+ if (ExtHdr->NextCapabilityOffset != 0 &&
(ExtHdr->NextCapabilityOffset <= (UINT32)(ExtendedConfigSize - sizeof
(PCI_EXP_EXT_HDR)))) { ExtHdr =
(PCI_EXP_EXT_HDR*)(ExtendedConfigSpace + ExtHdr->NextCapabilityOffset
- EFI_PCIE_CAPABILITY_BASE_OFFSET); } else { break;--
2.18.0.windows.1



-=-=-=-=-=-=
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72862): https://edk2.groups.io/g/devel/message/72862
Mute This Topic: https://groups.io/mt/81372175/1768756
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [zhichao.gao@intel.com]
-=-=-=-=-=-=


Re: [PATCH 1/2] UefiCpuPkg/CpuDxe: Rename variables to follow EDKII coding standard

Ni, Ray
 

(1) I think "mGdtTemplate" would be a better name than "gGdtTemplate". I
think the "g" prefix is used when an object is identical for all
firmware modules (such as named GUIDs, for example).
Agree! I will change in v2.



(2) I think the last hunk does not belong in this patch -- more
precisely, I *disagree* with the last hunk. Inserting a space in the
middle of a typecast, after the parenthesized typename, is a bad
practice in edk2; it is error prone and suggests that typecasts have low
binding power (when in reality they have almost the strongest binding).
I double checked the edk2 coding standard and did find a rule for this.
That might be just my personal preference. Since I need your Ack or Rb, I will remove
this change in v2.


回复: [edk2-devel] 回复: [PATCH 1/1] MdePkg/UefiLib: Correct the arguments passed to IsLanguageSupported()

gaoliming
 

-----邮件原件-----
发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 gaoliming
发送时间: 2021年3月9日 9:31
收件人: 'Chandramohan Akula' <chandramohan.akula@broadcom.com>;
devel@edk2.groups.io
抄送: 'Michael D Kinney' <michael.d.kinney@intel.com>; 'Zhiguang Liu'
<zhiguang.liu@intel.com>
主题: [edk2-devel] 回复: [PATCH 1/1] MdePkg/UefiLib: Correct the
arguments passed to IsLanguageSupported()

Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>

-----邮件原件-----
发件人: Chandramohan Akula <chandramohan.akula@broadcom.com>
发送时间: 2021年3月8日 11:03
收件人: devel@edk2.groups.io
抄送: Chandramohan Akula <chandramohan.akula@broadcom.com>;
Michael D Kinney <michael.d.kinney@intel.com>; Liming Gao
<gaoliming@byosoft.com.cn>; Zhiguang Liu <zhiguang.liu@intel.com>
主题: [PATCH 1/1] MdePkg/UefiLib: Correct the arguments passed to
IsLanguageSupported()

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3211

Correct the arguments passed to the IsLanguageSupported() function in
AddUnicodeString2() and LookupUnicodeString2() as expected by the
function

Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Signed-off-by: Chandramohan Akula
<chandramohan.akula@broadcom.com>
---
MdePkg/Library/UefiLib/UefiLib.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/MdePkg/Library/UefiLib/UefiLib.c
b/MdePkg/Library/UefiLib/UefiLib.c
index 835218f9824f..b6a33a0a488e 100644
--- a/MdePkg/Library/UefiLib/UefiLib.c
+++ b/MdePkg/Library/UefiLib/UefiLib.c
@@ -839,7 +839,7 @@ LookupUnicodeString2 (
SupportedLanguages += 3;

}

} else {

- Found = !IsLanguageSupported(Language, SupportedLanguages);

+ Found = !IsLanguageSupported(SupportedLanguages, Language);

}





@@ -1133,7 +1133,7 @@ AddUnicodeString2 (
SupportedLanguages += 3;

}

} else {

- Found = !IsLanguageSupported(Language, SupportedLanguages);

+ Found = !IsLanguageSupported(SupportedLanguages, Language);

}

//

// If Language is not a member of SupportedLanguages, then return
EFI_UNSUPPORTED

--
2.27.0






TianoCore Bug Triage - APAC / NAMO - Tue, 03/16/2021 6:30pm-7:30pm #cal-reminder

devel@edk2.groups.io Calendar <devel@...>
 

Reminder: TianoCore Bug Triage - APAC / NAMO

When: Tuesday, 16 March 2021, 6:30pm to 7:30pm, (GMT-07:00) America/Los Angeles

Where:https://meetingsamer34.webex.com/meetingsamer34/j.php?MTID=mb96c5bd411bd010e1e6d43a6f6c65f45

View Event

Organizer: Liming Gao gaoliming@...

Description:

TianoCore Bug Triage - APAC / NAMO

Hosted by Liming Gao

 

https://meetingsamer34.webex.com/meetingsamer34/j.php?MTID=mb96c5bd411bd010e1e6d43a6f6c65f45

Wednesday, Jan 20, 2021 10:30 am | 50 minutes | (UTC+08:00) Beijing, Chongqing, Hong Kong, Urumqi

Occurs every Wednesday effective 1/20/2021 from 10:30 AM to 11:20 AM, (UTC+08:00) Beijing, Chongqing, Hong Kong, Urumqi

Meeting number: 126 867 1239

Password: ZhqYQunw246 (94797869 from video systems)

d8edc6c9604344b08f727b4bf054eaac_20210120T023000Z

 

Join by video system

Dial 1268671239@...

You can also dial 173.243.2.68 and enter your meeting number.

 

Join by phone

Use VoIP only


回复: [PATCH] MdePkg: use CpuPause() in CpuDeadLoop()

gaoliming
 

Ankur:
Can you give the detail usage for the lower power state when enter into
CpuDeadLoop()?

Thanks
Liming

-----邮件原件-----
发件人: Ankur Arora <ankur.a.arora@oracle.com>
发送时间: 2021年3月17日 6:59
收件人: devel@edk2.groups.io
抄送: Ankur Arora <ankur.a.arora@oracle.com>; Liming Gao
<gaoliming@byosoft.com.cn>; Michael D Kinney
<michael.d.kinney@intel.com>
主题: [PATCH] MdePkg: use CpuPause() in CpuDeadLoop()

Use CpuPause() to allow the CPU to go into a lower power state
state while we spin wait.

Cc: Liming Gao <gaoliming@byosoft.com.cn>
Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
---
MdePkg/Library/BaseLib/CpuDeadLoop.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/MdePkg/Library/BaseLib/CpuDeadLoop.c
b/MdePkg/Library/BaseLib/CpuDeadLoop.c
index 9e110cacbc96..3cd304351a65 100644
--- a/MdePkg/Library/BaseLib/CpuDeadLoop.c
+++ b/MdePkg/Library/BaseLib/CpuDeadLoop.c
@@ -28,5 +28,7 @@ CpuDeadLoop (
{
volatile UINTN Index;

- for (Index = 0; Index == 0;);
+ for (Index = 0; Index == 0;) {
+ CpuPause();
+ }
}
--
2.9.3


Re: [edk2-discuss] Google Summer of Code Interested Student

Nate DeSimone
 

Hi Laszlo,

-----Original Message-----
From: discuss@edk2.groups.io <discuss@edk2.groups.io> On Behalf Of
Laszlo Ersek
Sent: Tuesday, March 16, 2021 8:24 AM
To: Desimone, Nathaniel L <nathaniel.l.desimone@intel.com>
Cc: discuss@edk2.groups.io; cadenkline9@gmail.com; edk2-devel-groups-io
<devel@edk2.groups.io>; Ard Biesheuvel (TianoCore)
<ardb+tianocore@kernel.org>; Leif Lindholm (Nuvia address)
<leif@nuviainc.com>
Subject: Re: [edk2-discuss] Google Summer of Code Interested Student

Hi Nate,

(adding Leif and Ard)

On 03/13/21 03:52, Desimone, Nathaniel L wrote:
I've created a new wiki page for this task with all the information I
have gathered thus far. I've done some more experimentation and found
that there are several newer terminal emulators that don't support DEC
Special Graphics so I've reduced the number of modes where DEC Special
Graphics should be preferred. Laszlo, if you could take a look at the
terminal type matrix I created that would be very helpful.

https://github.com/tianocore/tianocore.github.io/wiki/Tasks-Terminal-d
river-improvements
(

My background:

I settled on plain (non-UTF-8) xterm around 1998, and have been using it
ever since. Whenever something was off, I always tried to hammer the
application into conformance with my particular xterm setup, rather than the
other way around. I also have some quirky terminal settings -- for me,
"backspace" generates ^H / keycode 22 (stty sets erase to ^H), "delete"
generates keycode 119, and there's no "rubout". I still don't use UTF-8 (I use
latin2).

)

* Regarding ArmVirtPkg, I stick with the default TTY_TERMINAL=FALSE
setting (which means VT-100). Using that setting, I see the following
kind of "ASCII approximation" for box drawing:

/------------------------------------------------------------------------------\
| Boot Manager |
\------------------------------------------------------------------------------/

I'm really happy with this, as I don't care much for nice-looking
boxes; instead I prefer portability.

(NB: this seems to disagree with your "Current Behavior (Which is
wrong)" line for VT100, as it suggests CP437. That's not what I'm
seeing with VT100.)
I went back and looked at this is more detail, and I missed the following critical detail:

if (TerminalDevice->TerminalType != TerminalTypePcAnsi) {
GraphicChar = AsciiChar;
}

Yes you are totally right! I've adjusted the table to reflect this behavior.


TTY_TERMINAL=TRUE would mainly affect backspace / delete I think -- as
far as I recall, that's why I asked Roy not to make TTY_TERMINAL=TRUE
the default, in 2015:

http://mid.mail-archive.com/555458DB.3090602@redhat.com
http://mid.mail-
archive.com/CAFECyb_E+bGZt5xv7QhRqyD0jX=AzoEMw7VW_tjZr+E=sQf8w
w@mail.gmail.com

(I'd like to CC Roy, but I can't tell if he's now working for Linaro,
Cavium, HPE, Marvell, or another company.)

* Regarding OvmfPkg, currently PC_ANSI is hard-coded, and for me it
looks like this:


ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄż
ł Boot Manager ł

ŔÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄŮ

Obviously I'd much prefer if I got the simple ASCII approximation here
as well.

* Whether VT100 and/or PC_ANSI and/or TTY_TERM are *officially*
supposed
to use DEC Special Graphics, I can't tell.
The UEFI spec doesn't read on this at all, even though it describes VT100 and VT100+ as separate modes... it doesn't say how they differ. I agree with you that it seems reasonable for VT100 to keep character output to strict ASCII only... that way the "+" in VT100+ actually means something. I've updated the wiki accordingly.

I'd advocate for the default to be switched to VT_UTF8. I really don't think you will run into many terminal emulators that don't implement UTF-8 anymore, XTerm included. Those who want pure ASCII output can switch to VT100.


I know what my preferences are:

- the current BackSpace and Delete mappings (which work fine for me
with both VT100 and PC_ANSI, but *not* with TTY_TERM),

- and the most primitive ASCII mapping (no special graphics, no UTF-8
sequences, etc). I really like a super dumb terminal, where taking
simple "ASCII screenshots" (and pasting them into plaintext emails!)
is *trivial*.

... Looking at your "Expected Behavior" table, there is only one line
left with "poor man's ASCII" -- namely, TTY_TERM. Unfortunately,
TTY_TERM breaks my BackSpace / Delete settings :(

* In summary, I'd prefer if (a) VT100 stayed as-is (using "poor man's
ASCII", as seen in ArmVirtPkg), and (b) if OVMF used *that* VT100,
rather than PC_ANSI, by default.

Thanks!
Laszlo





[PATCH] MdePkg: use CpuPause() in CpuDeadLoop()

Ankur Arora
 

Use CpuPause() to allow the CPU to go into a lower power state
state while we spin wait.

Cc: Liming Gao <gaoliming@byosoft.com.cn>
Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
---
MdePkg/Library/BaseLib/CpuDeadLoop.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/MdePkg/Library/BaseLib/CpuDeadLoop.c b/MdePkg/Library/BaseLib/CpuDeadLoop.c
index 9e110cacbc96..3cd304351a65 100644
--- a/MdePkg/Library/BaseLib/CpuDeadLoop.c
+++ b/MdePkg/Library/BaseLib/CpuDeadLoop.c
@@ -28,5 +28,7 @@ CpuDeadLoop (
{
volatile UINTN Index;

- for (Index = 0; Index == 0;);
+ for (Index = 0; Index == 0;) {
+ CpuPause();
+ }
}
--
2.9.3


Re: [PATCH v2 1/1] EmbeddedPkg: fix guid for PrePiHobLib

Ard Biesheuvel
 

On Tue, 16 Mar 2021 at 20:53, Matthew Carlson <matthewfcarlson@gmail.com> wrote:

Currently there is a duplicate GUID shared by two INFs.
This rolls the INF for the PrePiHobLib.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2381

Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: devel@edk2.groups.io

Signed-off-by: Matthew Carlson <matthewfcarlson@gmail.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>

Thanks for the patch

PR submitted, this should appear on master shortly.


---
EmbeddedPkg/Library/PrePiHobLib/PrePiHobLib.inf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/EmbeddedPkg/Library/PrePiHobLib/PrePiHobLib.inf b/EmbeddedPkg/Library/PrePiHobLib/PrePiHobLib.inf
index b2c4c04bfd76..55de4511fc98 100644
--- a/EmbeddedPkg/Library/PrePiHobLib/PrePiHobLib.inf
+++ b/EmbeddedPkg/Library/PrePiHobLib/PrePiHobLib.inf
@@ -12,7 +12,7 @@
[Defines]
INF_VERSION = 0x00010005
BASE_NAME = PrePiHobLib
- FILE_GUID = 1F3A3278-82EB-4C0D-86F1-5BCDA5846CB2
+ FILE_GUID = AEF7D85A-6A91-4ACD-9A28-193DEFB325FB
MODULE_TYPE = BASE
VERSION_STRING = 1.0
LIBRARY_CLASS = HobLib
--
2.30.1.windows.1


[PATCH v2 1/1] EmbeddedPkg: fix guid for PrePiHobLib

Matthew Carlson
 

Currently there is a duplicate GUID shared by two INFs.
This rolls the INF for the PrePiHobLib.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2381

Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: devel@edk2.groups.io

Signed-off-by: Matthew Carlson <matthewfcarlson@gmail.com>
---
EmbeddedPkg/Library/PrePiHobLib/PrePiHobLib.inf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/EmbeddedPkg/Library/PrePiHobLib/PrePiHobLib.inf b/EmbeddedPkg/Library/PrePiHobLib/PrePiHobLib.inf
index b2c4c04bfd76..55de4511fc98 100644
--- a/EmbeddedPkg/Library/PrePiHobLib/PrePiHobLib.inf
+++ b/EmbeddedPkg/Library/PrePiHobLib/PrePiHobLib.inf
@@ -12,7 +12,7 @@
[Defines]
INF_VERSION = 0x00010005
BASE_NAME = PrePiHobLib
- FILE_GUID = 1F3A3278-82EB-4C0D-86F1-5BCDA5846CB2
+ FILE_GUID = AEF7D85A-6A91-4ACD-9A28-193DEFB325FB
MODULE_TYPE = BASE
VERSION_STRING = 1.0
LIBRARY_CLASS = HobLib
--
2.30.1.windows.1


[PATCH v2 0/1] Fix GUID in PrePiHobLib

Matthew Carlson
 

Currently there is a duplicate GUID shared by two INFs.
This rolls the INF for the PrePiHobLib.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2381

Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: devel@edk2.groups.io

Matthew Carlson (1):
EmbeddedPkg: fix guid for PrePiHobLib

EmbeddedPkg/Library/PrePiHobLib/PrePiHobLib.inf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--
2.30.1.windows.1


Re: [PATCH 1/1] MdeModulePkg/VariableRuntimeDxe: avoid double VA conversion of FVB protocol

Samer El-Haj-Mahmoud
 

Late to the party, but I confirm that this fixes the SetVariable() runtime calls on Solid Run Honeycomb LX2 (confirmed from multiple distros)

Tested-by: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Laszlo
Ersek via groups.io
Sent: Tuesday, March 16, 2021 11:58 AM
To: Ard Biesheuvel <ardb@kernel.org>; devel@edk2.groups.io
Cc: liming.gao@intel.com; Jon (jon@solid-run.com) <jon@solid-run.com>;
leif@nuviainc.com
Subject: Re: [edk2-devel] [PATCH 1/1] MdeModulePkg/VariableRuntimeDxe:
avoid double VA conversion of FVB protocol

On 03/13/21 00:05, Ard Biesheuvel wrote:
For historical reasons, the VariableRuntimeDxe performs virtual
address conversion on the FVB protocol member pointers of the protocol
instance that backs the EFI variable store. However, the driver that
produces the actual instance should be doing this, as it is the owner,
and provides the actual implementation of those methods.

Unfortunately, we cannot simply change this: existing drivers may rely
on this behavior, and so the variable driver should take care to only
convert the pointers when necessary, but leave them alone when the
owner is taking care of this.

The virtual address switch event can be delivered in arbitrary order,
and so we should take care of this in a way that does not rely on
whether this driver converts its pointers either before or after the
owner of the FVB protocol receives the event.

So let's not convert the pointers at all when the event is delivered,
but record the converted addresses in a shadow FVB protocol. This way,
we can check when the variable driver is invoked at runtime whether
the switch has occurred or not, and perform the switch if it hasn't.

Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
Build tested only.

MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c | 50
+++++++++++++++++---
1 file changed, 43 insertions(+), 7 deletions(-)

diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c
b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c
index 0fca0bb2a9b5..3d83ac4452ee 100644
--- a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c
+++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c
@@ -37,6 +37,8 @@ EDKII_VAR_CHECK_PROTOCOL mVarCheck
= { VarCheckRegis
VarCheckVariablePropertySet,

VarCheckVariablePropertyGet };

+STATIC EFI_FIRMWARE_VOLUME_BLOCK_PROTOCOL
mFvbProtocolShadow;
+
/**
Some Secure Boot Policy Variable may update following other variable
changes(SecureBoot follows PK change, etc).
Record their initial State when variable write service is ready.
@@ -105,8 +107,26 @@ AcquireLockOnlyAtBootTime (
IN EFI_LOCK *Lock
)
{
(1) Why is AcquireLockOnlyAtBootTime() the best place to add this?

(Considering especially the leading comment, "This is a temperary function
that will be removed when EfiAcquireLock() in UefiLib can handle the call in
UEFI Runtimer driver in RT phase".)

Obviously, I don't want to create more work for you! I just feel that, if this is
not the best place, we shouldn't overload this function with a new
responsibility.

+ EFI_FIRMWARE_VOLUME_BLOCK_PROTOCOL *FvbInstance;
+
if (!AtRuntime ()) {
EfiAcquireLock (Lock);
+ } else {
+ //
+ // Check whether we need to swap in the converted pointer values for
the
+ // FVB protocol methods
+ //
+ FvbInstance = mVariableModuleGlobal->FvbInstance;
+ if (FvbInstance != NULL &&
+ FvbInstance->GetBlockSize != mFvbProtocolShadow.GetBlockSize)
+ {
(2) It occurs to me that the following pattern (in a single-threaded
environment):

if (a != b) {
a = b;
}

is just:

a = b;

(the small CPU cost notwithstanding).

And that puts this patch in a bit different light: it's not that we may or may
not convert. Instead, we *always* convert, the question is *when* we apply
the result of the conversion.

Functionally, there is no difference, but to me mentally, there'd be a
difference, if we said "delay applying the runtime conversion until first call".

Anyway... just wanted to highlight this: we could drop the GetBlockSize
funcptr comparison. But, we don't have to.

Given the reviews from Liming and Hao -- and thank you in the first place for
writing the patch! --, I won't really ask for a v2. I'd just somehow prefer the
compat logic to be elsewhere, rather than in AcquireLockOnlyAtBootTime().
In the first place, I'm not clear what we currently use
AcquireLockOnlyAtBootTime() for.

Up to the maintainers to decide whether this justifies v2. If not:

Acked-by: Laszlo Ersek <lersek@redhat.com>

Thanks
Laszlo

+ FvbInstance->GetBlockSize = mFvbProtocolShadow.GetBlockSize;
+ FvbInstance->GetPhysicalAddress =
mFvbProtocolShadow.GetPhysicalAddress;
+ FvbInstance->GetAttributes = mFvbProtocolShadow.GetAttributes;
+ FvbInstance->SetAttributes = mFvbProtocolShadow.SetAttributes;
+ FvbInstance->Read = mFvbProtocolShadow.Read;
+ FvbInstance->Write = mFvbProtocolShadow.Write;
+ FvbInstance->EraseBlocks = mFvbProtocolShadow.EraseBlocks;
+ }
}
}

@@ -247,13 +267,22 @@ VariableClassAddressChangeEvent (
UINTN Index;

if (mVariableModuleGlobal->FvbInstance != NULL) {
- EfiConvertPointer (0x0, (VOID **) &mVariableModuleGlobal-
FvbInstance->GetBlockSize);
- EfiConvertPointer (0x0, (VOID **) &mVariableModuleGlobal-
FvbInstance->GetPhysicalAddress);
- EfiConvertPointer (0x0, (VOID **) &mVariableModuleGlobal-
FvbInstance->GetAttributes);
- EfiConvertPointer (0x0, (VOID **) &mVariableModuleGlobal-
FvbInstance->SetAttributes);
- EfiConvertPointer (0x0, (VOID **) &mVariableModuleGlobal-
FvbInstance->Read);
- EfiConvertPointer (0x0, (VOID **) &mVariableModuleGlobal-
FvbInstance->Write);
- EfiConvertPointer (0x0, (VOID **) &mVariableModuleGlobal-
FvbInstance->EraseBlocks);
+ //
+ // This module did not produce the FVB protocol instance that provides
the
+ // variable store, so it should not be the one performing the pointer
+ // conversion on its members. However, some FVB protocol
implementations
+ // may rely on this behavior, which was present in older versions of this
+ // driver, so we need to perform the conversion if the protocol
producer
+ // fails to do so. So let's record the converted values now, and swap
them
+ // in later if they haven't changed values.
+ //
+ EfiConvertPointer (0x0, (VOID
**)&mFvbProtocolShadow.GetBlockSize);
+ EfiConvertPointer (0x0, (VOID
**)&mFvbProtocolShadow.GetPhysicalAddress);
+ EfiConvertPointer (0x0, (VOID
**)&mFvbProtocolShadow.GetAttributes);
+ EfiConvertPointer (0x0, (VOID
**)&mFvbProtocolShadow.SetAttributes);
+ EfiConvertPointer (0x0, (VOID **)&mFvbProtocolShadow.Read);
+ EfiConvertPointer (0x0, (VOID **)&mFvbProtocolShadow.Write);
+ EfiConvertPointer (0x0, (VOID
+ **)&mFvbProtocolShadow.EraseBlocks);
EfiConvertPointer (0x0, (VOID **) &mVariableModuleGlobal-
FvbInstance);
}
EfiConvertPointer (0x0, (VOID **)
&mVariableModuleGlobal->PlatformLangCodes);
@@ -454,6 +483,13 @@ FtwNotificationEvent (
}
mVariableModuleGlobal->FvbInstance = FvbProtocol;

+ //
+ // Store the boot time values of the function pointers so we can
+ compare // them later. This is needed to avoid double conversion
+ during the call // to SetVirtualAddressMap.
+ //
+ CopyMem (&mFvbProtocolShadow, FvbProtocol, sizeof
+ mFvbProtocolShadow);
+
//
// Mark the variable storage region of the FLASH as RUNTIME.
//



IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.


Re: [RFC PATCH 00/14] Firmware Support for Fast Live Migration for AMD SEV

Singh, Brijesh <brijesh.singh@...>
 

[AMD Official Use Only - Internal Distribution Only]

Hi Yao,

In the current proposal the accelerated migration does not involve the PSP. I will let Tobin and Dov comment on how things works in current prototype.

If PSP was involved in the migration, then flow would be like this:

- During the guest creation time two things will happen (both source and destination VMs go through this step)
a) create a random VM encryption key (VEK) -- the key is used for encrypting the guest pages.
b) guest owner supplies a session blob to the PSP. The session blob contains transport encryption key (TEK). The TEK is used to encrypt all the confidential information exchanged between the PSP and the external entities such as a guest owner or another PSP.

During the migration
i) source VMM asks PSP to get a page that can be migrated.
ii) source PSP encrypt the guest pages using the TEK
iii) source VMM write the encrypted pages on the wire
iv) destination VMM will call PSP to put the received encrypted page in the guest memory.
v) destination PSP will decrypt the received pages using TEK, then encrypt it using the VEK before copying it to the guest memory.

As you see in the flow, the PSP's never share the keys. The TEK is wrapped in the session blob provided to the PSP on launch.

You are correct that the SEV/SEV-ES does not support querying the attestation report after the guest boot. All the attestation need to be done during the guest creation time.

With SEV-SNP, a guest OS/BIOS can call PSP to get the attestation report. The SEV-SNP, provides a method in which the guest owner can provide an IMI (Initial migration agent) through the launch process. The IMI will be measured separately and stored in IMD (Initial Migration Digest). When source VMM is ready to migrate it will use a PSP command (VM_EXPORT) to export the data from source to destination. The export will contains information about IMD etc. The destination VMM will use the PSP command (ABSORB) to import the incoming data. During the absorb process the destination PSP will check the IMD to ensure that same IMI is used at the source end. I have cut short few details in the email; See the SEV-SNP spec (section migration 4.11) for more.

Thanks
Brijesh

-----Original Message-----
From: Yao, Jiewen <jiewen.yao@intel.com>
Sent: Friday, March 12, 2021 8:32 PM
To: devel@edk2.groups.io; Yao, Jiewen <jiewen.yao@intel.com>; tobin@linux.ibm.com
Cc: Dov Murik <dovmurik@linux.vnet.ibm.com>; Tobin Feldman-Fitzthum <tobin@ibm.com>; James Bottomley <jejb@linux.ibm.com>; Hubertus Franke <frankeh@us.ibm.com>; Singh, Brijesh <brijesh.singh@amd.com>; Kalra, Ashish <Ashish.Kalra@amd.com>; Grimm, Jon <Jon.Grimm@amd.com>; Lendacky, Thomas <Thomas.Lendacky@amd.com>
Subject: RE: [edk2-devel] [RFC PATCH 00/14] Firmware Support for Fast Live Migration for AMD SEV

Hi
We discuss the patch internally. We do see PROs and CONs with this approach.
The advantage is that it is very simple. In-VM migration can save lots of effort on security context restore.
On the other hand, we feel not so comfortable to reserve a dedicate CPU to achieve that. Similar to the feedback in the community.

Using Hot-Plug is not a solution for Intel TDX as well. It is unsupported now.

I like the idea to diverge the migration boot mode v.s. normal boot mode in SEC phase.
We must be very carefully handle this migration boot mode, to avoid any touching on system memory.
Intel TDX Virtual Firmware skips the PEI phase directly. If we choose this approach, SEC-based migration is our preference.

Besides this patch, we would like to understand a full picture.
1) How the key is passed from source VM to destination?
I saw you mentions: "Key sharing is out of scope for this part of the RFC."
"This will probably be implemented via inject-launch-secret in the future"

Does that mean two PSP will sync with each other and negotiate the key, after the Migration Agent (MA) checks the policy?

2) How the attestation is supported?
I read the whitepaper https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.amd.com%2Fsystem%2Ffiles%2FTechDocs%2FSEV-SNP-strengthening-vm-isolation-with-integrity-protection-and-more.pdf&;data=04%7C01%7Cbrijesh.singh%40amd.com%7Cb19ccecd6ca946abd0eb08d8e5c84177%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637511995981376795%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=h67VntbdjigZFvhRfP6%2FGYTE9eqrFDqJRojWqG0C25c%3D&amp;reserved=0.
It seems SEV and SEV-ES only support attestation during launch, I don't believe this migration feature will impact the attestation report. Am I right?
SEV-SNP supports more flexible attestation, does it include any information about the new migrated content?


-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Yao,
Jiewen
Sent: Thursday, March 4, 2021 9:49 AM
To: devel@edk2.groups.io; tobin@linux.ibm.com
Cc: Dov Murik <dovmurik@linux.vnet.ibm.com>; Tobin Feldman-Fitzthum
<tobin@ibm.com>; James Bottomley <jejb@linux.ibm.com>; Hubertus Franke
<frankeh@us.ibm.com>; Brijesh Singh <brijesh.singh@amd.com>; Ashish
Kalra <ashish.kalra@amd.com>; Jon Grimm <jon.grimm@amd.com>; Tom
Lendacky <thomas.lendacky@amd.com>; Yao, Jiewen <jiewen.yao@intel.com>
Subject: Re: [edk2-devel] [RFC PATCH 00/14] Firmware Support for Fast
Live Migration for AMD SEV

Hi Tobin
Thanks for your patch.
You may that Intel is working on TDX for the same live migration feature.

Please give me some time (about 1 work week) to digest and evaluate
the patch and impact.
Then I will provide feedback.

Thank you
Yao Jiewen

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Tobin
Feldman-Fitzthum
Sent: Wednesday, March 3, 2021 4:48 AM
To: devel@edk2.groups.io
Cc: Dov Murik <dovmurik@linux.vnet.ibm.com>; Tobin Feldman-Fitzthum
<tobin@ibm.com>; Tobin Feldman-Fitzthum <tobin@linux.ibm.com>; James
Bottomley <jejb@linux.ibm.com>; Hubertus Franke
<frankeh@us.ibm.com>; Brijesh Singh <brijesh.singh@amd.com>; Ashish
Kalra
<ashish.kalra@amd.com>;
Jon Grimm <jon.grimm@amd.com>; Tom Lendacky
<thomas.lendacky@amd.com>
Subject: [edk2-devel] [RFC PATCH 00/14] Firmware Support for Fast
Live Migration for AMD SEV

This is a demonstration of fast migration for encrypted virtual
machines using a Migration Handler that lives in OVMF. This demo
uses AMD SEV, but the ideas may generalize to other confidential computing platforms.
With AMD SEV, guest memory is encrypted and the hypervisor cannot
access or move it. This makes migration tricky. In this demo, we
show how the HV can ask a Migration Handler (MH) in the firmware for
an encrypted page. The MH encrypts the page with a transport key
prior to releasing it to the HV. The target machine also runs an MH
that decrypts the page once it is passed in by the target HV. These
patches are not ready for production, but the are a full end-to-end
solution that facilitates a fast live migration between two SEV VMs.

Corresponding patches for QEMU have been posted my colleague Dov
Murik on qemu-devel. Our approach needs little kernel support,
requiring only one hypercall that the guest can use to mark a page
as encrypted or shared. This series includes updated patches from
Ashish Kalra and Brijesh Singh that allow OVMF to use this hypercall.

The MH runs continuously in the guest, waiting for communication
from the HV. The HV starts an additional vCPU for the MH but does
not expose it to the guest OS via ACPI. We use the MpService to
start the MH. The MpService is only available at runtime and
processes that are started by it are usually cleaned up on
ExitBootServices. Since we need the MH to run continuously, we had
to make some modifications. Ideally a feature could be added to the
MpService to allow for the starting of long-running processes.
Besides migration, this could support other background processes
that need to operate within the encryption boundary. For now, we
have included a handful of patches that modify the MpService to
allow the MH to keep running after ExitBootServices. These are temporary.

Ashish Kalra (2):
OvmfPkg/PlatformPei: Mark SEC GHCB page in the page encrpytion bitmap.
OvmfPkg/PlatformDxe: Add support for SEV live migration.

Brijesh Singh (1):
OvmfPkg/BaseMemEncryptLib: Support to issue unencrypted hypercall

Dov Murik (1):
OvmfPkg/AmdSev: Build page table for migration handler

Tobin Feldman-Fitzthum (10):
OvmfPkg/AmdSev: Base for Confidential Migration Handler
OvmfPkg/PlatfomPei: Set Confidential Migration PCD
OvmfPkg/AmdSev: Setup Migration Handler Mailbox
OvmfPkg/AmdSev: MH support for mailbox protocol
UefiCpuPkg/MpInitLib: temp removal of MpLib cleanup
UefiCpuPkg/MpInitLib: Allocate MP buffer as runtime memory
UefiCpuPkg/CpuExceptionHandlerLib: Exception handling as runtime
memory
OvmfPkg/AmdSev: Don't overwrite mailbox or pagetables
OvmfPkg/AmdSev: Don't overwrite MH stack
OvmfPkg/AmdSev: MH page encryption POC

OvmfPkg/OvmfPkg.dec | 11 +
OvmfPkg/AmdSev/AmdSevX64.dsc | 2 +
OvmfPkg/AmdSev/AmdSevX64.fdf | 13 +-
.../ConfidentialMigrationDxe.inf | 45 +++
.../ConfidentialMigrationPei.inf | 35 ++
.../DxeMemEncryptSevLib.inf | 1 +
.../PeiMemEncryptSevLib.inf | 1 +
OvmfPkg/PlatformDxe/Platform.inf | 2 +
OvmfPkg/PlatformPei/PlatformPei.inf | 2 +
UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf | 2 +
UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.inf | 2 +
OvmfPkg/AmdSev/ConfidentialMigration/MpLib.h | 235 +++++++++++++
.../ConfidentialMigration/VirtualMemory.h | 177 ++++++++++
OvmfPkg/Include/Guid/MemEncryptLib.h | 16 +
OvmfPkg/PlatformDxe/PlatformConfig.h | 5 +
.../ConfidentialMigrationDxe.c | 325 ++++++++++++++++++
.../ConfidentialMigrationPei.c | 25 ++
.../X64/PeiDxeVirtualMemory.c | 18 +
OvmfPkg/PlatformDxe/AmdSev.c | 99 ++++++
OvmfPkg/PlatformDxe/Platform.c | 6 +
OvmfPkg/PlatformPei/AmdSev.c | 10 +
OvmfPkg/PlatformPei/Platform.c | 10 +
.../CpuExceptionHandlerLib/DxeException.c | 8 +-
UefiCpuPkg/Library/MpInitLib/DxeMpLib.c | 21 +-
UefiCpuPkg/Library/MpInitLib/MpLib.c | 7 +-
25 files changed, 1061 insertions(+), 17 deletions(-) create mode
100644
OvmfPkg/AmdSev/ConfidentialMigration/ConfidentialMigrationDxe.inf
create mode 100644
OvmfPkg/AmdSev/ConfidentialMigration/ConfidentialMigrationPei.inf
create mode 100644 OvmfPkg/AmdSev/ConfidentialMigration/MpLib.h
create mode 100644
OvmfPkg/AmdSev/ConfidentialMigration/VirtualMemory.h
create mode 100644 OvmfPkg/Include/Guid/MemEncryptLib.h
create mode 100644
OvmfPkg/AmdSev/ConfidentialMigration/ConfidentialMigrationDxe.c
create mode 100644
OvmfPkg/AmdSev/ConfidentialMigration/ConfidentialMigrationPei.c
create mode 100644 OvmfPkg/PlatformDxe/AmdSev.c

--
2.20.1








[edk2-platforms][PATCH v2 5/5] Socionext: DeveloperBox DSC File: Added library for VariableSmmRuntimeDxe

Kun Qin
 

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3250

This change added NULL MmUnblockMemoryLib instance in DeveloperBox.dsc to
resolve new dependency by VariableSmmRuntimeDxe. The library interface
is consumed by variable module to better support variable runtime cache
feature.

Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Leif Lindholm <leif@nuviainc.com>

Signed-off-by: Kun Qin <kuqin12@gmail.com>
---

Notes:
v2:
- No review, no change.

Platform/Socionext/DeveloperBox/DeveloperBox.dsc | 2 ++
1 file changed, 2 insertions(+)

diff --git a/Platform/Socionext/DeveloperBox/DeveloperBox.dsc b/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
index 0a11b796cca5..acaa4cd90fc5 100644
--- a/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
+++ b/Platform/Socionext/DeveloperBox/DeveloperBox.dsc
@@ -49,6 +49,8 @@ [LibraryClasses]
TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf
!endif

+ MmUnblockMemoryLib|MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.inf
+
[LibraryClasses.common.SEC]
PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
--
2.30.0.windows.1


[edk2-platforms][PATCH v2 4/5] Vlv2TbltDevicePkg: PlatformPkg DSC: Added library for VariableSmmRuntimeDxe

Kun Qin
 

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3250

This change added NULL MmUnblockMemoryLib instance in PlatformPkg dsc
file to resolve new dependency by VariableSmmRuntimeDxe. The library
interface is consumed by variable module to better support variable
runtime cache feature.

Cc: Zailiang Sun <zailiang.sun@intel.com>
Cc: Yi Qian <yi.qian@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>

Signed-off-by: Kun Qin <kuqin12@gmail.com>
---

Notes:
v2:
- Added Michael K. to cc list [Zailiang]

Platform/Intel/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc | 1 +
Platform/Intel/Vlv2TbltDevicePkg/PlatformPkgX64.dsc | 1 +
2 files changed, 2 insertions(+)

diff --git a/Platform/Intel/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc b/Platform/Intel/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc
index 409f31c982d7..33e93b74800c 100644
--- a/Platform/Intel/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc
+++ b/Platform/Intel/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc
@@ -311,6 +311,7 @@ [LibraryClasses.IA32]
LockBoxLib|MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.inf
EfiRegTableLib|Vlv2TbltDevicePkg/Library/EfiRegTableLib/EfiRegTableLib.inf
HashLib|SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterDxe.inf
+ MmUnblockMemoryLib|MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.inf

[LibraryClasses.IA32.DXE_DRIVER]
DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
diff --git a/Platform/Intel/Vlv2TbltDevicePkg/PlatformPkgX64.dsc b/Platform/Intel/Vlv2TbltDevicePkg/PlatformPkgX64.dsc
index 38bd825c8bdc..f7a876353649 100644
--- a/Platform/Intel/Vlv2TbltDevicePkg/PlatformPkgX64.dsc
+++ b/Platform/Intel/Vlv2TbltDevicePkg/PlatformPkgX64.dsc
@@ -313,6 +313,7 @@ [LibraryClasses.X64]
LockBoxLib|MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.inf
EfiRegTableLib|Vlv2TbltDevicePkg/Library/EfiRegTableLib/EfiRegTableLib.inf
HashLib|SecurityPkg/Library/HashLibBaseCryptoRouter/HashLibBaseCryptoRouterDxe.inf
+ MmUnblockMemoryLib|MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.inf

[LibraryClasses.X64.DXE_DRIVER]
DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
--
2.30.0.windows.1


[edk2-platforms][PATCH v2 3/5] QuarkPlatformPkg: Quark DSC File: Added new library for VariableSmmRuntimeDxe

Kun Qin
 

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3250

This change added NULL MmUnblockMemoryLib instance in Quark.dsc to
resolve new dependency by VariableSmmRuntimeDxe. The library interface
is consumed by variable module to better support variable runtime cache
feature.

Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Kelly Steele <kelly.steele@intel.com>

Signed-off-by: Kun Qin <kuqin12@gmail.com>
Reviewed-by: Kelly Steele <kelly.steele@intel.com>
---

Notes:
v2:
- Added reviewed-by tag [Kelly]

Platform/Intel/QuarkPlatformPkg/Quark.dsc | 1 +
1 file changed, 1 insertion(+)

diff --git a/Platform/Intel/QuarkPlatformPkg/Quark.dsc b/Platform/Intel/QuarkPlatformPkg/Quark.dsc
index e29c7465b1e4..c58da58348e3 100644
--- a/Platform/Intel/QuarkPlatformPkg/Quark.dsc
+++ b/Platform/Intel/QuarkPlatformPkg/Quark.dsc
@@ -146,6 +146,7 @@ [LibraryClasses]
ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
ExtractGuidedSectionLib|MdePkg/Library/DxeExtractGuidedSectionLib/DxeExtractGuidedSectionLib.inf
LockBoxLib|MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.inf
+ MmUnblockMemoryLib|MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.inf
VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf
VariablePolicyLib|MdeModulePkg/Library/VariablePolicyLib/VariablePolicyLib.inf
VariablePolicyHelperLib|MdeModulePkg/Library/VariablePolicyHelperLib/VariablePolicyHelperLib.inf
--
2.30.0.windows.1


[edk2-platforms][PATCH v2 2/5] MinPlatformPkg: Core Include Files: Added Tcg2Acpi driver after separation

Kun Qin
 

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3251

This change follows the commit that separates the original Tcg2Smm driver
into Tcg2Acpi and Tcg2 MM based on functionality in DXE and MM. The new
Tcg2Acpi driver now will be responsible for patching and publishing ACPI
table from DXE, and Tcg2 MM driver will be handling runtime MMI requests
from ACPI calls.

Cc: Chasel Chiu <chasel.chiu@intel.com>
Cc: Nate DeSimone <nathaniel.l.desimone@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Eric Dong <eric.dong@intel.com>

Signed-off-by: Kun Qin <kuqin12@gmail.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
---

Notes:
v2:
- Added reviewed-by tag [Liming]

Platform/Intel/MinPlatformPkg/Include/Dsc/CoreDxeInclude.dsc | 1 +
Platform/Intel/MinPlatformPkg/Include/Fdf/CoreSecurityLateInclude.fdf | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/Platform/Intel/MinPlatformPkg/Include/Dsc/CoreDxeInclude.dsc b/Platform/Intel/MinPlatformPkg/Include/Dsc/CoreDxeInclude.dsc
index a76a9bf5fdf9..c2ade240f314 100644
--- a/Platform/Intel/MinPlatformPkg/Include/Dsc/CoreDxeInclude.dsc
+++ b/Platform/Intel/MinPlatformPkg/Include/Dsc/CoreDxeInclude.dsc
@@ -155,6 +155,7 @@
NULL|SecurityPkg/Library/HashInstanceLibSha256/HashInstanceLibSha256.inf
}
SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.inf
+ SecurityPkg/Tcg/Tcg2Acpi/Tcg2Acpi.inf
SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDxe.inf
!endif

diff --git a/Platform/Intel/MinPlatformPkg/Include/Fdf/CoreSecurityLateInclude.fdf b/Platform/Intel/MinPlatformPkg/Include/Fdf/CoreSecurityLateInclude.fdf
index 45dda7ea0a91..3edc878e173b 100644
--- a/Platform/Intel/MinPlatformPkg/Include/Fdf/CoreSecurityLateInclude.fdf
+++ b/Platform/Intel/MinPlatformPkg/Include/Fdf/CoreSecurityLateInclude.fdf
@@ -14,6 +14,7 @@
!if gMinPlatformPkgTokenSpaceGuid.PcdTpm2Enable == TRUE
INF SecurityPkg/Tcg/MemoryOverwriteControl/TcgMor.inf
INF SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.inf
-INF RuleOverride = DRIVER_ACPITABLE SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.inf
+INF SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.inf
+INF RuleOverride = DRIVER_ACPITABLE SecurityPkg/Tcg/Tcg2Acpi/Tcg2Acpi.inf
INF SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDxe.inf
!endif
--
2.30.0.windows.1


[edk2-platforms][PATCH v2 1/5] MinPlatformPkg: CoreCommonLib: Added new library for VariableSmmRuntimeDxe

Kun Qin
 

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3250

This change added NULL MmUnblockMemoryLib instance in dsc files of
CoreCommonLib to resolve newly introduced dependency. The library
interface is consumed by VariableSmmRuntimeDxe to better support variable
runtime cache feature.

Cc: Chasel Chiu <chasel.chiu@intel.com>
Cc: Nate DeSimone <nathaniel.l.desimone@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Eric Dong <eric.dong@intel.com>

Signed-off-by: Kun Qin <kuqin12@gmail.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
---

Notes:
v2:
- Added reviewed-by tag [Liming]

Platform/Intel/MinPlatformPkg/Include/Dsc/CoreCommonLib.dsc | 1 +
1 file changed, 1 insertion(+)

diff --git a/Platform/Intel/MinPlatformPkg/Include/Dsc/CoreCommonLib.dsc b/Platform/Intel/MinPlatformPkg/Include/Dsc/CoreCommonLib.dsc
index cb40e111b5dd..bcabb797e91a 100644
--- a/Platform/Intel/MinPlatformPkg/Include/Dsc/CoreCommonLib.dsc
+++ b/Platform/Intel/MinPlatformPkg/Include/Dsc/CoreCommonLib.dsc
@@ -159,6 +159,7 @@ [LibraryClasses.common]
LockBoxLib|MdeModulePkg/Library/LockBoxNullLib/LockBoxNullLib.inf

SmmMemLib|MdePkg/Library/SmmMemLib/SmmMemLib.inf
+ MmUnblockMemoryLib|MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.inf

SmbusLib|MdePkg/Library/BaseSmbusLibNull/BaseSmbusLibNull.inf
VariablePolicyLib|MdeModulePkg/Library/VariablePolicyLib/VariablePolicyLib.inf
--
2.30.0.windows.1


[edk2-platforms][PATCH v2 0/5] Resolve dependency from MmUnblockMemoryLib

Kun Qin
 

This patch series is a follow up of previous submission:
https://edk2.groups.io/g/devel/message/72645

v2 patches mainly focus on feedback for reviewed commits in v1 patches,
including:
a. Adding "Reviewed-by" tags for applicable patch;
b. Updating cc list include critical reviewers;

Patch v2 branch: https://github.com/kuqin12/edk2-platforms/tree/unblock_dependency_v2

Cc: Chasel Chiu <chasel.chiu@intel.com>
Cc: Nate DeSimone <nathaniel.l.desimone@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Kelly Steele <kelly.steele@intel.com>
Cc: Zailiang Sun <zailiang.sun@intel.com>
Cc: Yi Qian <yi.qian@intel.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Leif Lindholm <leif@nuviainc.com>

Kun Qin (5):
MinPlatformPkg: CoreCommonLib: Added new library for
VariableSmmRuntimeDxe
MinPlatformPkg: Core Include Files: Added Tcg2Acpi driver after
separation
QuarkPlatformPkg: Quark DSC File: Added new library for
VariableSmmRuntimeDxe
Vlv2TbltDevicePkg: PlatformPkg DSC: Added library for
VariableSmmRuntimeDxe
Socionext: DeveloperBox DSC File: Added library for
VariableSmmRuntimeDxe

Platform/Intel/MinPlatformPkg/Include/Dsc/CoreCommonLib.dsc | 1 +
Platform/Intel/MinPlatformPkg/Include/Dsc/CoreDxeInclude.dsc | 1 +
Platform/Intel/MinPlatformPkg/Include/Fdf/CoreSecurityLateInclude.fdf | 3 ++-
Platform/Intel/QuarkPlatformPkg/Quark.dsc | 1 +
Platform/Intel/Vlv2TbltDevicePkg/PlatformPkgIA32.dsc | 1 +
Platform/Intel/Vlv2TbltDevicePkg/PlatformPkgX64.dsc | 1 +
Platform/Socionext/DeveloperBox/DeveloperBox.dsc | 2 ++
7 files changed, 9 insertions(+), 1 deletion(-)

--
2.30.0.windows.1

16821 - 16840 of 89692