-----邮件原件-----
发件人: 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".

-----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]
-=-=-=-=-=-=

-----邮件原件-----
发件人: 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

-----邮件原件-----
发件人: 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

-----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.)

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.

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

-----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.
//

-----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