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 should not
store/retrieve the jump table
This needs to be set so that UefiCpuPkg can locate the SEV-SNP secrets
page later to set the AP Jump Table address.
Signed-off-by: Michael Roth
---
OvmfPkg/AmdSev/AmdSevX64.dsc| 3 +++
OvmfPkg/CloudHv/CloudHvX64.dsc | 3 +++
OvmfPkg/IntelTdx/IntelTdxX64.dsc| 3 +++
OvmfPkg will initially use this to hand off the secrets page address to
UefiCpuPkg, which will need this PCD to access the SEV-SNP secrets page
address. Define this as an MdePkg PCD so it can be accessed by other
packages alongside the secrets page struct defined in MdePkg/Include.
Signed-off-by:
This will be needed so that the AP Jump Table address can be stored for
use by the operating system later, and possibly for other things in the
future.
Signed-off-by: Michael Roth
---
MdePkg/Include/Register/Amd/SnpSecretsPage.h | 56
1 file changed, 56 insertions(+)
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 should not
store/retrieve the jump table
Original Message-
> > From: devel@edk2.groups.io On Behalf Of Michael Roth
> > via groups.io
> > Sent: Monday, May 16, 2022 8:02 PM
> > To: devel@edk2.groups.io
> > Cc: Tom Lendacky
> > Subject: [edk2-devel] [PATCH v2] UefiCpuPkg: Store SEV-SNP AP jum
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 should not
store/retrieve the jump table
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 currently any plans to
enable SNP support
On Fri, May 13, 2022 at 08:56:06AM -0500, Tom Lendacky wrote:
> 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
On Fri, May 13, 2022 at 08:32:38AM -0500, Tom Lendacky wrote:
> 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
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 should not
store/retrieve the jump table
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 currently any plans to
enable SNP support
On Wed, Sep 22, 2021 at 09:55:58AM +0200, Gerd Hoffmann wrote:
> Hi,
>
> > +; If SEV-SNP is enabled, use the CPUID page to handle the CPUID
> > +; instruction.
> > +mov ecx, SEV_STATUS_MSR
> > +rdmsr
> > +bt eax, 2
> > +jc SnpCpuidLookup
>
> Maybe check
13 matches
Mail list logo
