On 6/8/21 3:49 AM, Laszlo Ersek wrote:
> On 06/07/21 15:37, Brijesh Singh wrote:
>
>
...
> ... But maybe I just need to accept that we have to repurpose
> SEC_SEV_ES_WORK_AREA, considering it a super-early "HOB list" of sorts.
> Same as the PEI phase is considered the "HOB producer phase",
On 6/16/21 11:15 PM, Rebecca Cran via groups.io wrote:
> Is OvmfPkg/OvmfPkgIa32X64.dsc still supposed to work after the recent
> changes in OvmfPkg? I realized it's currently broken.
>
>
> bcran@photon:~/src/uefi/edk2> build -p OvmfPkg/OvmfPkgIa32X64.dsc -a X64
You need to also have "-a IA32"
On 6/21/21 8:57 AM, Ashish Kalra wrote:
> From: Ashish Kalra
>
> Detect for KVM hypervisor and check for SEV live migration
> feature support via KVM_FEATURE_CPUID, if detected setup a new
> UEFI enviroment variable to indicate OVMF support for SEV
> live migration.
>
> Signed-off-by: Ashish
On 6/21/21 8:56 AM, Ashish Kalra wrote:
> From: Ashish Kalra
>
> Add SEV and SEV-ES hypercall abstraction library to support SEV Page
> encryption/deceryption status hypercalls for SEV and SEV-ES guests.
Does this have to be a new library? It's just a single function and so I
would think it
On 6/21/21 8:57 AM, Ashish Kalra wrote:
> From: Brijesh Singh
>
> By default all the SEV guest memory regions are considered encrypted,
> if a guest changes the encryption attribute of the page (e.g mark a
> page as decrypted) then notify hypervisor. Hypervisor will need to
> track the
On 8/2/21 7:31 AM, Ashish Kalra wrote:
> From: Ashish Kalra
>
> Add support to check if we are running inside KVM HVM and
> KVM HVM supports SEV Live Migration feature.
>
> Cc: Jordan Justen
> Cc: Ard Biesheuvel
> Signed-off-by: Ashish Kalra
> ---
>
On 8/2/21 7:33 AM, Ashish Kalra wrote:
> From: Ashish Kalra
>
> Check for SEV live migration feature support, if detected
> setup a new UEFI enviroment variable to indicate OVMF
> support for SEV live migration.
>
> The new runtime UEFI environment variable is set via the
> notification
On 8/2/21 7:31 AM, Ashish Kalra wrote:
> From: Ashish Kalra
>
> Add API to issue hypercall on page encryption state change.
>
> By default all the SEV guest memory regions are considered encrypted,
> if a guest changes the encryption attribute of the page (e.g mark a
> page as decrypted) then
On 8/4/21 3:20 PM, Brijesh Singh wrote:
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3429
>
> Both the TDX and SEV support needs to reserve a page in MEMFD as a work
> area. The page will contain meta data specific to the guest type.
> Currently, the SEV-ES support reserves a page in
On 8/4/21 3:20 PM, Brijesh Singh wrote:
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3429
>
> Update the SEV support to switch to using the newer work area format.
>
> Cc: James Bottomley
> Cc: Min Xu
> Cc: Jiewen Yao
> Cc: Tom Lendacky
> Cc: Jordan Justen
> Cc: Ard Biesheuvel
>
On 8/4/21 3:20 PM, Brijesh Singh wrote:
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3429
>
> While build the initial page table, the SetCr3ForPageTables64 checks
> whether SEV-ES is enabled. If so, clear the page encryption mask from the
> GHCB page. Move the logic to clear the page
On 8/10/21 6:13 AM, Ashish Kalra wrote:
> Hello Tom,
>
> On Mon, Aug 09, 2021 at 09:29:29AM -0500, Tom Lendacky wrote:
>> On 8/2/21 7:33 AM, Ashish Kalra wrote:
>>
>> Should there be an "ASSERT_EFI_ERROR (Status)" after the DEBUG call?
>>
>
> I don't think we should do an assert here and abort
On 8/10/21 1:05 AM, Gerd Hoffmann wrote:
> Hi,
>
>>> I still really don't understand the need for the CPUID loop. KVM only ever
>>> programs CPUID function 0x4000, right?
>
> Nope. When you enable hyper-v emulation features you'll go find the kvm
> cpuid @ 0x4000 and the hyper-v cpuid
On 10/11/21 9:37 PM, Min Xu wrote:
RFC：
On 11/25/21 7:12 AM, qi zhou wrote:
From 5b10265fa5c7b5ca728b4f18488089de6535ed28 Mon Sep 17 00:00:00 2001
From: Qi Zhou
Date: Thu, 25 Nov 2021 20:25:55 +0800
Subject: [PATCH] OvmfPkg/MemEncryptSevLib: check CPUID when read msr during
PEI phase
Tested on Intel Platform, It is like 'SEV-ES
On 11/2/21 8:53 AM, Dov Murik wrote:
On 02/11/2021 15:29, Gerd Hoffmann wrote:
Hi,
I'm wondering whenever you actually tried to boot a sev guest
in microvm?
No I haven't tried. Do you want Microvm to be able to boot SEV guests,
or do you intentionally want to keep functionality out so
On 10/28/21 10:52 AM, Yao, Jiewen wrote:
Thanks Brijesh.
We can merge SNP patches at first, then decide next step. Not a problem.
TEE is just my initial thought. And I am open to change if we have a better
name.
We already have EFI_TEE_MEASUREMENT_PROTOCOL. I did not see your feedback on
On 11/4/21 3:10 AM, Gerd Hoffmann wrote:
On Wed, Nov 03, 2021 at 12:57:37PM +, Xu, Min M wrote:
On November 3, 2021 2:09 PM, Gerd Hoffmann wrote:
+++ b/UefiCpuPkg/Library/MpInitLib/X64/IntelTdcall.nasm
@@ -0,0 +1,120 @@
+;
On 7/20/21 3:03 AM, Dov Murik wrote:
> Round up the size of the SEV launch secret area to a whole page, as
> required by BuildMemoryAllocationHob. This will allow the secret
> area defined in the MEMFD to take less than a whole 4KB page.
>
> Cc: Ard Biesheuvel
> Cc: Jordan Justen
> Cc: Ashish
On 7/20/21 3:03 AM, Dov Murik wrote:
> In QemuKernelLoaderFsDxeEntrypoint we use FetchBlob to read the content
> of the kernel/initrd/cmdline from the QEMU fw_cfg interface. Insert a
> call to VerifyBlob after fetching to allow BlobVerifierLib
> implementations to add a verification step for
On 7/20/21 3:04 AM, Dov Murik wrote:
> Add an implementation for BlobVerifierLib that locates the SEV hashes
> table and verifies that the calculated hashes of the kernel, initrd, and
> cmdline blobs indeed match the expected hashes stated in the hashes
> table.
>
> If there's a missing hash or a
On 7/20/21 3:03 AM, Dov Murik wrote:
> This prepares the ground for calling VerifyBlob() in
> QemuKernelLoaderFsDxe.
>
> 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
On 7/20/21 3:04 AM, Dov Murik wrote:
> In the AmdSevX64 build, use BlobVerifierLibSevHashes to enforce
> verification of hashes of the kernel/initrd/cmdline blobs fetched from
> firmware config.
>
> This allows for secure (measured) boot of SEV guests with QEMU's
> -kernel/-initrd/-append
On 7/20/21 3:03 AM, Dov Murik wrote:
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3457
I believe the convention is that this line be in the individual patch
commit messages just like this (i.e. with the BZ: tag and the first line),
not as a Ref: tag at the end of the commit message.
I'll
On 7/20/21 3:03 AM, Dov Murik wrote:
> BlobVerifierLib will be used to verify blobs fetching them from QEMU's
> firmware config (fw_cfg) in platforms that enable such verification.
>
> The null implementation BlobVerifierLibNull treats all blobs as valid.
>
> Cc: Ard Biesheuvel
> Cc: Jordan
On 7/6/21 3:54 AM, Dov Murik wrote:
> From: James Bottomley
>
> Support QEMU's -kernel option.
>
> OvmfPkg/Library/PlatformBootManagerLibGrub/QemuKernel.c is an exact copy
> of OvmfPkg/Library/PlatformBootManagerLib/QemuKernel.c .
Just a nit, but this confused me initially. Maybe it should say
On 7/6/21 3:54 AM, Dov Murik wrote:
> Round up the size of the SEV launch secret area to a whole page, as
> required by BuildMemoryAllocationHob. This will allow the secret
> area defined in the MEMFD to take less than a whole 4KB page.
>
> Cc: Laszlo Ersek
> Cc: Ard Biesheuvel
> Cc: Jordan
On 7/6/21 3:54 AM, Dov Murik wrote:
> BlobVerifierLib will be used to verify blobs fetching them from QEMU's
> firmware config (fw_cfg) in platforms that enable such verification.
>
> The null implementation NullBlobVerifierLib treats all blobs as valid.
>
> Cc: Laszlo Ersek
> Cc: Ard
On 7/6/21 3:54 AM, Dov Murik wrote:
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3457
This BZ link should be part of all the commit messages in the series.
Thanks,
Tom
>
> Booting with SEV prevented the loading of kernel, initrd, and kernel
> command-line via QEMU fw_cfg interface
On 7/6/21 3:54 AM, Dov Murik wrote:
> From: James Bottomley
>
> Split the existing 4KB page reserved for SEV launch secrets into two
> parts: first 3KB for SEV launch secrets and last 1KB for firmware
> config hashes.
>
> The area of the firmware config hashes will be attested (measured) by
>
On 7/6/21 3:55 AM, Dov Murik wrote:
> Add an implementation for BlobVerifierLib that locates the SEV hashes
> table and verifies that the calculated hashes of the kernel, initrd, and
> cmdline blobs indeed match the expected hashes stated in the hashes
> table.
>
> If there's a missing hash or a
On 7/6/21 3:54 AM, Dov Murik wrote:
> In QemuKernelLoaderFsDxeEntrypoint we use FetchBlob to read the content
> of the kernel/initrd/cmdline from the QEMU fw_cfg interface. Insert a
> call to VerifyBlob after fetching to allow BlobVerifierLib
> implementations to add a verification step for these
On 7/6/21 3:55 AM, Dov Murik wrote:
> In the AmdSevX86 build, use SevHashesBlobVerifierLib to enforce
> verification of hashes of the kernel/initrd/cmdline blobs fetched from
> firmware config.
>
> This allows for secure (measured) boot of SEV guests with QEMU's
> -kernel/-initrd/-append switches
On 7/19/21 2:09 AM, Ard Biesheuvel via groups.io wrote:
> On Mon, 19 Jul 2021 at 05:14, Ni, Ray wrote:
>>
>> This change generates the reset vector binary which only contains 1G page
>> table. If a platform doesn't support 1G page table, this will cause system
>> hang.
>>
>> To Ard and Jordan,
On 7/19/21 2:47 PM, Dov Murik wrote:
> On 19/07/2021 20:28, Tom Lendacky wrote:
>> On 7/6/21 3:55 AM, Dov Murik wrote:
>
>>> +[Defines]
>>> + INF_VERSION= 0x00010005
>>> + BASE_NAME = SevHashesBlobVerifierLib
>
> But is this BASE_NAME okay?
>
> Or
On 7/22/21 12:52 AM, Min Xu wrote:
> RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3429
>
> In Tdx all CPUs "reset" to run on 32-bit protected mode with flat
> descriptor (paging disabled). But in Non-Td guest the initial state of
> CPUs is 16-bit real mode. To resolve this conflict, BITS
On 7/8/21 9:08 AM, Ashish Kalra wrote:
> From: Ashish Kalra
>
The subject isn't correct since the #VC handler already supports
hypercalls. It should say something like "Make the #VC handler aware of
the encryption state change hypercall" or "Update the #VC handler to
support the encryption
On 7/8/21 9:08 AM, Ashish Kalra wrote:
> From: Ashish Kalra
>
> Mark the SEC GHCB page (that is mapped as unencrypted in
> ResetVector code) in the hypervisor page status tracking.
>
> Cc: Jordan Justen
> Cc: Laszlo Ersek
> Cc: Ard Biesheuvel
> Signed-off-by: Ashish Kalra
> ---
>
On 7/8/21 9:07 AM, Ashish Kalra wrote:
> From: Ashish Kalra
>
The patch subject is a bit confusing. Something more like "Add API to
issue hypercall on page encryption state change" or similar, since this is
issued for changes to shared and private, not just shared.
> By default all the SEV
On 7/22/21 5:58 PM, Xu, Min M wrote:
> On July 23, 2021 1:08 AM, Tom Lendacky wrote:
>> On 7/22/21 12:52 AM, Min Xu wrote:
>>> RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3429
>>>
>>> diff --git a/OvmfPkg/ResetVector/Ia32/Flat32ToFlat64.asm
>>> b/OvmfPkg/ResetVector/Ia32/Flat32ToFlat64.asm
On 7/27/21 6:16 AM, Brijesh Singh wrote:
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275
>
> The PageTables64.asm was created to provide routines to set the CR3
> register for 64-bit paging. During the SEV support, it grew to include a
> lot of the SEV stuff. Before adding more SEV
On 1/10/22 9:29 AM, Peter Gonda wrote:
On Fri, Jan 7, 2022 at 3:54 PM Tom Lendacky wrote:
On 1/7/22 11:04 AM, Peter Gonda wrote:
The SEV-ES bit of Fn800-001F[EAX] - Bit 3 is used for a host to
determine support for running SEV-ES guests. It should not be checked by
a guest to determine if it
Is there a new minimum version of NASM required for the build? The
following commit causes the build to fail on my Ubuntu 20.04 system:
d3febfd9ade3 ("MdePkg: Replace Opcode with the corresponding instructions.")
Specifically the opcode changes in LongJump.nasm:
On 2/16/22 12:06, Aaron Young via groups.io wrote:
We have encountered another regression related to SEV support resulting in a
reset loop with Intel/Win2012R2 guests.
NOTE that I reported this several months ago here (which contains more
details):
On 2/2/22 14:54, Rebecca Cran wrote:
VmgExitLib fails to build with the CLANG38 toolset (clang 13.0.0):
edk2/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c:1875:9: error: variable
'Compacted' is used uninitialized whenever 'if' condition is false [-Werror,-W
sometimes-uninitialized]
if
On 1/7/22 11:04 AM, Peter Gonda wrote:
The SEV-ES bit of Fn800-001F[EAX] - Bit 3 is used for a host to
determine support for running SEV-ES guests. It should not be checked by
a guest to determine if it is running under SEV-ES. The guest should use
the SEV_STATUS MSR Bit 1 to determine if SEV-ES
On 1/13/22 10:30 AM, Peter Gonda wrote:
The SEV-ES bit of Fn800-001F[EAX] - Bit 3 is used for a host to
determine support for running SEV-ES guests. It should not be checked by
a guest to determine if it is running under SEV-ES. The guest should use
the SEV_STATUS MSR Bit 1 to determine if
On 4/12/22 16:00, James Bottomley via groups.io wrote:
I've identified a serious performance regression in recent edk2, so
I've been trying to identify it by bisection, but it seems that the TDX
patches have broken bisection in edk2. You can see this by trying to
checkout b6b2de884864 and build
On 3/29/22 18:46, Min Xu wrote:
RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3429
TdxDxe driver is dispatched early in DXE, due to being list in APRIORI.
This module is responsible for below features:
- Sets max logical cpus based on TDINFO
- Sets PCI PCDs based on resource hobs
-
On 3/29/22 18:46, Min Xu wrote:
RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3429
There are below major changes in this commit.
1. SecEntry.nasm
In TDX BSP and APs goes to the same entry point in SecEntry.nasm.
BSP initialize the temporary stack and then jumps to SecMain, just as
On 11/6/23 16:45, Lendacky, Thomas via groups.io wrote:
The CPUID_EXTENDED_TOPOLOGY CPUID leaf takes a subleaf as input when
returning CPUID information. However, the AsmCpuid() function does not
zero out ECX before the CPUID instruction, so the input leaf is used as
the sub-leaf for the CPUID
This patch series provides fixes around AP startup and sorting:
- The CPUID_EXTENDED_TOPOLOGY CPUID leaf takes a sub-leaf as input. The
current SEV-SNP support is attempting to retrieve the this leaf with
sub-leaf 0, but is calling AsmCpuid(), which does not clear ECX before
invoking the
With SEV-SNP, the SEV-ES save area for a vCPU should be unique to that
vCPU. After commit 3323359a811a, the VMSA allocation was re-used, but when
sorting the CPUs by APIC ID, the save area was not updated to follow the
original CPU. Similar to the StartupApSignal address, the SevEsSaveArea
address
The CPUID_EXTENDED_TOPOLOGY CPUID leaf takes a subleaf as input when
returning CPUID information. However, the AsmCpuid() function does not
zero out ECX before the CPUID instruction, so the input leaf is used as
the sub-leaf for the CPUID request and returns erroneous/invalid CPUID
data, since the
On 10/27/23 03:05, Tan, Dun wrote:
Hi all,
Could you please help to review this patch set? In this patch set, the IoLib
instance BaseIoLibIntrinsic is modified to support AMD SEV feature and the
BaseIoLibIntrinsicSev is removed.
Also could you help to do a test on AMD processor to make sure
On 9/19/23 02:59, Gerd Hoffmann wrote:
On Fri, Jul 14, 2023 at 03:28:26PM -0500, Tom Lendacky wrote:
Commit 63c50d3ff2854a76432b752af4f2a76f33ff1974 changed the check that is
used to determine if SEV-ES is active. Originally, a CMP instruction with
a supporting JZ instruction was used for the
On 4/19/22 00:06, Yao, Jiewen wrote:
OK. Let me describe what I think.
PCI Express BAR need to be initialized by someone in the platform.
This initialization may require CFG8. That is understandable.
A good design is that: After the PCIE BAR is initialized, it can be accessed.
Requires
On 4/18/22 23:47, Yao, Jiewen wrote:
Can SEV clear the C-bit in SEC phase?
Not really. IIRC, even if cleared in the SEC phase, the DXE phase replaces
the page tables and it has to be cleared again.
Thanks,
Tom
I think that is right way to ensure PCI Express can always be accessed by
On 4/19/22 08:16, Tom Lendacky wrote:
On 4/18/22 19:26, Min Xu wrote:
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3902
CcProbeLib is imported in BaseIoLibIntrinsicSev.
OvmfPkg/Library/CcProbeLib is the OvmfPkg version which checks
OvmfWorkArea to return the Cc guest type. It is included
On 4/18/22 19:26, Min Xu wrote:
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3902
CcProbeLib is imported in BaseIoLibIntrinsicSev.
OvmfPkg/Library/CcProbeLib is the OvmfPkg version which checks
OvmfWorkArea to return the Cc guest type. It is included
in OvmfPkgX64.dsc and
On 5/16/22 15:24, Lendacky, Thomas via groups.io wrote:
The BaseMemEncryptSevLib functionality was updated to rely on the use of
the OVMF/SEV workarea to check for SEV guests. However, this area is only
updated when running the X64 OVMF build, not the hybrid Ia32/X64 build.
Base SEV support
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
On 6/1/22 07:25, Ard Biesheuvel wrote:
On Tue, 31 May 2022 at 16:40, Peter Gonda wrote:
The SEV-ES bit of Fn800-001F[EAX] - Bit 3 is used for a host to
determine support for running SEV-ES guests. It should not be checked by
a guest to determine if it is running under SEV-ES. The guest should
On 5/13/22 08:22, 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/13/22 08:22, Michael Roth wrote:
The Confidential Computing blob defined here is intended to match the
definition defined by linux guest kernel. Previously, both definitions
relied on natural alignment, but that relies on both OVMF and kernel
being compiled as 64-bit. While there aren't
On 5/11/22 19:52, Min Xu via groups.io wrote:
On May 11, 2022 10:06 PM, Lendacky, Thomas wrote:
On 5/10/22 21:00, Xu, Min M wrote:
On May 11, 2022 4:30 AM, Tom Lendacky wrote:
I'm replying to this patch since I can't find patch V12 46/47
anywhere in my email.
I've bisected a regression in
On 5/7/22 10:13, Ray Ni wrote:
Probably should have a commit message here explaining the reason for the
changes.
Overall, this works, but it does seem strange to have the SwitchToRealProc
procedure in the middle of the RendezvousFunnelProc procedure. Not sure if
it would be worth just
On 5/16/22 02:14, Ray Ni wrote:
The patch does several simplifications:
1. Treat SwitchToRealProc as part of RendezvousFunnelProc.
So the common logic in MpLib.c doesn't need to be aware of
SwitchToRealProc.
As a result, SwitchToRealSize/Offset are removed from
Explicitly adding Liming to the To: line for visibility.
Thanks,
Tom
On 5/17/22 11:29, Ard Biesheuvel wrote:
On Tue, 17 May 2022 at 18:26, Tom Lendacky wrote:
On 5/16/22 15:24, Lendacky, Thomas via groups.io wrote:
The BaseMemEncryptSevLib functionality was updated to rely on the use
The BaseMemEncryptSevLib functionality was updated to rely on the use of
the OVMF/SEV workarea to check for SEV guests. However, this area is only
updated when running the X64 OVMF build, not the hybrid Ia32/X64 build.
Base SEV support is allowed under the Ia32/X64 build, but it now fails
to boot
On 6/16/22 00:51, Gerd Hoffmann wrote:
Hi,
Tom Lendacky's suggestion for SEV-SNP is to pre-accept all memory under
4GB to make all that complexity go away. Only this approach worked in my
own testing. With the MMIO hole it's just validating 3GB of memory.
Accepting all memory under 4GB
On 6/16/22 11:44, Dionna Amalie Glaze wrote:
A question: is there some performance impact when accepting all memory under
4GB?
On SEV-SNP, we accept the HOBs 0-0xA000 and 0x10_-0xC00_,
which takes a couple seconds, which is non-negligible.
Are you possibly including the memory
On 4/15/22 19:13, Xu, Min M wrote:
On April 16, 2022 4:05 AM, Tom Lendacky wrote:
#define SEC_IDT_ENTRY_COUNT 34
@@ -738,6 +737,20 @@ SecCoreStartupWithStack (
UINT32Index;
volatile UINT8*Table;
+ #if defined (TDX_GUEST_SUPPORTED)
+ if (TdIsEnabled ()) {
On 4/15/22 20:57, Xu, Min M wrote:
On April 16, 2022 4:52 AM, Lendacky, Thomas wrote:
Unfortunately, this driver also breaks SEV-ES. I bypassed the TDX code in the
SEC library, but then hit an issue because this driver is loaded before the
AmdSevDxe driver. The AmdSevDxe driver performs a
On 4/16/22 22:01, Min Xu wrote:
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3902
The confidential computing guest type (GUEST_TYPE) was defined in
OvmfPkg/Include/WorkArea.h. Now it is to be moved to
MdePkg/Include/ConfidentialComputingGuestAttr.h and renamed as
CC_GUEST_TYPE.
There are
On 4/16/22 19:56, Xu, Min M wrote:
On April 16, 2022 11:09 PM, Lendacky, Thomas wrote:
On 4/15/22 20:57, Xu, Min M wrote:
On April 16, 2022 4:52 AM, Lendacky, Thomas wrote:
Unfortunately, this driver also breaks SEV-ES. I bypassed the TDX
code in the SEC library, but then hit an issue
On 4/16/22 22:01, Min Xu wrote:
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3902
Bad IO performance in SEC phase is observed after TDX features was
introduced. (after commit b6b2de884864 - "MdePkg: Support mmio for
Tdx guest in BaseIoLibIntrinsic").
This is because IsTdxGuest() will be
On 4/16/22 22:01, Min Xu wrote:
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3902
CcProbeLib is imported in BaseIoLibIntrinsicSev.
OvmfPkg/Library/CcProbeLib is the OvmfPkg version which checks
OvmfWorkArea to return the Cc guest type. It is included
in OvmfPkgX64.dsc and
On 3/29/22 18:46, Min Xu wrote:
RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3429
In TDVF BSP and APs are simplified. BSP is the vCPU-0, while the others
are treated as APs.
So MP intialization is rather simple. ApWorker is not supported, BSP is
always the working processor, while the
On 2/28/22 01:21, Min Xu via groups.io wrote:
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3711
Per SDM, changing the mode of APIC timer (from one-shot to periodic or
vice versa) by writing to the timer LVT entry does not start the timer.
To start the timer, it is necessary to write to
On 5/9/22 18:37, Xu, Min M wrote:
On May 10, 2022 1:30 AM, Tom Lendacky wrote:
On 5/9/22 07:44, Xu, Min M wrote:
Gerd & Tom
What are your comments about this patch-set?
Hi Min,
This appears to resolve the issue. I was able to boot a 64 vCPU guest in
legacy, SEV, SEV-ES and SEV-SNP modes
On 5/9/22 18:37, Xu, Min M wrote:
On May 10, 2022 1:30 AM, Tom Lendacky wrote:
On 5/9/22 07:44, Xu, Min M wrote:
Gerd & Tom
What are your comments about this patch-set?
Hi Min,
This appears to resolve the issue. I was able to boot a 64 vCPU guest in
legacy, SEV, SEV-ES and SEV-SNP modes
art bisecting to see which commit introduced that.
Thanks,
Tom
thanks,
ray
--
*From:* devel@edk2.groups.io on behalf of Lendacky,
Thomas via groups.io
*Sent:* Tuesday, May 10, 2022 5:39:51 AM
*To:* devel@edk2.groups.io ; Ni,
now. I'll follow up with Min.
Thanks,
Tom
Thanks,
Tom
thanks,
ray
--
*From:* devel@edk2.groups.io on behalf of
Lendacky, Thomas via groups.io
*Sent:* Tuesday, May 10, 2022 5:39:51 AM
*To:* devel@edk2.groups.io ; Ni,
On 5/10/22 21:00, Xu, Min M wrote:
On May 11, 2022 4:30 AM, Tom Lendacky wrote:
On 2/28/22 01:21, Min Xu via groups.io wrote:
BZ:
On 5/9/22 07:44, Xu, Min M wrote:
Gerd & Tom
What are your comments about this patch-set?
Hi Min,
This appears to resolve the issue. I was able to boot a 64 vCPU guest in
legacy, SEV, SEV-ES and SEV-SNP modes without any asserts.
I'm assuming that you were able to see the ASSERTs on your
On 5/9/22 06:54, Ni, Ray wrote:
Tom,
Can you please review this change? Does it cause any regression to SEV feature?
Hi Ray,
I just got back from vacation today and I'm going through all my email.
I'll take a look as soon as I can.
Thanks,
Tom
-Original Message-
From:
Hi Ray,
Do you have a public git tree with these patches that I can use to test
with? I'm having lots of problems pulling these patches out of my mail
client and applying them.
Thanks,
Tom
On 5/7/22 10:13, Ni, Ray via groups.io wrote:
Ray Ni (4):
MpInitLib: Allocate code buffer for PEI
On 8/23/22 03:40, Xu, Min M wrote:
On August 23, 2022 3:38 PM, Gerd Hoffmann wrote:
Hi,
Ah, I forget to reserve the work-area as RT_Data in below code:
BuildMemoryAllocationHob (
(EFI_PHYSICAL_ADDRESS)(UINTN)FixedPcdGet32
(PcdOvmfWorkAreaBase),
On 8/26/22 18:07, Min Xu wrote:
From: Min M Xu
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3974
CcProbeLib once was designed to probe the Confidential Computing guest
type by checking the PcdOvmfWorkArea. But this memory is allocated with
either EfiACPIMemoryNVS or EfiBootServicesData.
On 8/16/22 02:57, Yuanhao Xie via groups.io wrote:
To remove the dependency of CPU register, 4/8 byte at the top of the stack
is occupied for CpuMpData. BIST information is also taken care here.
This modification is only for PEI phase, since in DXE phase CpuMpData is
accessed via global
On 8/27/22 01:21, Min Xu wrote:
From: Jiaqi Gao
RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3937
When CoreAllocatePages() / CoreAllocatePool() meets error of
EFI_OUT_OF_RESOURCES, locate the EdkiiMemoryAcceptProtocol and accept extra
memory dynamically.
Firstly, find the unaccpeted
On 8/21/22 21:23, Min Xu wrote:
From: Min M Xu
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3974
Ovmf work-area (PcdOvmfWorkArea) was designed to store the Confidential
Computing guest information, including the CC guest type. This
information will be probed by CcProbeLib so that the CC
On 8/29/22 22:20, Xu, Min M wrote:
On August 30, 2022 4:47 AM, Lendacky, Thomas wrote:
On 8/27/22 01:21, Min Xu wrote:
From: Jiaqi Gao
RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3937
When CoreAllocatePages() / CoreAllocatePool() meets error of
EFI_OUT_OF_RESOURCES, locate the
On 9/28/22 10:33, Dionna Glaze wrote:
From: Sophia Wolf
When a guest OS does not support unaccepted memory, the unaccepted
memory must be accepted before returning a memory map to the caller.
EfiMemoryAcceptProtocol is defined in MdePkg and is implemented /
Installed in AmdSevDxe for AMD
On 9/23/22 14:34, Dionna Amalie Glaze wrote:
Ah yes, I did forget to include that patch. Will add to v2. I was just
setting the ResourceType to unaccepted and skipping the Prevalidate call
in PlatformPei if the start address is greater or equal to SIZE_4GB. That
seemed more self-contained than
On 9/22/22 15:50, Dionna Glaze wrote:
These three patches build on the lazy-accept patch series
"Introduce Lazy-accept for Tdx guest"
by adding SEV-SNP support for the MemoryAccept protocol, and
importantly making eager memory acceptance the default behavior.
For unaccepted memory to be
On 9/22/22 15:50, Dionna Glaze wrote:
From: Sophia Wolf
When a guest OS does not support unaccepted memory, the unaccepted
memory must be accepted before returning a memory map to the caller.
EfiMemoryAcceptProtocol is defined in MdePkg and is implementated /
Installed in AmdSevDxe for AMD
On 9/23/22 15:34, Dionna Glaze wrote:
From: Sophia Wolf
When a guest OS does not support unaccepted memory, the unaccepted
memory must be accepted before returning a memory map to the caller.
EfiMemoryAcceptProtocol is defined in MdePkg and is implementated /
Installed in AmdSevDxe for AMD
1 - 100 of 300 matches
Mail list logo
