Re: [edk2-devel] [PATCH v13 00/46] SEV-ES guest support
On 8/9/20 9:41 PM, Gao, Liming wrote: > > > -Original Message- > From: Laszlo Ersek > Sent: 2020年8月6日 23:39 > To: Tom Lendacky ; devel@edk2.groups.io > Cc: Brijesh Singh ; Ard Biesheuvel > ; Dong, Eric ; Justen, Jordan L > ; Gao, Liming ; Kinney, > Michael D ; Ni, Ray ; Andrew > Fish ; Anthony Perard ; You, > Benjamin ; Bi, Dandan ; Dong, > Guo ; Wu, Hao A ; Wang, Jian J > ; Julien Grall ; Leif Lindholm > ; Ma, Maurice > Subject: Re: [edk2-devel] [PATCH v13 00/46] SEV-ES guest support > > On 08/06/20 17:12, Tom Lendacky wrote: >> It looks like all the patches will have a Reviewed-by: or Acked-by: >> tag now. I just need to submit another version with the fix to address >> the >> IA32 issue that Laszlo found. After that, assuming it is looking good >> to include this series, there is still the question of the >> edk2-platform changes that are needed because of the library prereqs >> introduced by this series. >> >> I've updated the appropriate .dsc files in the edk2-platform tree >> locally and successfully test built some of the configs in the Intel >> sub-directory (KabylakeRvp3, WhiskeylakeURvp, CometlakeURvp). >> >> How would we approach applying this series and providing the updates >> to the edk2-platform at the same time? > > I don't have much experience with edk2-platforms. If I recall correctly, the > edk2 series is supposed to be merged in two parts, between which > edk2-platforms is supposed to be updated (meaning various edk2-platform > patches and an edk2 submodule update). In other words, if there is a way to > lay out the edk2 and edk2-platforms patches as one grand series, then that > order should be followed with the merges. > > In your v14 blurb, you can perhaps identify this split point (if there is > one), plus the edk2-platforms series that should be merged there, in the > middle. > > Thanks > Laszlo > > [Liming] First, please send the patches to edk2-platform tree, and make sure > they pass review also. The merge process is just Laszlo propose. The first 10 > patches in Edk2 will be merged first, then edk2-platforms changes will be > merged, last the remaining changes in Edk2 will be merged. After your patches > are ready for merge, I can help merge them in edk2 and edk2-platforms. I'll send the edk2-platforms patch for review as a reply to patch 10 of the series (the split point). Thanks, Tom > > Thanks > Liming > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#63912): https://edk2.groups.io/g/devel/message/63912 Mute This Topic: https://groups.io/mt/75892660/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v13 00/46] SEV-ES guest support
-Original Message- From: Laszlo Ersek Sent: 2020年8月6日 23:39 To: Tom Lendacky ; devel@edk2.groups.io Cc: Brijesh Singh ; Ard Biesheuvel ; Dong, Eric ; Justen, Jordan L ; Gao, Liming ; Kinney, Michael D ; Ni, Ray ; Andrew Fish ; Anthony Perard ; You, Benjamin ; Bi, Dandan ; Dong, Guo ; Wu, Hao A ; Wang, Jian J ; Julien Grall ; Leif Lindholm ; Ma, Maurice Subject: Re: [edk2-devel] [PATCH v13 00/46] SEV-ES guest support On 08/06/20 17:12, Tom Lendacky wrote: > It looks like all the patches will have a Reviewed-by: or Acked-by: > tag now. I just need to submit another version with the fix to address > the > IA32 issue that Laszlo found. After that, assuming it is looking good > to include this series, there is still the question of the > edk2-platform changes that are needed because of the library prereqs > introduced by this series. > > I've updated the appropriate .dsc files in the edk2-platform tree > locally and successfully test built some of the configs in the Intel > sub-directory (KabylakeRvp3, WhiskeylakeURvp, CometlakeURvp). > > How would we approach applying this series and providing the updates > to the edk2-platform at the same time? I don't have much experience with edk2-platforms. If I recall correctly, the edk2 series is supposed to be merged in two parts, between which edk2-platforms is supposed to be updated (meaning various edk2-platform patches and an edk2 submodule update). In other words, if there is a way to lay out the edk2 and edk2-platforms patches as one grand series, then that order should be followed with the merges. In your v14 blurb, you can perhaps identify this split point (if there is one), plus the edk2-platforms series that should be merged there, in the middle. Thanks Laszlo [Liming] First, please send the patches to edk2-platform tree, and make sure they pass review also. The merge process is just Laszlo propose. The first 10 patches in Edk2 will be merged first, then edk2-platforms changes will be merged, last the remaining changes in Edk2 will be merged. After your patches are ready for merge, I can help merge them in edk2 and edk2-platforms. Thanks Liming -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#63899): https://edk2.groups.io/g/devel/message/63899 Mute This Topic: https://groups.io/mt/75892660/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v13 00/46] SEV-ES guest support
On 08/06/20 17:12, Tom Lendacky wrote: > It looks like all the patches will have a Reviewed-by: or Acked-by: tag > now. I just need to submit another version with the fix to address the > IA32 issue that Laszlo found. After that, assuming it is looking good to > include this series, there is still the question of the edk2-platform > changes that are needed because of the library prereqs introduced by > this series. > > I've updated the appropriate .dsc files in the edk2-platform tree > locally and successfully test built some of the configs in the Intel > sub-directory (KabylakeRvp3, WhiskeylakeURvp, CometlakeURvp). > > How would we approach applying this series and providing the updates to > the edk2-platform at the same time? I don't have much experience with edk2-platforms. If I recall correctly, the edk2 series is supposed to be merged in two parts, between which edk2-platforms is supposed to be updated (meaning various edk2-platform patches and an edk2 submodule update). In other words, if there is a way to lay out the edk2 and edk2-platforms patches as one grand series, then that order should be followed with the merges. In your v14 blurb, you can perhaps identify this split point (if there is one), plus the edk2-platforms series that should be merged there, in the middle. Thanks Laszlo -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#63789): https://edk2.groups.io/g/devel/message/63789 Mute This Topic: https://groups.io/mt/75892660/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v13 00/46] SEV-ES guest support
It looks like all the patches will have a Reviewed-by: or Acked-by: tag now. I just need to submit another version with the fix to address the IA32 issue that Laszlo found. After that, assuming it is looking good to include this series, there is still the question of the edk2-platform changes that are needed because of the library prereqs introduced by this series. I've updated the appropriate .dsc files in the edk2-platform tree locally and successfully test built some of the configs in the Intel sub-directory (KabylakeRvp3, WhiskeylakeURvp, CometlakeURvp). How would we approach applying this series and providing the updates to the edk2-platform at the same time? Thanks, Tom On 7/31/20 6:54 AM, Laszlo Ersek via groups.io wrote: On 07/30/20 20:43, Tom Lendacky wrote: Changes since v12: - Change IA32 VMGEXIT .nasm file to issue an int 3. Depending on the version of NASM, the "BITS 64" trick to get NASM to recognize the VMMCALL instruction (VMGEXIT is a REP VMMCALL) caused an error. Since SEV-ES is X64 only, VMGEXIT should never be called in IA32. I've build-tested this series with various OvmfPkg and ArmVirtPkg platforms / settings (including Xen); it looks good. Build-tested-by: Laszlo Ersek Laszlo -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#63788): https://edk2.groups.io/g/devel/message/63788 Mute This Topic: https://groups.io/mt/75892660/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v13 00/46] SEV-ES guest support
On 07/30/20 20:43, Tom Lendacky wrote: > Changes since v12: > - Change IA32 VMGEXIT .nasm file to issue an int 3. Depending on the > version of NASM, the "BITS 64" trick to get NASM to recognize the > VMMCALL instruction (VMGEXIT is a REP VMMCALL) caused an error. Since > SEV-ES is X64 only, VMGEXIT should never be called in IA32. I've build-tested this series with various OvmfPkg and ArmVirtPkg platforms / settings (including Xen); it looks good. Build-tested-by: Laszlo Ersek Laszlo -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#63569): https://edk2.groups.io/g/devel/message/63569 Mute This Topic: https://groups.io/mt/75892660/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH v13 00/46] SEV-ES guest support
From: Tom Lendacky
This patch series provides support for running EDK2/OVMF under SEV-ES.
Secure Encrypted Virtualization - Encrypted State (SEV-ES) expands on the
SEV support to protect the guest register state from the hypervisor. See
"AMD64 Architecture Programmer's Manual Volume 2: System Programming",
section "15.35 Encrypted State (SEV-ES)" [1].
In order to allow a hypervisor to perform functions on behalf of a guest,
there is architectural support for notifying a guest's operating system
when certain types of VMEXITs are about to occur. This allows the guest to
selectively share information with the hypervisor to satisfy the requested
function. The notification is performed using a new exception, the VMM
Communication exception (#VC). The information is shared through the
Guest-Hypervisor Communication Block (GHCB) using the VMGEXIT instruction.
The GHCB format and the protocol for using it is documented in "SEV-ES
Guest-Hypervisor Communication Block Standardization" [2].
The main areas of the EDK2 code that are updated to support SEV-ES are
around the exception handling support and the AP boot support.
Exception support is required starting in Sec, continuing through Pei
and into Dxe in order to handle #VC exceptions that are generated. Each
AP requires it's own GHCB page as well as a page to hold values specific
to that AP.
AP booting poses some interesting challenges. The INIT-SIPI-SIPI sequence
is typically used to boot the APs. However, the hypervisor is not allowed
to update the guest registers. The GHCB document [2] talks about how SMP
booting under SEV-ES is performed.
Since the GHCB page must be a shared (unencrypted) page, the processor
must be running in long mode in order for the guest and hypervisor to
communicate with each other. As a result, SEV-ES is only supported under
the X64 architecture.
[1] https://www.amd.com/system/files/TechDocs/24593.pdf
[2] https://developer.amd.com/wp-content/resources/56421.pdf
---
These patches are based on commit:
e848b58d7c85 ("BaseTools/PeCoffLoaderEx: Remove the unused local variable")
A version of the tree can be found at:
https://github.com/AMDESE/ovmf/tree/sev-es-v21
Cc: Andrew Fish
Cc: Anthony Perard
Cc: Ard Biesheuvel
Cc: Benjamin You
Cc: Dandan Bi
Cc: Eric Dong
Cc: Guo Dong
Cc: Hao A Wu
Cc: Jian J Wang
Cc: Jordan Justen
Cc: Julien Grall
Cc: Laszlo Ersek
Cc: Leif Lindholm
Cc: Liming Gao
Cc: Maurice Ma
Cc: Michael D Kinney
Cc: Ray Ni
Changes since v12:
- Change IA32 VMGEXIT .nasm file to issue an int 3. Depending on the
version of NASM, the "BITS 64" trick to get NASM to recognize the
VMMCALL instruction (VMGEXIT is a REP VMMCALL) caused an error. Since
SEV-ES is X64 only, VMGEXIT should never be called in IA32.
Changes since v11:
- Make the XGETBV and VMGEXIT .nasm files buildable for all environments
and remove the updates that add these instructions to GccInline.c
Changes since v10:
- Fix conflicts around GccInline.c file after moving to latest commit
- Fix conflicts with OVMF PCD values after moving to latest commit
Changes since v9:
- Fixed bit field declarations in the GHCB structure to use UINT32
and not UINT64.
- Fixed a warning produced by VS2019 in the instruction parsing code
by expliciting casting a bit shift to an INT64.
- Sorted section entries in the OVMF VmgExitLib INF file.
- Moved the new Maintainers.txt entry so entries remain sorted.
- Documentation style fixes for return values.
- Miscellaneous code style fixes.
Changes since v8:
- Move IOIO exit info definitions into Ghcb.h file
- Add a macro for calculating IO instruction bytes (IOIO_DATA_BYTES)
- Exception handler support for debug registers
- Moved the DRx register saving changes into the UefiCpuPkg patch for
base #VC support in CpuExceptionHandlerLib.
- OvmfPkg VmgExitLib
- Remove the .uni file
- Update .inf file:
- New file location for VmgExitVcHandler.c
- Add additional Packages and LibraryClasses
- Introduce a header file to hold the #VC instruction parsing related
definitions
- Include additional #defines for instruction decoding to replace
hard coded values for things like instruction prefixes and escapes.
- Replace hardcoded CPUID values with values from existing header files
and use existing CR4 definition for accessing CR4 data.
- Change the type used for obtaining data addresses in the instruction
parsing
- Switch from INTN to UINT64 and use compiler conversions and casting
to perform the correct address calculation
- ResetVector code:
- Revert some inadvertant changes introduced in v7 for reserving the
SEV-ES work area memory and for checking the status of SEV-ES.
- AP Booting
- Provide support for non-broadcast INIT-SIPI-SIPI AP boot (minimize
code duplication by creating a function to set the AP jump table
vector address).
- Fix file/directory entry in maintainer changes.
- Various coding style fixes
- Commenting, if statements, etc.
- Various
