From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) by mx.groups.io with SMTP id smtpd.web11.3141.1589051403759223828 for ; Sat, 09 May 2020 12:10:04 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@apple.com header.s=20180706 header.b=FCqc3xkt; spf=pass (domain: apple.com, ip: 17.171.2.72, mailfrom: afish@apple.com) Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.42/8.16.0.42) with SMTP id 049J6Oio012900; Sat, 9 May 2020 12:09:59 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=UvUkxWdEB5eTYW9TYCszRRoTtsdByK/hk6yU9CMgLBw=; b=FCqc3xktf1QfcEi2ZprifBYgDkuc0N5GEwmgVtD4nxQ/Z7RIkDzTEHc9bRTy7+VvEJ2G v+kLwDKOJQaHXgQzM26T1aL8jOs3dyY9cqtX5hX1/FwXECcqSLeGR0Gmu0ucJj7x/vnT yiAkM9wXOI+IZ5iQ9rKlvpbfknJsg7H+UFjH05QvDf7+i3EBRHttCk0zmspIB4kMy08u MIVgCtfwjquBspCVKgGIAQQ4AHI/6bkcglgJRiX4DIYa5HNGUmDGazi6CfskWgl2mbnX 4UDE/pCc5ilrJ3vplvJ0g6c45uQEe0mzoSM2Y9L2y1MTscYxs4hsbbnG5ga4EmFyR/bj yQ== Received: from rn-mailsvcp-mta-lapp04.rno.apple.com (rn-mailsvcp-mta-lapp04.rno.apple.com [10.225.203.152]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 30wugv5auj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 09 May 2020 12:09:59 -0700 Received: from rn-mailsvcp-mmp-lapp01.rno.apple.com (rn-mailsvcp-mmp-lapp01.rno.apple.com [17.179.253.14]) by rn-mailsvcp-mta-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPS id <0QA2002BSVWMY960@rn-mailsvcp-mta-lapp04.rno.apple.com>; Sat, 09 May 2020 12:09:58 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp01.rno.apple.com by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) id <0QA200S00VMU4D00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Sat, 09 May 2020 12:09:58 -0700 (PDT) X-Va-A: X-Va-T-CD: 678bf7de5df0d9ff994f556fd1b44182 X-Va-E-CD: ff690b989b3533ec55b283e20a1c43de X-Va-R-CD: bc4141a4b9746a83f71691105fca1ae2 X-Va-CD: 0 X-Va-ID: 5d8ca3f2-64b7-4531-ab16-a5604c19aae8 X-V-A: X-V-T-CD: 678bf7de5df0d9ff994f556fd1b44182 X-V-E-CD: ff690b989b3533ec55b283e20a1c43de X-V-R-CD: bc4141a4b9746a83f71691105fca1ae2 X-V-CD: 0 X-V-ID: a11209c9-d2ba-4d60-87b6-436d58cdc6ad X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216,18.0.676 definitions=2020-05-09_07:2020-05-08,2020-05-09 signatures=0 Received: from [17.235.36.125] (unknown [17.235.36.125]) by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPSA id <0QA20012WVWKNT00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Sat, 09 May 2020 12:09:57 -0700 (PDT) From: "Andrew Fish" Message-id: MIME-version: 1.0 (Mac OS X Mail 13.0 \(3594.4.17\)) Subject: Re: [edk2-devel] [PATCH v7 00/43] SEV-ES guest support Date: Sat, 09 May 2020 12:09:55 -0700 In-reply-to: Cc: "Ni, Ray" , Jordan Justen , Laszlo Ersek , Ard Biesheuvel , Mike Kinney , "Gao, Liming" , "Dong, Eric" , Brijesh Singh , "You, Benjamin" , "Bi, Dandan" , "Dong, Guo" , "Wu, Hao A" , "Wang, Jian J" , "Ma, Maurice" To: devel@edk2.groups.io, thomas.lendacky@amd.com References: <4da69262-e6a8-1374-2853-dab2a8f193d3@amd.com> <734D49CCEBEEF84792F5B80ED585239D5C530D55@SHSMSX104.ccr.corp.intel.com> X-Mailer: Apple Mail (2.3594.4.17) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216,18.0.676 definitions=2020-05-09_07:2020-05-08,2020-05-09 signatures=0 Content-type: multipart/alternative; boundary="Apple-Mail=_971305DA-2E39-49C9-A081-772758697944" --Apple-Mail=_971305DA-2E39-49C9-A081-772758697944 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On May 9, 2020, at 7:34 AM, Lendacky, Thomas w= rote: >=20 > On 5/9/20 1:44 AM, Ni, Ray wrote: >> Tom, >=20 > Hi Ray, >=20 >> I have a bit concern on your change that directly modifies CpuException= HandlerLib to handle >> exception #29. Today's CpuExceptionHandlerLib simplify dumps the except= ion context for >> every exception. Any component which wants to do specific handling of c= ertain exceptions >> should call RegisterCpuInterruptHandler(). Such as code in CpuDxe drive= r: >> if (HEAP_GUARD_NONSTOP_MODE || NULL_DETECTION_NONSTOP_MODE) { >> RegisterCpuInterruptHandler (EXCEPT_IA32_DEBUG, DebugExceptionHandl= er); >> RegisterCpuInterruptHandler (EXCEPT_IA32_PAGE_FAULT, PageFaultExcep= tionHandler); >> } >> Is it possible for your feature to follow the same pattern? >=20 > There are two problems: >=20 > The first is that RegisterCpuInterruptHandler() is not implemented for b= oth the SEC and PEI phases, so it is not currently possible to register a h= andler that early. >=20 > The second is that I need to be able to propagate an exception request f= rom the hypervisor. With the current implementation there doesn't appear to= be an easy way to perform this propagation. >=20 > If there's a way to accomplish both of the above I wouldn't be opposed t= o using RegisterCpuInterruptHandler() as long as there are no #VCs that can= occur between initializing exception handling and and registering the #VC = handler. >=20 Thomas, As you point out it is tricky dealing with XIP code. You can't have global= s that you can write and generally you use a PEI service to look tings up, = the most common thing being using a HOB. But SEC has no services and I'm no= t sure you really want to be calling into the PEI Core on a random excepti= on.=20 Here are the best options that popped into my head after reading your emai= l 1) IDT in RAM If your code populates the IDT the IDTR gives you access to the address of= the IDTR via an instruction. The PI Spec reserves IDT - sizeof (UNITN) for= a cached copy of the PEI Services Table, but otther than that you are good= to go. It should be possible to have a global so you can have the table re= quired to implement RegisterCpuInterruptHandler(). There might be some usag= e of IDT - ( 2* sizeof(UINTN)), I know I'm guilty, so storing data after t= he IDT would be a good option. In general if your code allocates the memory= for the IDT then you can treat the IDT as part of your private context dat= a structure and that gives you access=20 2) IDT in ROM.=20 For this it seems like you need a library to link in to the CpuExceptionHa= ndlerLib that allows you to override the handler. If CpuInterruptHandlerOve= rride() returns NULL you do the current behavior if not NULL then you call = the returned handler.=20 EFI_CPU_INTERRUPT_HANDLER EFIAPI OverrideCpuInterruptHandler ( IN EFI_EXCEPTION_TYPE InterruptType ); Thanks, Andrew Fish PS Off topic, but it would also be useful to have a library that overrides= the state dump display. For example using Xcode you can always display a s= tack frame from the exception handler.=20 > Thanks, > Tom >=20 >> Thanks, >> Ray >>> -----Original Message----- >>> From: Tom Lendacky >>> Sent: Saturday, May 9, 2020 3:16 AM >>> To: devel@edk2.groups.io >>> Cc: Justen, Jordan L ; Laszlo Ersek ; Ard Biesheuvel >>> ; Kinney, Michael D ; Gao, Liming ; Dong, >>> Eric ; Ni, Ray ; Brijesh Singh = ; You, Benjamin >>> ; Bi, Dandan ; Dong, Guo = ; Wu, Hao A >>> ; Wang, Jian J ; Ma, Mauric= e >>> Subject: Re: [PATCH v7 00/43] SEV-ES guest support >>>=20 >>> I was able to use the pull request method that Laszlo documented and f= ixed >>> up all of the issues identified by the VS compiler. >>>=20 >>> An additional change I'm planning to make for the next version (v8) of= the >>> patches is to create a NULL library instance of the VmgExitLib that wi= ll >>> also include the #VC handler function. This will reduce the amount of = code >>> associated with this feature for platforms that don't use/support SEV-= ES. >>>=20 >>> Laszlo, this will mean that I will introduce a version of the VmgExitL= ib >>> under OvmfPkg that will provide the majority of the functionality that= is >>> present today in UefiCpuPkg. In essence, the functionality in v7 patch= es 8 >>> and 11 - 25 will now live under OvmfPkg instead of UefiCpuPkg. I think >>> this is the better way to do this. Let me know if you have any concern= s. >>>=20 >>> Thanks, >>> Tom >>>=20 >>> On 4/22/20 12:41 PM, Tom Lendacky wrote: >>>> This patch series provides support for running EDK2/OVMF under SEV-ES= . >>>>=20 >>>> 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]. >>>>=20 >>>> In order to allow a hypervisor to perform functions on behalf of a gu= est, >>>> there is architectural support for notifying a guest's operating syst= em >>>> when certain types of VMEXITs are about to occur. This allows the gue= st to >>>> selectively share information with the hypervisor to satisfy the requ= ested >>>> function. The notification is performed using a new exception, the VM= M >>>> Communication exception (#VC). The information is shared through the >>>> Guest-Hypervisor Communication Block (GHCB) using the VMGEXIT instruc= tion. >>>> The GHCB format and the protocol for using it is documented in "SEV-E= S >>>> Guest-Hypervisor Communication Block Standardization" [2]. >>>>=20 >>>> The main areas of the EDK2 code that are updated to support SEV-ES ar= e >>>> around the exception handling support and the AP boot support. >>>>=20 >>>> Exception support is required starting in Sec, continuing through Pei >>>> and into Dxe in order to handle #VC exceptions that are generated. E= ach >>>> AP requires it's own GHCB page as well as a page to hold values speci= fic >>>> to that AP. >>>>=20 >>>> AP booting poses some interesting challenges. The INIT-SIPI-SIPI sequ= ence >>>> is typically used to boot the APs. However, the hypervisor is not all= owed >>>> to update the guest registers. The GHCB document [2] talks about how = SMP >>>> booting under SEV-ES is performed. >>>>=20 >>>> Since the GHCB page must be a shared (unencrypted) page, the processo= r >>>> 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 un= der >>>> the X64 architecture. >>>>=20 >>>> [1] https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F= %2Fwww.amd.com%2Fsystem%2Ffiles%2FTechDocs%2F24593.pdf&data=3D02%7C01%7= Cthomas.lendacky%40amd.com%7Cf5d7875dfcf54e45c42208d7f3e4676b%7C3dd8961fe48= 84e608e11a82d994e183d%7C0%7C0%7C637246036118033165&sdata=3DH74fQl1n2sXz= CMSoGm1tGOKc5epMtVkGJFCidwLMl5c%3D&reserved=3D0 >>>> [2] https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F= %2Fdeveloper.amd.com%2Fwp-content%2Fresources%2F56421.pdf&data=3D02%7C0= 1%7Cthomas.lendacky%40amd.com%7Cf5d7875dfcf54e45c42208d7f3e4676b%7C3dd8961f= e4884e608e11a82d994e183d%7C0%7C0%7C637246036118033165&sdata=3DEwW9575nJ= MaWxizo2XrLHjrbUMJIB0WFTDLjwy%2BM%2F4k%3D&reserved=3D0 >>>>=20 >>>> --- >>>>=20 >>>> These patches are based on commit: >>>> be7295b36405 (".python/SpellCheck: Increase SpellCheck plugin max fai= lures") >>>>=20 >>>> Proper execution of SEV-ES relies on Bugzilla 2340 being fixed. >>>>=20 >>>> A version of the tree (with an extra patch to workaround Bugzilla 234= 0) can >>>> be found at: >>>> https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fg= ithub.com%2FAMDESE%2Fovmf%2Ftree%2Fsev-es-v14&data=3D02%7C01%7Cthomas.l= endacky%40amd.com%7Cf5d7875dfcf54e45c42208d7f3e4676b%7C3dd8961fe4884e608e11= a82d994e183d%7C0%7C0%7C637246036118033165&sdata=3DU8fIzb%2F4A8WBaiVbScx= UuGDw22kyxxnRP5olSyTedvE%3D&reserved=3D0 >>>>=20 >>>> 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: Laszlo Ersek > >>>> Cc: Liming Gao > >>>> Cc: Maurice Ma > >>>> Cc: Michael D Kinney > >>>> Cc: Ray Ni > >>>>=20 >>>> Changes since v6: >>>> - Add function comments to all functions, including local functions >>>> - Add function parameter direction to all functions (in/out) >>>> - Add support for MMIO MOVZX/MOVSX instructions >>>> - Ensure the per-CPU variable page remains encrypted >>>> - Coding-style fixes as identified by Ecc >>>>=20 >>>> Changes since v5: >>>> - Remove extraneous VmgExitLib usage >>>> - Miscellaneous changes to address feedback (coding style, etc.) >>>>=20 >>>> Changes since v4: >>>> - Move the SEV-ES protocol negotiation out of the SEC exception handl= er >>>> and into the SecMain.c file. As a result: >>>> - Move the SecGhcb related PCDs out of UefiCpuPkg and into OvmfPkg >>>> - Combine SecAMDSevVcHandler.c and PeiDxeAMDSevVcHandler.c into a >>>> single AMDSevVcHandler.c >>>> - Consolidate VmgExitLib usage into common LibraryClasses sections >>>> - Add documentation comments to the VmgExitLib functions >>>>=20 >>>> Changes since v3: >>>> - Remove the need for the MP library finalization routine. The AP >>>> jump table address will be held by the hypervisor rather than >>>> communicated via the GHCB MSR. This removes some fragility around >>>> the UEFI to OS transition. >>>> - Rename the SEV-ES RIP reset area to SEV-ES workarea and use it to >>>> communicate the SEV-ES status, so that SEC CPU exception handling = is >>>> only established for an SEV-ES guest. >>>> - Fix SMM build breakageAdd around QemuFlashPtrWrite(). >>>> - Fix SMM build breakage by adding VC exception support the SMM CPU >>>> exception handling. >>>> - Add memory fencing around the invocation of AsmVmgExit(). >>>> - Clarify comments around the SEV-ES AP reset RIP values and usage. >>>> - Move some PCD definitions from MdeModulePkg to UefiCpuPkg. >>>> - Remove the 16-bit code selector definition from MdeModulePkg >>>>=20 >>>> Changes since v2: >>>> - Added a way to locate the SEV-ES fixed AP RIP address for starting >>>> AP's to avoid updating the actual flash image (build time location >>>> that is identified with a GUID value). >>>> - Create a VmgExit library to replace static inline functions. >>>> - Move some PCDs to the appropriate packages >>>> - Add support for writing to QEMU flash under SEV-ES >>>> - Add additional MMIO opcode support >>>> - Cleaned up the GHCB MSR CPUID protocol support >>>>=20 >>>> Changes since v1: >>>> - Patches reworked to be more specific to the component/area being up= dated >>>> and order of definition/usage >>>> - Created a library for VMGEXIT-related functions to replace use of i= nline >>>> functions >>>> - Allocation method for GDT changed from AllocatePool to AllocatePage= s >>>> - Early caching only enabled for SEV-ES guests >>>> - Ensure AP loop mode set to halt loop mode for SEV-ES guests >>>> - Reserved SEC GHCB-related memory areas when S3 is enabled >>>>=20 >>>> Tom Lendacky (43): >>>> MdeModulePkg: Create PCDs to be used in support of SEV-ES >>>> UefiCpuPkg: Create PCD to be used in support of SEV-ES >>>> MdePkg: Add the MSR definition for the GHCB register >>>> MdePkg: Add a structure definition for the GHCB >>>> MdeModulePkg/DxeIplPeim: Support GHCB pages when creating page tab= les >>>> MdePkg/BaseLib: Add support for the XGETBV instruction >>>> MdePkg/BaseLib: Add support for the VMGEXIT instruction >>>> UefiCpuPkg: Implement library support for VMGEXIT >>>> OvmfPkg: Prepare OvmfPkg to use the VmgExitLib library >>>> UefiPayloadPkg: Prepare UefiPayloadPkg to use the VmgExitLib libra= ry >>>> UefiCpuPkg/CpuExceptionHandler: Add base support for the #VC excep= tion >>>> UefiCpuPkg/CpuExceptionHandler: Add support for IOIO_PROT NAE even= ts >>>> UefiCpuPkg/CpuExceptionHandler: Support string IO for IOIO_PROT NA= E >>>> events >>>> UefiCpuPkg/CpuExceptionHandler: Add support for CPUID NAE events >>>> UefiCpuPkg/CpuExceptionHandler: Add support for MSR_PROT NAE event= s >>>> UefiCpuPkg/CpuExceptionHandler: Add support for NPF NAE events (MM= IO) >>>> UefiCpuPkg/CpuExceptionHandler: Add support for WBINVD NAE events >>>> UefiCpuPkg/CpuExceptionHandler: Add support for RDTSC NAE events >>>> UefiCpuPkg/CpuExceptionHandler: Add support for RDPMC NAE events >>>> UefiCpuPkg/CpuExceptionHandler: Add support for INVD NAE events >>>> UefiCpuPkg/CpuExceptionHandler: Add support for VMMCALL NAE events >>>> UefiCpuPkg/CpuExceptionHandler: Add support for RDTSCP NAE events >>>> UefiCpuPkg/CpuExceptionHandler: Add support for MONITOR/MONITORX N= AE >>>> events >>>> UefiCpuPkg/CpuExceptionHandler: Add support for MWAIT/MWAITX NAE >>>> events >>>> UefiCpuPkg/CpuExceptionHandler: Add support for DR7 Read/Write NAE >>>> events >>>> OvmfPkg/MemEncryptSevLib: Add an SEV-ES guest indicator function >>>> OvmfPkg: Add support to perform SEV-ES initialization >>>> OvmfPkg: Create a GHCB page for use during Sec phase >>>> OvmfPkg/PlatformPei: Reserve GHCB-related areas if S3 is supported >>>> OvmfPkg: Create GHCB pages for use during Pei and Dxe phase >>>> OvmfPkg/PlatformPei: Move early GDT into ram when SEV-ES is enable= d >>>> UefiCpuPkg: Create an SEV-ES workarea PCD >>>> OvmfPkg: Reserve a page in memory for the SEV-ES usage >>>> OvmfPkg/ResetVector: Add support for a 32-bit SEV check >>>> OvmfPkg/Sec: Add #VC exception handling for Sec phase >>>> OvmfPkg/Sec: Enable cache early to speed up booting >>>> OvmfPkg/QemuFlashFvbServicesRuntimeDxe: Bypass flash detection wit= h >>>> SEV-ES is enabled >>>> UefiCpuPkg: Add a 16-bit protected mode code segment descriptor >>>> UefiCpuPkg/MpInitLib: Add CPU MP data flag to indicate if SEV-ES i= s >>>> enabled >>>> UefiCpuPkg: Allow AP booting under SEV-ES >>>> OvmfPkg: Use the SEV-ES work area for the SEV-ES AP reset vector >>>> OvmfPkg: Move the GHCB allocations into reserved memory >>>> UefiCpuPkg/MpInitLib: Prepare SEV-ES guest APs for OS use >>>>=20 >>>> MdeModulePkg/MdeModulePkg.dec | 9 + >>>> OvmfPkg/OvmfPkg.dec | 9 + >>>> UefiCpuPkg/UefiCpuPkg.dec | 17 + >>>> OvmfPkg/OvmfPkgIa32.dsc | 6 + >>>> OvmfPkg/OvmfPkgIa32X64.dsc | 6 + >>>> OvmfPkg/OvmfPkgX64.dsc | 6 + >>>> OvmfPkg/OvmfXen.dsc | 1 + >>>> UefiCpuPkg/UefiCpuPkg.dsc | 2 + >>>> UefiPayloadPkg/UefiPayloadPkgIa32.dsc | 2 + >>>> UefiPayloadPkg/UefiPayloadPkgIa32X64.dsc | 2 + >>>> OvmfPkg/OvmfPkgX64.fdf | 9 + >>>> MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf | 2 + >>>> MdePkg/Library/BaseLib/BaseLib.inf | 4 + >>>> OvmfPkg/PlatformPei/PlatformPei.inf | 7 + >>>> .../FvbServicesRuntimeDxe.inf | 2 + >>>> OvmfPkg/ResetVector/ResetVector.inf | 8 + >>>> OvmfPkg/Sec/SecMain.inf | 4 + >>>> .../DxeCpuExceptionHandlerLib.inf | 5 + >>>> .../PeiCpuExceptionHandlerLib.inf | 5 + >>>> .../SecPeiCpuExceptionHandlerLib.inf | 5 + >>>> .../SmmCpuExceptionHandlerLib.inf | 5 + >>>> UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf | 4 + >>>> UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.inf | 4 + >>>> UefiCpuPkg/Library/VmgExitLib/VmgExitLib.inf | 33 + >>>> .../Core/DxeIplPeim/X64/VirtualMemory.h | 12 +- >>>> MdePkg/Include/Library/BaseLib.h | 31 + >>>> MdePkg/Include/Register/Amd/Fam17Msr.h | 42 + >>>> MdePkg/Include/Register/Amd/Ghcb.h | 136 ++ >>>> OvmfPkg/Include/Library/MemEncryptSevLib.h | 12 + >>>> .../QemuFlash.h | 13 + >>>> UefiCpuPkg/CpuDxe/CpuGdt.h | 4 +- >>>> UefiCpuPkg/Include/Library/VmgExitLib.h | 117 ++ >>>> .../CpuExceptionHandlerLib/AMDSevVcCommon.h | 49 + >>>> .../CpuExceptionCommon.h | 2 + >>>> UefiCpuPkg/Library/MpInitLib/MpLib.h | 68 +- >>>> .../Core/DxeIplPeim/Ia32/DxeLoadFunc.c | 4 +- >>>> .../Core/DxeIplPeim/X64/DxeLoadFunc.c | 11 +- >>>> .../Core/DxeIplPeim/X64/VirtualMemory.c | 57 +- >>>> MdePkg/Library/BaseLib/Ia32/GccInline.c | 45 + >>>> MdePkg/Library/BaseLib/X64/GccInline.c | 47 + >>>> .../MemEncryptSevLibInternal.c | 75 +- >>>> OvmfPkg/PlatformPei/AmdSev.c | 89 + >>>> OvmfPkg/PlatformPei/MemDetect.c | 23 + >>>> .../QemuFlash.c | 23 +- >>>> .../QemuFlashDxe.c | 22 + >>>> .../QemuFlashSmm.c | 16 + >>>> OvmfPkg/Sec/SecMain.c | 188 +- >>>> UefiCpuPkg/CpuDxe/CpuGdt.c | 8 +- >>>> .../CpuExceptionHandlerLib/AMDSevVcHandler.c | 40 + >>>> .../CpuExceptionCommon.c | 2 +- >>>> .../Ia32/ArchAMDSevVcHandler.c | 38 + >>>> .../PeiDxeSmmCpuException.c | 16 + >>>> .../SecPeiCpuException.c | 16 + >>>> .../X64/ArchAMDSevVcHandler.c | 1699 ++++++++++++++= +++ >>>> UefiCpuPkg/Library/MpInitLib/DxeMpLib.c | 113 +- >>>> UefiCpuPkg/Library/MpInitLib/MpLib.c | 265 ++- >>>> UefiCpuPkg/Library/MpInitLib/PeiMpLib.c | 19 + >>>> UefiCpuPkg/Library/VmgExitLib/VmgExitLib.c | 293 +++ >>>> UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmFuncsArch.c | 2 +- >>>> MdeModulePkg/MdeModulePkg.uni | 8 + >>>> MdePkg/Library/BaseLib/Ia32/VmgExit.nasm | 37 + >>>> MdePkg/Library/BaseLib/Ia32/XGetBv.nasm | 31 + >>>> MdePkg/Library/BaseLib/X64/VmgExit.nasm | 32 + >>>> MdePkg/Library/BaseLib/X64/XGetBv.nasm | 34 + >>>> OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm | 100 + >>>> OvmfPkg/ResetVector/Ia32/PageTables64.asm | 350 +++- >>>> OvmfPkg/ResetVector/ResetVector.nasmb | 20 + >>>> .../X64/ExceptionHandlerAsm.nasm | 17 + >>>> UefiCpuPkg/Library/MpInitLib/Ia32/MpEqu.inc | 2 +- >>>> .../Library/MpInitLib/Ia32/MpFuncs.nasm | 15 + >>>> UefiCpuPkg/Library/MpInitLib/X64/MpEqu.inc | 4 +- >>>> UefiCpuPkg/Library/MpInitLib/X64/MpFuncs.nasm | 370 +++- >>>> UefiCpuPkg/Library/VmgExitLib/VmgExitLib.uni | 15 + >>>> .../ResetVector/Vtf0/Ia16/Real16ToFlat32.asm | 9 + >>>> UefiCpuPkg/UefiCpuPkg.uni | 11 + >>>> 75 files changed, 4707 insertions(+), 102 deletions(-) >>>> create mode 100644 UefiCpuPkg/Library/VmgExitLib/VmgExitLib.inf >>>> create mode 100644 MdePkg/Include/Register/Amd/Ghcb.h >>>> create mode 100644 UefiCpuPkg/Include/Library/VmgExitLib.h >>>> create mode 100644 UefiCpuPkg/Library/CpuExceptionHandlerLib/AMDSev= VcCommon.h >>>> create mode 100644 UefiCpuPkg/Library/CpuExceptionHandlerLib/AMDSev= VcHandler.c >>>> create mode 100644 UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/A= rchAMDSevVcHandler.c >>>> create mode 100644 UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/Ar= chAMDSevVcHandler.c >>>> create mode 100644 UefiCpuPkg/Library/VmgExitLib/VmgExitLib.c >>>> create mode 100644 MdePkg/Library/BaseLib/Ia32/VmgExit.nasm >>>> create mode 100644 MdePkg/Library/BaseLib/Ia32/XGetBv.nasm >>>> create mode 100644 MdePkg/Library/BaseLib/X64/VmgExit.nasm >>>> create mode 100644 MdePkg/Library/BaseLib/X64/XGetBv.nasm >>>> create mode 100644 OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm >>>> create mode 100644 UefiCpuPkg/Library/VmgExitLib/VmgExitLib.uni >>>>=20 >=20 >=20 --Apple-Mail=_971305DA-2E39-49C9-A081-772758697944 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On May 9,= 2020, at 7:34 AM, Lendacky, Thomas <thomas.lendacky@amd.com> wrote:

On 5/9/20 1:44 AM, Ni, R= ay wrote:
= Tom,

Hi Ray,

I have a bit concern on your change= that directly modifies CpuExceptionHandlerLib to handle
exce= ption #29. Today's CpuExceptionHandlerLib simplify dumps the exception cont= ext for
every exception. Any component which wants to do spec= ific handling of certain exceptions
should call RegisterCpuIn= terruptHandler(). Such as code in CpuDxe driver:
  = if (HEAP_GUARD_NONSTOP_MODE || NULL_DETECTION_NONSTOP_MODE) {
    RegisterCpuInterruptHandler (EXCEPT_IA32_DEBUG, De= bugExceptionHandler);
    RegisterCpuInte= rruptHandler (EXCEPT_IA32_PAGE_FAULT, PageFaultExceptionHandler);
  }
Is it possible for your feature to follo= w the same pattern?

There are two problems:

The first is that= RegisterCpuInterruptHandler() is not implemented for both the SEC and PEI = phases, so it is not currently possible to register a handler that early.

The second is that I need to be able to propagate an excepti= on request from the hypervisor. With the current implementation there doesn= 't appear to be an easy way to perform this propagation.

If= there's a way to accomplish both of the above I wouldn't be opposed to usi= ng RegisterCpuInterruptHandler() as long as there are no #VCs that can occu= r between initializing exception handling and and registering the #VC handl= er.


Thomas,

As you point out it is tricky dealing with = XIP code. You can't have globals that you can write and generally you use a= PEI service to look tings up, the most common thing being using a HOB. But= SEC has no services and I'm not sure you really want to be calling into th= e PEI Core on a random  exception. 

Here are the best options that popped into my head after reading you= r email
1) IDT in RAM
If your code populates the IDT th= e IDTR gives you access to the address of the IDTR via an instruction. The = PI Spec reserves IDT - sizeof (UNITN) for a cached copy of the PEI Services= Table, but otther than that you are good to go. It should be possible to h= ave a global so you can have the table required to implement RegisterCpuInt= erruptHandler(). There might be some usage  of IDT - ( 2* sizeof(UINTN= )), I know I'm guilty, so storing data after the IDT would be a good option= . In general if your code allocates the memory for the IDT then you can tre= at the IDT as part of your private context data structure and that gives yo= u access 

2) IDT in ROM. 
For this it seems like you need a library to link in to the Cpu= ExceptionHandlerLib that allows you to override the handler. If CpuInterrup= tHandlerOverride() returns NULL you do the current behavior if not NULL the= n you call the returned handler. 

= EFI_CPU_INTERRUPT_HANDLER
EFIAPI
OverrideCpuInterruptHa= ndler (
  IN EFI_EXCEPTION_TYPE       &n= bsp;    InterruptType
  );

Thanks,

Andrew Fish
<= br class=3D"">
PS Off topic, but it would also be useful to have = a library that overrides the state dump display. For example using Xcode yo= u can always display a stack frame from the exception handler. 
<= div>

Thanks,
Tom

Thanks,
Ra= y
-----Original Message-= ----
From: Tom Lendacky <thomas.lendacky@amd.com>
Sent: Sa= turday, May 9, 2020 3:16 AM
To: devel@edk2.groups.io
Cc: Justen, Jo= rdan L <jordan.l= .justen@intel.com>; Laszlo Ersek <lersek@redhat.com>; Ard Biesheuvel
&l= t;ard.biesheuvel@li= naro.org>; Kinney, Michael D <michael.d.kinney@intel.com>; Gao, Liming <<= a href=3D"mailto:liming.gao@intel.com" class=3D"">liming.gao@intel.com&= gt;; Dong,
Eric <eric.dong@intel.com>; Ni, Ray <ray.ni@intel.com>; Brijesh Singh <brijesh.singh@amd.com>= ; You, Benjamin
<benjamin.you@intel.com>; Bi, Dandan <dandan.bi@intel.com>; Dong, Guo &l= t;guo.dong@intel.com&g= t;; Wu, Hao A
<hao.a.wu@intel.com>; Wang, Jian J <jian.j.wang@intel.com>; Ma, Maurice <= ;maurice.ma@intel.com>
Subject: Re: [PATCH v7 00/43] SEV-ES guest support

I was able to use the pull request method that Las= zlo documented and fixed
up all of the issues identified by t= he VS compiler.

An additional change I'm plann= ing to make for the next version (v8) of the
patches is to cr= eate a NULL library instance of the VmgExitLib that will
also= include the #VC handler function. This will reduce the amount of code
associated with this feature for platforms that don't use/support= SEV-ES.

Laszlo, this will mean that I will in= troduce a version of the VmgExitLib
under OvmfPkg that will p= rovide the majority of the functionality that is
present toda= y in UefiCpuPkg. In essence, the functionality in v7 patches 8
and 11 - 25 will now live under OvmfPkg instead of UefiCpuPkg. I thinkthis is the better way to do this. Let me know if you have any = concerns.

Thanks,
Tom

On 4/22/20 12:41 PM, Tom Lendacky wrote:
This patch series provides support f= or running EDK2/OVMF under SEV-ES.

Secure Encr= ypted Virtualization - Encrypted State (SEV-ES) expands on the
SEV support to protect the guest register state from the hypervisor. See<= br class=3D"">"AMD64 Architecture Programmer's Manual Volume 2: System Prog= ramming",
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 not= ifying a guest's operating system
when certain types of VMEXI= Ts are about to occur. This allows the guest to
selectively s= hare 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 VM= GEXIT instruction.
The GHCB format and the protocol for using= it is documented in "SEV-ES
Guest-Hypervisor Communication B= lock Standardization" [2].

The main areas of t= he EDK2 code that are updated to support SEV-ES are
around th= e exception handling support and the AP boot support.

Exception support is required starting in Sec, continuing through P= ei
and into Dxe in order to handle #VC exceptions that are ge= nerated.  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-SIP= I sequence
is typically used to boot the APs. However, the hy= pervisor is not allowed
to update the guest registers. The GH= CB document [2] talks about how SMP
booting under SEV-ES is p= erformed.

Since the GHCB page must be a shared= (unencrypted) page, the processor
must be running in long mo= de in order for the guest and hypervisor to
communicate with = each other. As a result, SEV-ES is only supported under
the X= 64 architecture.

[1] https://nam11.safelinks.protection.outlook.com/?= url=3Dhttps%3A%2F%2Fwww.amd.com%2Fsystem%2Ffiles%2FTechDocs%2F24593.pdf&= ;amp;data=3D02%7C01%7Cthomas.lendacky%40amd.com%7Cf5d7875dfcf54e45c42208d7f= 3e4676b%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637246036118033165&= ;amp;sdata=3DH74fQl1n2sXzCMSoGm1tGOKc5epMtVkGJFCidwLMl5c%3D&amp;reserve= d=3D0
[2] https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3= A%2F%2Fdeveloper.amd.com%2Fwp-content%2Fresources%2F56421.pdf&amp;data= =3D02%7C01%7Cthomas.lendacky%40amd.com%7Cf5d7875dfcf54e45c42208d7f3e4676b%= 7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637246036118033165&amp;sda= ta=3DEwW9575nJMaWxizo2XrLHjrbUMJIB0WFTDLjwy%2BM%2F4k%3D&amp;reserved=3D= 0

---

These p= atches are based on commit:
be7295b36405 (".python/SpellCheck= : Increase SpellCheck plugin max failures")

Pr= oper execution of SEV-ES relies on Bugzilla 2340 being fixed.

A version of the tree (with an extra patch to workaround Bu= gzilla 2340) can
be found at:
https://nam11.safe= links.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithub.com%2FAMDESE%2Fovm= f%2Ftree%2Fsev-es-v14&amp;data=3D02%7C01%7Cthomas.lendacky%40amd.com%7C= f5d7875dfcf54e45c42208d7f3e4676b%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0= %7C637246036118033165&amp;sdata=3DU8fIzb%2F4A8WBaiVbScxUuGDw22kyxxnRP5o= lSyTedvE%3D&amp;reserved=3D0

Cc: Ard B= iesheuvel <ard.b= iesheuvel@linaro.org>
Cc: Benjamin You <benjamin.you@intel.com>Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Guo Dong <guo.dong@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
= Cc: Jian J Wang <jia= n.j.wang@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com&g= t;
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Liming Gao <liming.gao@intel.com><= br class=3D"">Cc: Maurice Ma <maurice.ma@intel.com>
Cc: Michael D Kinney &l= t;michael.d.kinney= @intel.com>
Cc: Ray Ni <ray.ni@intel.com>

C= hanges since v6:
- Add function comments to all functions, in= cluding local functions
- Add function parameter direction to= all functions (in/out)
- Add support for MMIO MOVZX/MOVSX in= structions
- Ensure the per-CPU variable page remains encrypt= ed
- Coding-style fixes as identified by Ecc
Changes since v5:
- Remove extraneous VmgExitLib= usage
- Miscellaneous changes to address feedback (coding st= yle, etc.)

Changes since v4:
- M= ove the SEV-ES protocol negotiation out of the SEC exception handler
   and into the SecMain.c file. As a result:
   - Move the SecGhcb related PCDs out of UefiCpuPkg = and into OvmfPkg
   - Combine SecAMDSevVcHandl= er.c and PeiDxeAMDSevVcHandler.c into a
   &nb= sp; single AMDSevVcHandler.c
- Consolidate VmgExitLib us= age into common LibraryClasses sections
- Add documentation c= omments to the VmgExitLib functions

Changes si= nce v3:
- Remove the need for the MP library finalization rou= tine. The AP
   jump table address will be hel= d by the hypervisor rather than
   communicate= d via the GHCB MSR. This removes some fragility around
 =   the UEFI to OS transition.
- Rename the SEV-ES RI= P reset area to SEV-ES workarea and use it to
  &nb= sp;communicate the SEV-ES status, so that SEC CPU exception handling is
   only established for an SEV-ES guest.
- Fix SMM build breakageAdd around QemuFlashPtrWrite().
- Fix SMM build breakage by adding VC exception support the SMM CPU
   exception handling.
- Add memory f= encing around the invocation of AsmVmgExit().
- Clarify comme= nts around the SEV-ES AP reset RIP values and usage.
- Move s= ome PCD definitions from MdeModulePkg to UefiCpuPkg.
- Remove= the 16-bit code selector definition from MdeModulePkg

Changes since v2:
- Added a way to locate the SEV-ES= fixed AP RIP address for starting
   AP's to = avoid updating the actual flash image (build time location
&n= bsp;  that is identified with a GUID value).
- Crea= te a VmgExit library to replace static inline functions.
- Mo= ve some PCDs to the appropriate packages
- Add support for wr= iting to QEMU flash under SEV-ES
- Add additional MMIO opcode= support
- Cleaned up the GHCB MSR CPUID protocol support

Changes since v1:
- Patches reworke= d to be more specific to the component/area being updated
&nb= sp;  and order of definition/usage
- Created a libr= ary for VMGEXIT-related functions to replace use of inline
&n= bsp;  functions
- Allocation method for GDT changed= from AllocatePool to AllocatePages
- Early caching only enab= led for SEV-ES guests
- Ensure AP loop mode set to halt loop = mode for SEV-ES guests
- Reserved SEC GHCB-related memory are= as when S3 is enabled

Tom Lendacky (43):
   MdeModulePkg: Create PCDs to be used in support = of SEV-ES
   UefiCpuPkg: Create PCD to be used= in support of SEV-ES
   MdePkg: Add the MSR d= efinition for the GHCB register
   MdePkg: Add= a structure definition for the GHCB
   MdeMod= ulePkg/DxeIplPeim: Support GHCB pages when creating page tables
   MdePkg/BaseLib: Add support for the XGETBV instruction=
   MdePkg/BaseLib: Add support for the VMGEXI= T instruction
   UefiCpuPkg: Implement library= support for VMGEXIT
   OvmfPkg: Prepare OvmfP= kg to use the VmgExitLib library
   UefiPayloa= dPkg: Prepare UefiPayloadPkg to use the VmgExitLib library
&n= bsp;  UefiCpuPkg/CpuExceptionHandler: Add base support for the #V= C exception
   UefiCpuPkg/CpuExceptionHandler:= Add support for IOIO_PROT NAE events
   UefiC= puPkg/CpuExceptionHandler: Support string IO for IOIO_PROT NAE
     events
   Uefi= CpuPkg/CpuExceptionHandler: Add support for CPUID NAE events
=    UefiCpuPkg/CpuExceptionHandler: Add support for MSR_PROT = NAE events
   UefiCpuPkg/CpuExceptionHandler: = Add support for NPF NAE events (MMIO)
   UefiC= puPkg/CpuExceptionHandler: Add support for WBINVD NAE events
=    UefiCpuPkg/CpuExceptionHandler: Add support for RDTSC NAE= events
   UefiCpuPkg/CpuExceptionHandler: Add= support for RDPMC NAE events
   UefiCpuPkg/Cp= uExceptionHandler: Add support for INVD NAE events
 &nbs= p; UefiCpuPkg/CpuExceptionHandler: Add support for VMMCALL NAE events<= br class=3D"">   UefiCpuPkg/CpuExceptionHandler: Add support= for RDTSCP NAE events
   UefiCpuPkg/CpuExcept= ionHandler: Add support for MONITOR/MONITORX NAE
  =    events
   UefiCpuPkg/CpuExce= ptionHandler: Add support for MWAIT/MWAITX NAE
  &n= bsp;  events
   UefiCpuPkg/CpuExcept= ionHandler: Add support for DR7 Read/Write NAE
  &n= bsp;  events
   OvmfPkg/MemEncryptSe= vLib: Add an SEV-ES guest indicator function
  &nbs= p;OvmfPkg: Add support to perform SEV-ES initialization
 = ;  OvmfPkg: Create a GHCB page for use during Sec phase
   OvmfPkg/PlatformPei: Reserve GHCB-related areas if= S3 is supported
   OvmfPkg: Create GHCB pages= for use during Pei and Dxe phase
   OvmfPkg/P= latformPei: Move early GDT into ram when SEV-ES is enabled
&n= bsp;  UefiCpuPkg: Create an SEV-ES workarea PCD
&nb= sp;  OvmfPkg: Reserve a page in memory for the SEV-ES usage
   OvmfPkg/ResetVector: Add support for a 32-bit SE= V check
   OvmfPkg/Sec: Add #VC exception hand= ling for Sec phase
   OvmfPkg/Sec: Enable cach= e early to speed up booting
   OvmfPkg/QemuFla= shFvbServicesRuntimeDxe: Bypass flash detection with
 &n= bsp;   SEV-ES is enabled
   Uef= iCpuPkg: Add a 16-bit protected mode code segment descriptor
=    UefiCpuPkg/MpInitLib: Add CPU MP data flag to indicate if= SEV-ES is
     enabled
   UefiCpuPkg: Allow AP booting under SEV-ES
   OvmfPkg: Use the SEV-ES work area for the SEV-ES AP rese= t vector
   OvmfPkg: Move the GHCB allocations= into reserved memory
   UefiCpuPkg/MpInitLib:= Prepare SEV-ES guest APs for OS use

 &nb= sp;MdeModulePkg/MdeModulePkg.dec        =          |    9= +
  OvmfPkg/OvmfPkg.dec     &n= bsp;            = ;         |    = 9 +
  UefiCpuPkg/UefiCpuPkg.dec    &= nbsp;           &nbs= p;    |   17 +
  Ovmf= Pkg/OvmfPkgIa32.dsc          &= nbsp;           &nbs= p;|    6 +
  OvmfPkg/OvmfPkgIa32X64.= dsc             = ;       |    6 +
  OvmfPkg/OvmfPkgX64.dsc      &nb= sp;            =      |    6 +
 &= nbsp;OvmfPkg/OvmfXen.dsc         &n= bsp;            = ;     |    1 +
 =  UefiCpuPkg/UefiCpuPkg.dsc        &= nbsp;           &nbs= p;|    2 +
  UefiPayloadPkg/UefiPayl= oadPkgIa32.dsc         |  &nbs= p; 2 +
  UefiPayloadPkg/UefiPayloadPkgIa32X64.= dsc      |    2 +
&nb= sp; OvmfPkg/OvmfPkgX64.fdf        &= nbsp;           &nbs= p;   |    9 +
  MdeMo= dulePkg/Core/DxeIplPeim/DxeIpl.inf       | &n= bsp;  2 +
  MdePkg/Library/BaseLib/BaseLi= b.inf            | &= nbsp;  4 +
  OvmfPkg/PlatformPei/Platform= Pei.inf           |  = ;  7 +
  .../FvbServicesRuntimeDxe.inf &n= bsp;            = ;   |    2 +
  OvmfPk= g/ResetVector/ResetVector.inf        &nb= sp;  |    8 +
  OvmfPkg/Se= c/SecMain.inf           &= nbsp;           | &n= bsp;  4 +
  .../DxeCpuExceptionHandlerLib= .inf            &nbs= p;|    5 +
  .../PeiCpuExceptionHand= lerLib.inf           &nbs= p; |    5 +
  .../SecPeiCpuExce= ptionHandlerLib.inf          |=    5 +
  .../SmmCpuExceptionHandler= Lib.inf            &= nbsp;|    5 +
  UefiCpuPkg/Library/M= pInitLib/DxeMpInitLib.inf |    4 +
  = ;UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.inf |    4 +
  UefiCpuPkg/Library/VmgExitLib/VmgExitLib.inf  | =   33 +
  .../Core/DxeIplPeim/X64/VirtualM= emory.h       |   12 +-
  MdePkg/Include/Library/BaseLib.h     &nb= sp;        |   31 +
  MdePkg/Include/Register/Amd/Fam17Msr.h   &nb= sp;    |   42 +
  Mde= Pkg/Include/Register/Amd/Ghcb.h        &= nbsp;   |  136 ++
  OvmfPkg/Inc= lude/Library/MemEncryptSevLib.h    |   12 +
  .../QemuFlash.h       &nb= sp;            =            |  &= nbsp;13 +
  UefiCpuPkg/CpuDxe/CpuGdt.h   =             &nb= sp;    |    4 +-
 &nb= sp;UefiCpuPkg/Include/Library/VmgExitLib.h      &n= bsp;|  117 ++
  .../CpuExceptionHandlerLib/AMD= SevVcCommon.h   |   49 +
  .../= CpuExceptionCommon.h          =             | &= nbsp;  2 +
  UefiCpuPkg/Library/MpInitLib= /MpLib.h          |  &nbs= p;68 +-
  .../Core/DxeIplPeim/Ia32/DxeLoadFunc.c &n= bsp;      |    4 +-
  .../Core/DxeIplPeim/X64/DxeLoadFunc.c    =      |   11 +-
  = ;.../Core/DxeIplPeim/X64/VirtualMemory.c      &nbs= p;|   57 +-
  MdePkg/Library/BaseLib/Ia32= /GccInline.c       |   45 +
  MdePkg/Library/BaseLib/X64/GccInline.c    = ;    |   47 +
  .../M= emEncryptSevLibInternal.c         &= nbsp;      |   75 +-
=   OvmfPkg/PlatformPei/AmdSev.c      &nbs= p;           |  = ; 89 +
  OvmfPkg/PlatformPei/MemDetect.c  = ;            &n= bsp;|   23 +
  .../QemuFlash.c  &nbs= p;            &= nbsp;           &nbs= p;   |   23 +-
  .../QemuF= lashDxe.c            = ;            &n= bsp;   |   22 +
  .../Qemu= FlashSmm.c           &nbs= p;            &= nbsp;   |   16 +
  OvmfPkg= /Sec/SecMain.c           =             &nb= sp; |  188 +-
  UefiCpuPkg/CpuDxe/CpuGdt.= c             &= nbsp;      |    8 +-
  .../CpuExceptionHandlerLib/AMDSevVcHandler.c  | &nb= sp; 40 +
  .../CpuExceptionCommon.c  &nbs= p;            &= nbsp;      |    2 +-
  .../Ia32/ArchAMDSevVcHandler.c     &= nbsp;          |  &n= bsp;38 +
  .../PeiDxeSmmCpuException.c   =             &nb= sp;   |   16 +
  .../SecPe= iCpuException.c           = ;           |  =  16 +
  .../X64/ArchAMDSevVcHandler.c  &n= bsp;            = ;  | 1699 +++++++++++++++++
  UefiCpuPkg/= Library/MpInitLib/DxeMpLib.c       |  11= 3 +-
  UefiCpuPkg/Library/MpInitLib/MpLib.c  &= nbsp;       |  265 ++-
  UefiCpuPkg/Library/MpInitLib/PeiMpLib.c    &nb= sp;  |   19 +
  UefiCpuPkg/Libr= ary/VmgExitLib/VmgExitLib.c    |  293 +++
  UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmFuncsArch.c  |  &nb= sp; 2 +-
  MdeModulePkg/MdeModulePkg.uni  = ;            &n= bsp;  |    8 +
  MdePkg/Li= brary/BaseLib/Ia32/VmgExit.nasm      |   = ;37 +
  MdePkg/Library/BaseLib/Ia32/XGetBv.nasm &nb= sp;     |   31 +
 &nb= sp;MdePkg/Library/BaseLib/X64/VmgExit.nasm      &n= bsp;|   32 +
  MdePkg/Library/BaseLib/X64= /XGetBv.nasm        |   34 +  OvmfPkg/ResetVector/Ia16/ResetVectorVtf0.asm  = ;|  100 +
  OvmfPkg/ResetVector/Ia32/PageTable= s64.asm     |  350 +++-
  = OvmfPkg/ResetVector/ResetVector.nasmb       &= nbsp; |   20 +
  .../X64/ExceptionHa= ndlerAsm.nasm           &= nbsp;  |   17 +
  UefiCpuPkg/Li= brary/MpInitLib/Ia32/MpEqu.inc   |    2 +-
  .../Library/MpInitLib/Ia32/MpFuncs.nasm   &nbs= p;   |   15 +
  UefiCpuPkg= /Library/MpInitLib/X64/MpEqu.inc    |    4 +-=
  UefiCpuPkg/Library/MpInitLib/X64/MpFuncs.nasm | =  370 +++-
  UefiCpuPkg/Library/VmgExitLib/VmgE= xitLib.uni  |   15 +
  .../ResetVect= or/Vtf0/Ia16/Real16ToFlat32.asm  |    9 +
  UefiCpuPkg/UefiCpuPkg.uni       =             &nb= sp; |   11 +
  75 files changed, 470= 7 insertions(+), 102 deletions(-)
  create mode 100= 644 UefiCpuPkg/Library/VmgExitLib/VmgExitLib.inf
  = create mode 100644 MdePkg/Include/Register/Amd/Ghcb.h
 &= nbsp;create mode 100644 UefiCpuPkg/Include/Library/VmgExitLib.h
  create mode 100644 UefiCpuPkg/Library/CpuExceptionHandlerLib= /AMDSevVcCommon.h
  create mode 100644 UefiCpuPkg/L= ibrary/CpuExceptionHandlerLib/AMDSevVcHandler.c
  c= reate mode 100644 UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ArchAMDSev= VcHandler.c
  create mode 100644 UefiCpuPkg/Library= /CpuExceptionHandlerLib/X64/ArchAMDSevVcHandler.c
  = ;create mode 100644 UefiCpuPkg/Library/VmgExitLib/VmgExitLib.c
  create mode 100644 MdePkg/Library/BaseLib/Ia32/VmgExit.nasm  create mode 100644 MdePkg/Library/BaseLib/Ia32/XGe= tBv.nasm
  create mode 100644 MdePkg/Library/BaseLi= b/X64/VmgExit.nasm
  create mode 100644 MdePkg/Libr= ary/BaseLib/X64/XGetBv.nasm
  create mode 100644 Ov= mfPkg/ResetVector/Ia16/ResetVectorVtf0.asm
  create= mode 100644 UefiCpuPkg/Library/VmgExitLib/VmgExitLib.uni


--Apple-Mail=_971305DA-2E39-49C9-A081-772758697944--