Did you find the TestPointDumpApp?
https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel/MinPlatformPkg/Test/TestPointDumpApp
gEfiAdapterInformationProtocolGuid is used and there is a test-point
specific adapter information type. FeaturesImplemented can be compared
with
Laszlo, Ard, Sami:
I am OK to merge this patch for stable tag 202105.
Thanks
Liming
> -邮件原件-
> 发件人: devel@edk2.groups.io 代表 Laszlo Ersek
> 发送时间: 2021年5月25日 19:55
> 收件人: devel@edk2.groups.io; sami.muja...@arm.com
> 抄送: a...@kernel.org; l...@nuviainc.com; matteo.carl...@arm.com;
>
Mike,
I totally agree with you on the restriction: Drivers in universal payload don't
use dynamic(ex) PCDs.
That's the final state.
In phase #1, we need to separate the PCD database so that drivers inside
universal payload don't consume any dynamic(ex) PCDs outside. For example,
*Reminder:* TianoCore Bug Triage - APAC / NAMO
*When:* Tuesday, 25 May 2021, 6:30pm to 7:30pm, (GMT-07:00) America/Los Angeles
*Where:*
On 5/25/21 6:15 PM, James Bottomley wrote:
> On Tue, 2021-05-25 at 15:33 -0500, Tom Lendacky wrote:
>> On 5/25/21 3:08 PM, Dov Murik wrote:
>>> Hi Brijesh,
>>>
>>> On 25/05/2021 18:48, Brijesh Singh wrote:
On 5/25/21 12:31 AM, Dov Murik wrote:
> Booting with SEV prevented the loading of
On Tue, 2021-05-25 at 15:33 -0500, Tom Lendacky wrote:
> On 5/25/21 3:08 PM, Dov Murik wrote:
> > Hi Brijesh,
> >
> > On 25/05/2021 18:48, Brijesh Singh wrote:
> > > On 5/25/21 12:31 AM, Dov Murik wrote:
> > > > Booting with SEV prevented the loading of kernel, initrd, and
> > > > kernel
On 5/25/21 3:08 PM, Dov Murik wrote:
> Hi Brijesh,
>
> On 25/05/2021 18:48, Brijesh Singh wrote:
>>
>> On 5/25/21 12:31 AM, Dov Murik wrote:
>>> Booting with SEV prevented the loading of kernel, initrd, and kernel
>>> command-line via QEMU fw_cfg interface because they arrive from the VMM
>>>
Hi Brijesh,
On 25/05/2021 18:48, Brijesh Singh wrote:
>
> On 5/25/21 12:31 AM, Dov Murik wrote:
>> Booting with SEV prevented the loading of kernel, initrd, and kernel
>> command-line via QEMU fw_cfg interface because they arrive from the VMM
>> which is untrusted in SEV.
>>
>> However, in some
On 05/25/21 16:28, Satoshi Tanda wrote:
> On Tue, May 25, 2021 at 05:16 AM, Laszlo Ersek wrote:
>
>>
>> (1) The BZ URL is incorrect;
>
>>
>> (2) Similarly, I think the subject should be clarified, upon merge
>
> Let me know if anyone needs the updates of the patch on those (vs updating
> them
On 5/25/21 12:31 AM, Dov Murik wrote:
> Booting with SEV prevented the loading of kernel, initrd, and kernel
> command-line via QEMU fw_cfg interface because they arrive from the VMM
> which is untrusted in SEV.
>
> However, in some cases the kernel, initrd, and cmdline are not secret
> but
Hi Ray,
The PCD Database is intended to be owned by the platform FW.
The concept of a universal payload that is loaded after the platform FW is
similar in
concept to loading a UEFI app/driver/osloader. Those types of loadable UEFI
components
are not allowed to use the PCD services
The only
On Tue, May 25, 2021 at 05:16 AM, Laszlo Ersek wrote:
>
> (1) The BZ URL is incorrect;
>
> (2) Similarly, I think the subject should be clarified, upon merge
Let me know if anyone needs the updates of the patch on those (vs updating them
inline at PR). I will do it if required.
>
> Should
What does different PCD Database with a different GUID mean?
Has the problem statement and design for multiple PCD databases
from multiple binaries been reviewed in the TianoCore design meeting?
This sounds like a topic that needs more discussion before making
changes like this.
Thanks,
Mike
Hi Sayanta,
Thank you for this patch.
Please find my response inline marked [SAMI].
Regards,
Sami Mujawar
On 24/05/2021 06:23 PM, Sayanta Pattanayak wrote:
Enable the use of UEFI secure boot for Arm's Neoverse reference design
platforms. The UEFI authenticated variable store uses NOR flash
Hi Sayanta,
I have a minor suggestion maked inline as [SAMI].
Otherwise this patch looks good to me.
With that addressed.
Reviewed-by: Sami Mujawar
Regards,
Sami Mujawar
On 24/05/2021 06:22 PM, Sayanta Pattanayak wrote:
Add the NorFlashPlatformLib library instance that can be linked with
Hi Sayanta,
This patch looks good to me.
Reviewed-by: Sami Mujawar
Regards,
Sami Mujawar
On 24/05/2021 06:22 PM, Sayanta Pattanayak wrote:
The RD-N2 platform has a different memory map from that of the other
platforms supported under the SgiPkg. To enable the use of StandaloneMM
as a
Looks good to me as well. By the way, this fixed Windows PE blue screen issue.
Reviewed-by: Sunny Wang
-Original Message-
From: Samer El-Haj-Mahmoud
Sent: Monday, May 24, 2021 7:00 PM
To: Marcin Wojtas ; devel@edk2.groups.io
Cc: l...@nuviainc.com; ardb+tianoc...@kernel.org; Sunny Wang
On 25/05/2021 8:31, Dov Murik wrote:
> Booting with SEV prevented the loading of kernel, initrd, and kernel
> command-line via QEMU fw_cfg interface because they arrive from the VMM
> which is untrusted in SEV.
>
> However, in some cases the kernel, initrd, and cmdline are not secret
> but
On 5/25/21 6:21 AM, Laszlo Ersek wrote:
The idea is to use the wiki of any one of your projects on github.com --
most fittingly, your edk2 fork's wiki.
The URL to clone the "real" wiki repo from is:
git://github.com/tianocore/tianocore.github.io.wiki
And the repo URL of the wiki of your
From: James Bottomley
The library finds and checks out the encrypted page from the memfd and
installs a finder routine for GUID described hashes if it checks out
OK.
Cc: Laszlo Ersek
Cc: Ard Biesheuvel
Cc: Jordan Justen
Cc: Ashish Kalra
Cc: Brijesh Singh
Cc: Erdem Aktas
Cc: James
From: James Bottomley
Reserve a page inside the MEMFD for the VMM to place an encrypted page
containing GUID described hashes of firmware configurations. We do
this so the page gets attested by the PSP and thus the untrusted VMM
can't pass in different files from what the guest owner thinks.
From: James Bottomley
Allow registering a verifier which is then called for each blob passed
via QEMU's fw_cfg.
Cc: Laszlo Ersek
Cc: Ard Biesheuvel
Cc: Jordan Justen
Cc: Ashish Kalra
Cc: Brijesh Singh
Cc: Erdem Aktas
Cc: James Bottomley
Cc: Jiewen Yao
Cc: Min Xu
Cc: Tom Lendacky
Booting with SEV prevented the loading of kernel, initrd, and kernel
command-line via QEMU fw_cfg interface because they arrive from the VMM
which is untrusted in SEV.
However, in some cases the kernel, initrd, and cmdline are not secret
but should not be modified by the host. In such a case, we
From: James Bottomley
Provide a library verifier that plugs into the QemuKernelLoaderFs
hooks to verify the hashes against the SEV hash table (stored in
encrypted memory).
The verifier is enabled when SEV memory encryption is active.
Cc: Laszlo Ersek
Cc: Ard Biesheuvel
Cc: Jordan Justen
Cc:
From: James Bottomley
Add optional hook which calls a verifier with the content of the fw_cfg
command line.
Cc: Laszlo Ersek
Cc: Ard Biesheuvel
Cc: Jordan Justen
Cc: Ashish Kalra
Cc: Brijesh Singh
Cc: Erdem Aktas
Cc: James Bottomley
Cc: Jiewen Yao
Cc: Min Xu
Cc: Tom Lendacky
From: James Bottomley
Commit 96201ae7bf97 ("OvmfPkg/AmdSev/SecretDxe: make secret location
naming generic", 2020-12-15) replaced references to SEV with the generic
term Confidential Computing, but missed the file header comment. Fix
the naming in that header.
Cc: Laszlo Ersek
Cc: Ard
From: James Bottomley
This is a wrapper library around GenericQemuLoadImageLib which
activates a verifier on the command line to check its hash against the
one passed in via the SEV hash table.
The verifier is enabled if SEV memory encryption is active.
Cc: Laszlo Ersek
Cc: Ard Biesheuvel
From: James Bottomley
Support QEMU's -kernel option.
OvmfPkg/Library/PlatformBootManagerLibGrub/QemuKernel.c is an exact copy
of OvmfPkg/Library/PlatformBootManagerLib/QemuKernel.c .
Cc: Laszlo Ersek
Cc: Ard Biesheuvel
Cc: Jordan Justen
Cc: Ashish Kalra
Cc: Brijesh Singh
Cc: Erdem Aktas
On 05/23/21 18:12, Rebecca Cran wrote:
> On 5/23/2021 2:51 AM, Laszlo Ersek wrote:
>
>> On 05/21/21 20:28, Rebecca Cran wrote:
>>> Could someone review this please? I submitted it almost 2 weeks ago.
>> I've been aware of it, but I've not once launched (or even seen) Xcode,
>> so I can't verify
CC'ing the MdePkg maintainers (see "Maintainers.txt" and
"$EDK_TOOLS_PATH/Scripts/GetMaintainer.py").
On 05/24/21 06:50, Satoshi Tanda wrote:
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3325
(1) The BZ URL is incorrect; the right URL is
On 05/24/21 14:58, Sami Mujawar wrote:
> Hi Laszlo,
>
> Joey is not in office today. I will submit this patch shortly so that we can
> include this in the release.
Ah good, just seeing this now. Thanks!
Laszlo
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this
Hi Sami,
On 05/24/21 15:01, Sami Mujawar wrote:
> From: Andreas Sandberg
>
> Bugzilla: 3415 (https://bugzilla.tianocore.org/show_bug.cgi?id=3415)
>
> The GICv3 architecture supports up to 1020 ordinary interrupt
> lines. The actual number of interrupts supported is described by the
>
Looks good to me.
Reviewed-by: Sunny Wang
-Original Message-
From: Marcin Wojtas
Sent: Monday, May 24, 2021 1:29 PM
To: devel@edk2.groups.io
Cc: l...@nuviainc.com; ardb+tianoc...@kernel.org; Samer El-Haj-Mahmoud
; Sunny Wang ;
g...@semihalf.com; upstr...@semihalf.com; Marcin Wojtas
Looks good to me as well.
Reviewed-by: Sunny Wang
-Original Message-
From: Samer El-Haj-Mahmoud
Sent: Monday, May 24, 2021 7:00 PM
To: Marcin Wojtas ; devel@edk2.groups.io
Cc: l...@nuviainc.com; ardb+tianoc...@kernel.org; Sunny Wang
; g...@semihalf.com; upstr...@semihalf.com; Samer
Extend the SMBIOS support for RD-N2-Cfg1 platform. RD-N2-Cfg1 platform
is a derivative of the RD-N2 platform and so most of the table values
for RD-N2 platform is reused.
Signed-off-by: Pranav Madhu
Reviewed-by: Sami Mujawar
---
Add the RD-N2-Cfg1 platform identification values including the part
number and configuration number. This information will be used in
populating the SMBIOS tables.
Signed-off-by: Pranav Madhu
Reviewed-by: Sami Mujawar
---
Platform/ARM/SgiPkg/Include/SgiPlatform.h | 7 ++-
Enable ACPI CPPC mechanism for RD-N2-Cfg1 as defined by the ACPI
specification. The implementation uses AMU registers accessible as
Fixed-feature Hardware (FFixedHW) for monitoring the performance.
Non-secure SCMI fastchannels are used to communicate with SCP to set
the desired performance.
RD-N2-Cfg1 platform supports 2 LPI states, LPI1 (Standby WFI) and LPI3
(Power-down) and the cluster supports LPI2 (Power-down) state. The LPI
implementation also supports combined power state for core and cluster.
Signed-off-by: Pranav Madhu
Reviewed-by: Sami Mujawar
---
The RD-N2-Cfg1 platform includes eight single-thread CPUS. Each of the
CPUs include 64KB L1 Data cache, 64KB L1 Instruction cache and 1MB L2
cache. The platform also includes a system level cache of 8MB. Add PPTT
table for RD-N2-Cfg1 platform with this information.
Signed-off-by: Pranav Madhu
From: Aditya Angadi
Arm's RD-N2-Cfg1 platform is a variant of the RD-N2 platform. Compared
to RD-N2 platform, RD-N2-Cfg1 has a reduced core count of eight Neoverse
N2 CPUs and a smaller interconnect mesh. As part of the initial platform
support for RD-N2-Cfg1 platform, add the corresponding ACPI
Changes since V1:
- Updated the MADT table to fix the incorrect base addresses mentioned
for GICC, GICR, GICV and GICH.
- Addressed comments from Sami
- Picked up Sami's reviewed-by tags.
RD-N2-Cfg1 platform is a variant of the RD-N2 platform. The platform
is based on 8xMP1 Neoverse N2 CPUs,
FMMT will crash if there is no fv ext_header in a specific FV.
This patch is going to add a check point for this case.
Signed-off-by: Bob Feng
Cc: Liming Gao
Cc: Yuwei Chen
---
BaseTools/Source/C/FMMT/FmmtLib.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
42 matches
Mail list logo
