Hi,
> > SimicsOpenBoardPkg can partially boot QEMU with a minimum of changes. It
> > makes it into the DXE phase (where we'd eventually get a shell), but fails
> > to initialise SMM, so it can't load the variable driver in there. Many
> > drivers depend on the variable protocol, including
*Tools, CI, Code base construction meeting series*
*When:*
05/23/2022
4:30pm to 5:30pm
(UTC-07:00) America/Los Angeles
*Where:*
https://github.com/tianocore/edk2/discussions/2614
View Event ( https://edk2.groups.io/g/devel/viewevent?eventid=1496536 )
*Description:*
TianoCore community,
Compressing the CpuMpPei component results in it executing
from cached memory saving significant boot time.
Cc: Nate DeSimone
Cc: Chasel Chiu
Signed-off-by: Isaac Oram
---
.../Intel/WhitleyOpenBoardPkg/BoardPortTemplate/PlatformPkg.fdf | 2 +-
Benjamin,
Thanks for sharing, it is interesting that Simics gets that far. In looking at
the QemuPkg, I note that they have QEMU drivers for all the DXE and SMM HW
needs that likely explain . Timer, SMM access, SMM control, FVB services … I
haven’t gotten to the next level of details yet,
(CC Gerd, Isaac)
Comments inline.
On Mon, May 23, 2022 at 5:50 PM Benjamin Doron
wrote:
> Hi Theo and Nate,
> I took a brief look at this myself, because having an emulated environment
> would help me with my project. I didn't know then that QemuOpenBoardPkg was
> an accepted project this
Hi Theo and Nate,
I took a brief look at this myself, because having an emulated environment
would help me with my project. I didn't know then that QemuOpenBoardPkg was an
accepted project this year. OvmfPkg is large, I'm unfamiliar with QEMU's
codebase and I'm only minimally familiar with
DevicePathLib utilities are useful in PEI to locate the devices which need
an opal unlock on S3 resume. This commit reuses the implementation done
to support Standalone MM for PEI.
Signed-off-by: Mateusz Albecki
Cc: Michael D Kinney
Cc: Liming Gao
Cc: Zhiguang Liu
---
For NetworkPkg part: Reviewed-by: Maciej Rabeda
On 22 maj 2022 03:54, yi1 li wrote:
To meet the needs of WPA3 Enterprise, additional cipher algorithms
and TLS APIs need to be added.
Code branch: https://github.com/liyi77/edk2/tree/Add-TLS
Details as follows:
- TlsShutdown: Shutdown the TLS
On 5/20/22 10:27, Michael Roth wrote:
A full-featured SEV-SNP guest will not rely on the AP jump table, and
will instead use the AP Creation interface defined by the GHCB. However,
a guest is still allowed to use the AP jump table if desired.
However, unlike with SEV-ES guests, SEV-SNP guests
On 5/20/22 10:27, Michael Roth wrote:
A full-featured SEV-SNP guest will not rely on the AP jump table, and
will instead use the AP Creation interface defined by the GHCB. However,
a guest is still allowed to use the AP jump table if desired.
However, unlike with SEV-ES guests, SEV-SNP guests
kvm FSB clock is 1GHz, not 100 MHz. Timings are off by factor 10.
Fix all affected build configurations. Not changed: Microvm and
Cloudhw (they have already have the correct value), and Xen (has
no fixed frequency, the PCD is configured at runtime by platform
initialization code).
Fixes:
Hi,
Sorry to bother you folks, but I was wondering if you had this patchset on your
radar :)
Thanks for your time,
Sebastien
From: Boeuf, Sebastien
Sent: Tuesday, May 10, 2022 2:50 PM
To: devel@edk2.groups.io
Cc: Yao, Jiewen ; Justen, Jordan L
;
Hi Regina,
I am not sure if I can help you with exactly the approach you are describing.
Are you aware of the efi_gdb.py script in BaseToosl/Scripts?
This can be used to debug OVMF with Qemu and gdb.
See these messages:
https://edk2.groups.io/g/devel/message/89621
@Ni, Ray
I think EDK2 needs to provide a way for root port to operate without IO space
assigned in a platform-independent way. I can think of the following cases when
root port didn't get IO space:
1. We have run out of IO space but it's fine since the device under the root
port doesn't use
Same questions here. I don't think we should use the legacy Linux EFI
handover protocol for CC implementations, and the ordinary
LoadImage/StartImage based boot sequence already incorporates TPM
measurement, of which TDX and SEV/SNP are just a specialization.
So I don't understand why we need any
Fix Typo for 3:
->BlobMeasurementLib->TpmMeasurementLib->TpmMeasurementLibTdx
Should be: ->BlobMeasurementLib->TpmMeasurementLib->CcProtocol->Tdx
> -Original Message-
> From: devel@edk2.groups.io On Behalf Of Yao, Jiewen
> Sent: Monday, May 23, 2022 5:30 PM
> To: Xu, Min M ;
Hi
I am not clear about the design. Some questions:
1. This should be generic feature for trusted boot. Not TDX specific. Right?
2. Why we need BlobMeasurementLib?
We already have TpmMeasurementLib. Why we cannot use it?
3. Why we need BlobMeasurementLibTdx?
Even if we really need
> +EFI_STATUS
> +EFIAPI
> +MeasureKernelBlob (
> + IN CONST CHAR16 *BlobName,
> + IN UINT32BlobNameSize,
> + IN CONST VOID*BlobBase,
> + IN UINT32BlobSize
> + )
> +{
> + EFI_STATUSStatus;
> + UINT32MrIndex;
> + EFI_CC_EVENT *CcEvent;
> +
> + if
18 matches
Mail list logo
