On Thu, Sep 23, 2021 at 02:19:17PM +, Yao, Jiewen wrote:
> All fields in TDX metadata are required. So the current SEV proposal
> (3 fields) does not work for TDX. The extra fields are used to guide
> VMM on how to copy the binary, allocate memory,
--verbose please.
The VMM loads the
Hi,
> > SEV hardware does not have a concept of the metadata. To boot SEV guest we
> > need to pass some information to VMM and in past those information were
> > passed through SNP_BOOT_BLOCK (GUIDed structure) but Gerd recommended
> > that it will be good idea if both SEV and TDX uses a
On Thu, Sep 23, 2021 at 01:38:52PM +, Yao, Jiewen wrote:
> Good point, Min.
>
> If
> https://github.com/AMDESE/ovmf/blob/snp-v8/OvmfPkg/ResetVector/X64/OvmfMetadata.asm
> is the proposal, then I have more comment:
>
> Type: OVMF_SECTION_TYPE_CODE, OVMF_SECTION_TYPE_VARS are NOT used for
More details on new QuickSort() API:
The new API needs to carry additional parameter “BufferOneElement”.
This parameter gives QuickSort() the temporary buffer for swapping in sorting.
It’s to avoid BaseLib depends on MemoryAllocationLib.
…
@param [in] BufferOneElement When ElementSize >
Hi Liming,
Yes, this adds a new runtime variation of the FmpDxe driver that can process
the FMP payload of a capsule at runtime if the capsule flags do not request
PERSIST_ACROSS_RESET and INITIATE_RESET.
There are also changes required to DxeCapsuleLibFmp to enable this runtime FMP
Hi Everyone,
We are pleased to announce that the FSP External Architecture Specification
v2.3 has been posted to https://www.intel.com/fsp!
Highlights
* FSP_NON_VOLATILE_STORAGE_HOB2 – A new architectural HOB has been added
for storage of MRC training data. While this HOB serves the
Limiting the boot description to a fixed number of characters should be a
platform policy.
BDS common logic should NOT do that.
Imagine a platform that contains a fancy UI with scrollbar or supports a big
resolution.
Such platform can still use the BdsDxe driver. But it doesn't need the
Bob:
Dose this change make FirmwareManagementProtocol to be used in runtime
phase?
Thanks
Liming
> -邮件原件-
> 发件人: devel@edk2.groups.io 代表 Bob Morgan
> via groups.io
> 发送时间: 2021年9月23日 8:00
> 收件人: devel@edk2.groups.io
> 抄送: gaolim...@byosoft.com.cn; michael.d.kin...@intel.com;
>
You can create the PR by yourself.
Thanks,
Zhichao
From: Sami Mujawar
Sent: Thursday, September 23, 2021 4:37 PM
To: Gao; Gao, Zhichao ; devel@edk2.groups.io
Subject: Re: [edk2-devel] [PATCH v1 0/2] ACPI 6.4 SBSA generic watchdog renaming
Hi Zhichao,
The following patch series have been
Pierre:
Can you submit BZ for this change request?
Thanks
Liming
> -邮件原件-
> 发件人: pierre.gond...@arm.com
> 发送时间: 2021年9月23日 16:59
> 收件人: devel@edk2.groups.io; Bob Feng ; Liming
> Gao ; Sami Mujawar
> 主题: [PATCH v1 0/4] Set default Makefile name
>
> From: Pierre Gondois
>
> A
Leif:
I gave my Acked-by for this patch set V2. I think it can be merged now.
Thanks
Liming
> -邮件原件-
> 发件人: devel@edk2.groups.io 代表 Leif Lindholm
> 发送时间: 2021年9月24日 2:17
> 收件人: Rebecca Cran
> 抄送: devel@edk2.groups.io; Bob Feng ; Liming Gao
> ; Yuwei Chen ; Sean
> Brogan ; Sami Mujawar
On Thu, Sep 23, 2021 at 15:20:41 +, Jeff Brasen wrote:
> That looks like something I missed and looks good, do you need me to
> make a v4 or will you just add that in.
Nah, I just folded it in.
Pushed as 79019c7a4228..7ea7f9c07757.
Thanks!
> When I built I just used our
> application that
Sorry I don't see it. Could you re-send it with "PATCH v2" in the
subject line (by passing -v2 to "git format-patch") if you didn't
already please?
--
Rebecca Cran
On 9/22/21 10:22 PM, Jayaprakash, N wrote:
Thank you Rebecca.
I have submitted the updated patch for review.
Regards,
JP
Hi Rebecca,
I think I already gave v2 an Acked-by, but just in case:
Acked-by: Leif Lindholm
Bob, Liming, Yuwei - any comments?
/
Leif
Thu, Sep 23, 2021 at 10:09:55 -0600, Rebecca Cran wrote:
> BaseTools/Bin/gcc_[arm,aarch64]_linux_ext_dep.yaml downloads GCC releases
> from
Linaro no longer do gcc releases - they're done by Arm now.
Update gcc_aarch64_linux_ext_dep.yaml to fetch the latest AARCH64 gcc
release (10.3-2021.07) from their site.
Signed-off-by: Rebecca Cran
---
BaseTools/Bin/gcc_aarch64_linux_ext_dep.yaml | 10 +-
Linaro no longer do gcc releases - they're done by Arm now.
Update gcc_arm_linux_ext_dep.yaml to fetch the latest ARM gcc release
(10.3-2021.07) from their site.
Signed-off-by: Rebecca Cran
---
BaseTools/Bin/gcc_arm_linux_ext_dep.yaml | 10 +-
BaseTools/Bin/gcc_[arm,aarch64]_linux_ext_dep.yaml downloads GCC releases
from https://releases.linaro.org/components/toolchain/binaries/7.4-2019.02 .
As indicated in the URL, those builds are from 2019 because Linaro no
longer do GCC releases, with that task having moved to Arm.
The Arm GCC
That looks like something I missed and looks good, do you need me to make a v4
or will you just add that in. When I built I just used our application that has
the guid in our inf so missed this.
>From my looking at it AndroidFastBootApp doesn't seem to use this lib.
> -Original
Hi Stefan,
This patch looks good to me.
Reviewed-by: Sami Mujawar
Regards,
Sami Mujawar
On 22/09/2021, 17:32, "Stefan Berger" wrote:
From: Stefan Berger
Add a NULL implementation of the library class TpmPlatformHierarchyLib.
Link:
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3648
Register SmmExitBootServices and SmmLegacyBoot callback function to unregister
this handler.
Signed-off-by: Hao Shi
Cc: Dandan Bi
Cc: Liming Gao
---
.../UserAuthenticationSmm.c | 34 +++
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3648
Register SmmExitBootServices and SmmLegacyBoot callback function to unregister
this handler.
Signed-off-by: Hao Shi mailto:hao@intel.com>>
---
.../UserAuthenticationSmm.c | 34 +++
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3648
Register SmmExitBootServices and SmmLegacyBoot callback function to unregister
this handler.
Signed-off-by: Hao Shi
---
.../UserAuthenticationSmm.c | 34 +++
.../UserAuthenticationSmm.inf
HI Brijesh
Thanks for the explanation.
All fields in TDX metadata are required. So the current SEV proposal (3 fields)
does not work for TDX. The extra fields are used to guide VMM on how to copy
the binary, allocate memory, and how to measure the component. And we are
adding more extension to
On September 23, 2021 10:04 PM, Brijesh Singh wrote:
>
> SEV hardware does not have a concept of the metadata. To boot SEV guest we
> need to pass some information to VMM and in past those information were
> passed through SNP_BOOT_BLOCK (GUIDed structure) but Gerd recommended
> that it will be
SEV hardware does not have a concept of the metadata. To boot SEV guest
we need to pass some information to VMM and in past those information
were passed through SNP_BOOT_BLOCK (GUIDed structure) but Gerd
recommended that it will be good idea if both SEV and TDX uses a common
metadata approach
On Thu, Sep 23, 2021 at 06:54:24 -0600, Rebecca Cran wrote:
> On 9/23/21 4:30 AM, Leif Lindholm wrote:
> > Not just an improvement, but an actual bugfix.
> >
> > I would propose a subject line change though:
> > Qemu: SbsaQemu: Set the DSDT revision value to 2 to use 64-bit math
> > ->
> >
Hi Nhi,
Following up with the comment I also made for 12/28:
On Wed, Sep 15, 2021 at 22:55:00 +0700, Nhi Pham wrote:
> diff --git a/Silicon/Ampere/AmpereAltraPkg/Include/Platform/Ac01.h
> b/Silicon/Ampere/AmpereAltraPkg/Include/Platform/Ac01.h
> new file mode 100644
> index
Hi Nhi,
I think all of my comments up to here have been reasonably simple.
This patch I have not reviewed before, so they could be more detailed.
If you'd like to submit a v4 of 1-11, we could possibly merge those
and reduce the churn a bit.
Anyway, review following:
On Wed, Sep 15, 2021 at
Good point, Min.
If
https://github.com/AMDESE/ovmf/blob/snp-v8/OvmfPkg/ResetVector/X64/OvmfMetadata.asm
is the proposal, then I have more comment:
Type: OVMF_SECTION_TYPE_CODE, OVMF_SECTION_TYPE_VARS are NOT used for SEV. I am
not sure why they are there.
Type: OVMF_SECTION_TYPE_CPUID should
Please see my comments below inline.
Thanks,
Chasel
> -Original Message-
> From: S, Ashraf Ali
> Sent: Wednesday, September 22, 2021 10:23 PM
> To: devel@edk2.groups.io
> Cc: S, Ashraf Ali ; Chiu, Chasel
> ;
> Desimone, Nathaniel L ; Zeng, Star
> ; Kuo, Ted ; Duggapu, Chinni B
> ;
I suggest SEV and TDX keep their own metadata in separate files. This is
because SEV and TDX has different item structure.
From the OvmfMetadata definition in SEV
(https://github.com/AMDESE/ovmf/blob/snp-v8/OvmfPkg/ResetVector/X64/OvmfMetadata.asm)
there are 3 fields in the item.
The metadata table definition for TDX is at
https://software.intel.com/content/dam/develop/external/us/en/documents/tdx-virtual-firmware-design-guide-rev-1.pdf,
Chapter 11.2 TDVF descriptor. And we will add more entry there.
May I get a proposed SEV or OVMF meta-table definition somewhere?
Like Gerd I would prefer to have one metadata table in the reset GUID.
The metadata table will contain multiple entries; lot of entries are
common between SNP and TDX. Some entries will have specific meaning for
the platform. Those special entries should be marked using the
On 9/23/21 4:30 AM, Leif Lindholm wrote:
Not just an improvement, but an actual bugfix.
I would propose a subject line change though:
Qemu: SbsaQemu: Set the DSDT revision value to 2 to use 64-bit math
->
Platform/Qemu: fix SbsaQemu DSDT format version
If you're OK with the change, I can fold
On Wed, Sep 15, 2021 at 22:55:08 +0700, Nhi Pham wrote:
> From: Vu Nguyen
>
> This supports storing the UEFI non-volatile varibles on flash through
> the MM communication interface instead of emulating. Below are modules
> added for this support:
> * FlashLib provides APIs to access flash
I strongly recommend to separate SEV and TDX in all context, if it is something
SEV or TDX specific.
Then each file has clear ownership.
If it is something generic for both SEV and TDX, it can in one file.
For example, SecPeiTempRam/SecPageTable can be in common file.
But
Hi Jeff,
I was about to say "no more issues", and then I went to build
EmbeddedPkg, and it turns out this fails in
Applications/AndroidBootApp due to the missing dependency on
gEfiLoadFile2ProtocolGuid in AndroidBootImgLib.inf.
(Why this doesn't break AndroidFastbootApp build as well is not
Not just an improvement, but an actual bugfix.
I would propose a subject line change though:
Qemu: SbsaQemu: Set the DSDT revision value to 2 to use 64-bit math
->
Platform/Qemu: fix SbsaQemu DSDT format version
If you're OK with the change, I can fold that in.
Reviewed-by: Leif Lindholm
On
Hi Marcin,
On Wed, Sep 22, 2021 at 14:46:10 +0200, Marcin Wojtas wrote:
> > Marcin, when you find the time, could you please do a pass over these
> > files with Leif's critique in mind?
>
>
> For all 3 platforms, how about the following update:
> - extend the "Summary" section with supported
For this patch series:
Reviewed-by: Chris Jones
Regards,
Chris
From: devel@edk2.groups.io on behalf of PierreGondois
via groups.io
Sent: Thursday, September 23, 2021 9:58 AM
To: devel@edk2.groups.io ; Bob Feng
; Liming Gao ; Sami Mujawar
Subject:
From: Pierre Gondois
Running the following command:
python3 build/build.py -a AARCH64 -t GCC5
-p ArmPlatformPkg/ArmPlatformPkg.dsc -b DEBUG libraries
triggers the following error:
make: *** Build/ArmPlatform/DEBUG_GCC5/AARCH64/MdePkg/Library/
BasePcdLibNull/BasePcdLibNull: Is a
From: Pierre Gondois
The "target.txt" and "tools_def.txt" filenames are hard-coded
at some places when global definitions are available at:
BaseTools/Source/Python/Common/TargetTxtClassObject.py:
DefaultTargetTxtFile
and
BaseTools/Source/Python/Common/ToolDefClassObject.py:
DefaultToolsDefFile
From: Pierre Gondois
The Makefile and MakefilName fields are never set/used. Remove them.
To check this, the following commands can be used:
- grep -rIn "\.Makefile"
- grep -rIn "\.MakefileName"
Signed-off-by: Pierre Gondois
---
BaseTools/Source/Python/AutoGen/ModuleAutoGen.py | 1 -
From: Pierre Gondois
Use the value set in tools_def.txt when the makefile type is
not explicitly set via BuildOption. This allows to have a
valid default makefile name instead of an empty string.
Also use GMAKE_FILETYPE instead of hard-coded "gmake".
Signed-off-by: Pierre Gondois
---
From: Pierre Gondois
A Makefile name is not set in BaseTools when only building modules
or libraries. This patch-set sets a default Makefile name for the
"build" command.
The patch-set also:
- Removes unsused Makefile variables
- Removes hard-coded references to "target.txt" and "tools_def.txt"
On Thu, Sep 23, 2021 at 12:38:24AM +, Xu, Min M wrote:
> On September 22, 2021 3:49 PM, Gerd Hoffmann wrote:
> > Hi,
> >
> > > +%ifdef ARCH_X64
> > > +;
> > > +; TDX Metadata offset block
> > > +;
> > > +; TdxMetadata.asm is included in ARCH_X64 because Inte TDX is only ;
> > > +available
Hi Zhichao,
The following patch series have been reviewed and have received r-b from the
maintainers.
· https://edk2.groups.io/g/devel/topic/84925099#79362 (ShellPkg &
DynamicTablesPkg)
· https://edk2.groups.io/g/devel/topic/84868164#79285 (ShellPkg)
·
Hi,
> One issue with that is that the contents of the CPUID page are not part
> of guest measurement that will be checked later during attestation (only
> the metadata such as page type/location is recorded in the measurement).
>
> [ more details snipped ]
Thanks, that makes sense.
> That
Hi Ray,
That is one way for platform to customize their own boot option. It can solve
the issue. But my point is it should not be used in such case. If EDK2 want a
default behavior of the boot option description, we should change at the root
instead of using the customize interfaces.
Thanks,
Hi Sami,
Unfortunately this is still necessary,
cf
https://dev.azure.com/tianocore/edk2-ci/_build/results?buildId=29900=logs=216bd3cb-36c2-5579-221e-bd2f77088687=156c6dac-d9ee-52ac-8143-8428ed0a9e36
ERROR - EFI coding style error
ERROR - *Error code: 8003
ERROR - *The #ifndef at the start of an
Another option is to use EfiBootManagerRegisterBootDescriptionHandler() to
alter the boot descriptions.
> -Original Message-
> From: Gao, Zhichao
> Sent: Thursday, September 23, 2021 11:47 AM
> To: devel@edk2.groups.io; gaolim...@byosoft.com.cn; Ni, Ray
> Cc: Wang, Jian J
> Subject:
51 matches
Mail list logo
