summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* MdePkg: Remove PPTT ID type structureChris Jones2021-12-101-16/+0
| | | | | | | | | | | | | Bugzilla: 3697 (https://bugzilla.tianocore.org/show_bug.cgi?id=3697) The ACPI 6.3A specification deprecated the PPTT ID type structure (type 2) therefore remove it from Acpi64.h. Mantis ID: 2072 (https://mantis.uefi.org/mantis/view.php?id=2072) Signed-off-by: Chris Jones <christopher.jones@arm.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
* MdePkg: Add missing Cache ID (in)valid defineChris Jones2021-12-101-0/+2
| | | | | | | | | | | | | Bugzilla: 3697 (https://bugzilla.tianocore.org/show_bug.cgi?id=3697) Add Cache ID valid/invalid defines to Acpi64.h which were not initially added when the CacheIdValid field was added to EFI_ACPI_6_4_PPTT_STRUCTURE_CACHE_FLAGS. Signed-off-by: Chris Jones <christopher.jones@arm.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Zhichao Gao <zhichao.gao@intel.com> Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
* OvmfPkg: Remove unused print service driver (PrintDxe)Philippe Mathieu-Daude2021-12-1014-14/+0
| | | | | | | | | | | | | | | | | | | | | | | | PrintDxe produces gEfiPrint2ProtocolGuid and gEfiPrint2SProtocolGuid, and those are consumed by the following PrintLib instance: MdeModulePkg/Library/DxePrintLibPrint2Protocol/DxePrintLibPrint2Protocol.inf However, none of the OVMF DSC files contain such a PrintLib class resolution, so none of the OVMF platforms need PrintDxe. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Suggested-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3744 Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com>
* UefiCpuPkg/MpInitLib: Use SEV-SNP AP Creation NAE event to launch APsTom Lendacky2021-12-097-22/+433
| | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 Use the SEV-SNP AP Creation NAE event to create and launch APs under SEV-SNP. This capability will be advertised in the SEV Hypervisor Feature Support PCD (PcdSevEsHypervisorFeatures). Cc: Michael Roth <michael.roth@amd.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Ray Ni <ray.ni@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
* OvmfPkg/AmdSev: expose the SNP reserved pages through configuration tableBrijesh Singh2021-12-094-0/+64
| | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 Now that both the secrets and cpuid pages are reserved in the HOB, extract the location details through fixed PCD and make it available to the guest OS through the configuration table. Cc: Michael Roth <michael.roth@amd.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
* OvmfPkg/PlatformPei: mark cpuid and secrets memory reserved in EFI mapBrijesh Singh via groups.io2021-12-094-0/+42
| | | | | | | | | | | | | | | | | | | When SEV-SNP is active, the CPUID and Secrets memory range contains the information that is used during the VM boot. The content need to be persist across the kexec boot. Mark the memory range as Reserved in the EFI map so that guest OS or firmware does not use the range as a system RAM. Cc: Michael Roth <michael.roth@amd.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
* OvmfPkg/MemEncryptSevLib: skip page state change for Mmio addressBrijesh Singh2021-12-091-7/+13
| | | | | | | | | | | | | | | | | | | | | | | | | The SetMemoryEncDec() is used by the higher level routines to set or clear the page encryption mask for system RAM and Mmio address. When SEV-SNP is active, in addition to set/clear page mask it also updates the RMP table. The RMP table updates are required for the system RAM address and not the Mmio address. Add a new parameter in SetMemoryEncDec() to tell whether the specified address is Mmio. If its Mmio then skip the page state change in the RMP table. Cc: Michael Roth <michael.roth@amd.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
* OvmfPkg/MemEncryptSevLib: change the page state in the RMP tableBrijesh Singh via groups.io2021-12-091-0/+34
| | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 The MemEncryptSev{Set,Clear}PageEncMask() functions are used to set or clear the memory encryption attribute in the page table. When SEV-SNP is active, we also need to change the page state in the RMP table so that it is in sync with the memory encryption attribute change. Cc: Michael Roth <michael.roth@amd.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
* UefiCpuPkg/MpInitLib: use BSP to do extended topology checkMichael Roth2021-12-095-0/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During AP bringup, just after switching to long mode, APs will do some cpuid calls to verify that the extended topology leaf (0xB) is available so they can fetch their x2 APIC IDs from it. In the case of SEV-ES, these cpuid instructions must be handled by direct use of the GHCB MSR protocol to fetch the values from the hypervisor, since a #VC handler is not yet available due to the AP's stack not being set up yet. For SEV-SNP, rather than relying on the GHCB MSR protocol, it is expected that these values would be obtained from the SEV-SNP CPUID table instead. The actual x2 APIC ID (and 8-bit APIC IDs) would still be fetched from hypervisor using the GHCB MSR protocol however, so introducing support for the SEV-SNP CPUID table in that part of the AP bring-up code would only be to handle the checks/validation of the extended topology leaf. Rather than introducing all the added complexity needed to handle these checks via the CPUID table, instead let the BSP do the check in advance, since it can make use of the #VC handler to avoid the need to scan the SNP CPUID table directly, and add a flag in ExchangeInfo to communicate the result of this check to APs. Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Ray Ni <ray.ni@intel.com> Suggested-by: Brijesh Singh <brijesh.singh@amd.com> Signed-off-by: Michael Roth <michael.roth@amd.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
* UefiCpuPkg/MpLib: add support to register GHCB GPA when SEV-SNP is enabledBrijesh Singh2021-12-094-5/+64
| | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 An SEV-SNP guest requires that the physical address of the GHCB must be registered with the hypervisor before using it. See the GHCB specification section 2.3.2 for more details. Cc: Michael Roth <michael.roth@amd.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Ray Ni <ray.ni@Intel.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
* MdePkg/GHCB: increase the GHCB protocol max versionBrijesh Singh2021-12-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 Now that OvmfPkg supports version 2 of the GHCB specification, bump the protocol version. Cc: Michael Roth <michael.roth@amd.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Ray Ni <ray.ni@intel.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
* OvmfPkg/PlatformPei: set the Hypervisor Features PCDBrijesh Singh2021-12-092-0/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 Version 2 of the GHCB specification added the support to query the hypervisor feature bitmap. The feature bitmap provide information such as whether to use the AP create VmgExit or use the AP jump table approach to create the APs. The MpInitLib will use the PcdGhcbHypervisorFeatures to determine which method to use for creating the AP. Query the hypervisor feature and set the PCD accordingly. Cc: Michael Roth <michael.roth@amd.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
* UefiCpuPkg: add PcdGhcbHypervisorFeaturesBrijesh Singh via groups.io2021-12-091-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 Version 2 of the GHCB specification added a new VMGEXIT that the guest could use for querying the hypervisor features. One of the immediate users for it will be an AP creation code. When SEV-SNP is enabled, the guest can use the newly added AP_CREATE VMGEXIT to create the APs. The MpInitLib will check the hypervisor feature, and if AP_CREATE is available, it will use it. See GHCB spec version 2 for more details on the VMGEXIT. Cc: Michael Roth <michael.roth@amd.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Ray Ni <ray.ni@Intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
* UefiCpuPkg/MpInitLib: use PcdConfidentialComputingAttr to check SEV statusBrijesh Singh2021-12-096-10/+90
| | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 Previous commit introduced a generic confidential computing PCD that can determine whether AMD SEV-ES is enabled. Update the MpInitLib to drop the PcdSevEsIsEnabled in favor of PcdConfidentialComputingAttr. Cc: Michael Roth <michael.roth@amd.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Ray Ni <ray.ni@intel.com> Suggested-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
* OvmfPkg/PlatformPei: set PcdConfidentialComputingAttr when SEV is activeBrijesh Singh2021-12-096-0/+28
| | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 The MpInitLib uses the ConfidentialComputingAttr PCD to determine whether AMD SEV is active so that it can use the VMGEXITs defined in the GHCB specification to create APs. Cc: Michael Roth <michael.roth@amd.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Suggested-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
* MdePkg: Define ConfidentialComputingGuestAttrBrijesh Singh via groups.io2021-12-092-0/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 While initializing APs, the MpInitLib may need to know whether the guest is running with active AMD SEV or Intel TDX memory encryption. Add a new ConfidentialComputingGuestAttr PCD that can be used to query the memory encryption attribute. Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Zhiguang Liu <zhiguang.liu@intel.com> Cc: Michael Roth <michael.roth@amd.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Ray Ni <ray.ni@intel.com> Suggested-by: Jiewen Yao <jiewen.yao@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
* OvmfPkg/PlatformPei: validate the system RAM when SNP is activeBrijesh Singh via groups.io2021-12-091-0/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 When SEV-SNP is active, a memory region mapped encrypted in the page table must be validated before access. There are two approaches that can be taken to validate the system RAM detected during the PEI phase: 1) Validate on-demand OR 2) Validate before access On-demand ========= If memory is not validated before access, it will cause a #VC exception with the page-not-validated error code. The VC exception handler can perform the validation steps. The pages that have been validated will need to be tracked to avoid the double validation scenarios. The range of memory that has not been validated will need to be communicated to the OS through the recently introduced unaccepted memory type https://github.com/microsoft/mu_basecore/pull/66, so that OS can validate those ranges before using them. Validate before access ====================== Since the PEI phase detects all the available system RAM, use the MemEncryptSevSnpValidateSystemRam() function to pre-validate the system RAM in the PEI phase. For now, choose option 2 due to the dependency and the complexity of the on-demand validation. Cc: Michael Roth <michael.roth@amd.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
* OvmfPkg/SecMain: validate the memory used for decompressing FvBrijesh Singh2021-12-098-1/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 The VMM launch sequence should have pre-validated all the data pages used in the Reset vector. The range does not cover the data pages used during the SEC phase (mainly PEI and DXE firmware volume decompression memory). When SEV-SNP is active, the memory must be pre-validated before the access. Add support to pre-validate the memory range from SnpSecPreValidatedStart to SnpSecPreValidatedEnd. This should be sufficent to enter into the PEI phase. Cc: Michael Roth <michael.roth@amd.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
* OvmfPkg/MemEncryptSevLib: add support to validate > 4GB memory in PEI phaseBrijesh Singh via groups.io2021-12-093-0/+160
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 The initial page built during the SEC phase is used by the MemEncryptSevSnpValidateSystemRam() for the system RAM validation. The page validation process requires using the PVALIDATE instruction; the instruction accepts a virtual address of the memory region that needs to be validated. If hardware encounters a page table walk failure (due to page-not-present) then it raises #GP. The initial page table built in SEC phase address up to 4GB. Add an internal function to extend the page table to cover > 4GB. The function builds 1GB entries in the page table for access > 4GB. This will provide the support to call PVALIDATE instruction for the virtual address > 4GB in PEI phase. Cc: Michael Roth <michael.roth@amd.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
* OvmfPkg/BaseMemEncryptSevLib: skip the pre-validated system RAMBrijesh Singh2021-12-092-1/+68
| | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 The MemEncryptSevSnpPreValidateSystemRam() is used for pre-validating the system RAM. As the boot progress, each phase validates a fixed region of the RAM. In the PEI phase, the PlatformPei detects all the available RAM and calls to pre-validate the detected system RAM. While validating the system RAM in PEI phase, we must skip previously validated system RAM to avoid the double validation. Cc: Michael Roth <michael.roth@amd.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
* OvmfPkg/MemEncryptSevLib: add function to check the VMPL0Brijesh Singh via groups.io2021-12-093-1/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 Virtual Machine Privilege Level (VMPL) feature in the SEV-SNP architecture allows a guest VM to divide its address space into four levels. The level can be used to provide the hardware isolated abstraction layers with a VM. The VMPL0 is the highest privilege, and VMPL3 is the least privilege. Certain operations must be done by the VMPL0 software, such as: * Validate or invalidate memory range (PVALIDATE instruction) * Allocate VMSA page (RMPADJUST instruction when VMSA=1) The initial SEV-SNP support assumes that the guest is running on VMPL0. Let's add function in the MemEncryptSevLib that can be used for checking whether guest is booted under the VMPL0. Cc: Michael Roth <michael.roth@amd.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
* OvmfPkg/MemEncryptSevLib: add support to validate system RAMBrijesh Singh via groups.io2021-12-0912-0/+485
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 Many of the integrity guarantees of SEV-SNP are enforced through the Reverse Map Table (RMP). Each RMP entry contains the GPA at which a particular page of DRAM should be mapped. The guest can request the hypervisor to add pages in the RMP table via the Page State Change VMGEXIT defined in the GHCB specification section 2.5.1 and 4.1.6. Inside each RMP entry is a Validated flag; this flag is automatically cleared to 0 by the CPU hardware when a new RMP entry is created for a guest. Each VM page can be either validated or invalidated, as indicated by the Validated flag in the RMP entry. Memory access to a private page that is not validated generates a #VC. A VM can use the PVALIDATE instruction to validate the private page before using it. During the guest creation, the boot ROM memory is pre-validated by the AMD-SEV firmware. The MemEncryptSevSnpValidateSystemRam() can be called during the SEC and PEI phase to validate the detected system RAM. One of the fields in the Page State Change NAE is the RMP page size. The page size input parameter indicates that either a 4KB or 2MB page should be used while adding the RMP entry. During the validation, when possible, the MemEncryptSevSnpValidateSystemRam() will use the 2MB entry. A hypervisor backing the memory may choose to use the different page size in the RMP entry. In those cases, the PVALIDATE instruction should return SIZEMISMATCH. If a SIZEMISMATCH is detected, then validate all 512-pages constituting a 2MB region. Upon completion, the PVALIDATE instruction sets the rFLAGS.CF to 0 if instruction changed the RMP entry and to 1 if the instruction did not change the RMP entry. The rFlags.CF will be 1 only when a memory region is already validated. We should not double validate a memory as it could lead to a security compromise. If double validation is detected, terminate the boot. Cc: Michael Roth <michael.roth@amd.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
* OvmfPkg/AmdSevDxe: do not use extended PCI config spaceBrijesh Singh via groups.io2021-12-095-5/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 Commit 85b8eac59b8c5bd9c7eb9afdb64357ce1aa2e803 added support to ensure that MMIO is only performed against the un-encrypted memory. If MMIO is performed against encrypted memory, a #GP is raised. The AmdSevDxe uses the functions provided by the MemEncryptSevLib to clear the memory encryption mask from the page table. If the MemEncryptSevLib is extended to include VmgExitLib then depedency chain will look like this: OvmfPkg/AmdSevDxe/AmdSevDxe.inf -----> MemEncryptSevLib class -----> "OvmfPkg/BaseMemEncryptSevLib/DxeMemEncryptSevLib.inf" instance -----> VmgExitLib class -----> "OvmfPkg/VmgExitLib" instance -----> LocalApicLib class -----> "UefiCpuPkg/BaseXApicX2ApicLib/BaseXApicX2ApicLib.inf" instance -----> TimerLib class -----> "OvmfPkg/AcpiTimerLib/DxeAcpiTimerLib.inf" instance -----> PciLib class -----> "OvmfPkg/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf" instance -----> PciExpressLib class -----> "MdePkg/BasePciExpressLib/BasePciExpressLib.inf" instance The LocalApicLib provides a constructor that gets called before the AmdSevDxe can clear the memory encryption mask from the MMIO regions. When running under the Q35 machine type, the call chain looks like this: AcpiTimerLibConstructor () [AcpiTimerLib] PciRead32 () [DxePciLibI440FxQ35] PciExpressRead32 () [PciExpressLib] The PciExpressRead32 () reads the MMIO region. The MMIO regions are not yet mapped un-encrypted, so the check introduced in the commit 85b8eac59b8c5bd9c7eb9afdb64357ce1aa2e803 raises a #GP. The AmdSevDxe driver does not require the access to the extended PCI config space. Accessing a normal PCI config space, via IO port should be sufficent. Use the module-scope override to make the AmdSevDxe use the BasePciLib instead of BasePciExpressLib so that PciRead32 () uses the IO ports instead of the extended config space. Cc: Michael Roth <michael.roth@amd.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Suggested-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
* OvmfPkg/PlatformPei: register GHCB gpa for the SEV-SNP guestBrijesh Singh2021-12-091-0/+88
| | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 The SEV-SNP guest requires that GHCB GPA must be registered before using. See the GHCB specification section 2.3.2 for more details. Cc: Michael Roth <michael.roth@amd.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
* OvmfPkg/VmgExitLib: use SEV-SNP-validated CPUID valuesMichael Roth2021-12-093-23/+481
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | SEV-SNP firmware allows a special guest page to be populated with guest CPUID values so that they can be validated against supported host features before being loaded into encrypted guest memory to be used instead of hypervisor-provided values [1]. Add handling for this in the CPUID #VC handler and use it whenever SEV-SNP is enabled. To do so, existing CPUID handling via VmgExit is moved to a helper, GetCpuidHyp(), and a new helper that uses the CPUID page to do the lookup, GetCpuidFw(), is used instead when SNP is enabled. For cases where SNP CPUID lookups still rely on fetching specific CPUID fields from hypervisor, GetCpuidHyp() is used there as well. [1]: SEV SNP Firmware ABI Specification, Rev. 0.8, 8.13.2.6 Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Michael Roth <michael.roth@amd.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
* OvmfPkg/SecMain: register GHCB gpa for the SEV-SNP guestBrijesh Singh via groups.io2021-12-091-0/+119
| | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 The SEV-SNP guest requires that GHCB GPA must be registered before using. See the GHCB specification section 2.3.2 for more details. Cc: Michael Roth <michael.roth@amd.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
* OvmfPkg/MemEncryptSevLib: add MemEncryptSevSnpEnabled()Brijesh Singh2021-12-094-0/+85
| | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 Create a function that can be used to determine if VM is running as an SEV-SNP guest. Cc: Michael Roth <michael.roth@amd.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
* OvmfPkg/ResetVector: use SEV-SNP-validated CPUID valuesMichael Roth2021-12-091-5/+75
| | | | | | | | | | | | | | | | | | | | | | | | CPUID instructions are issued during early boot to do things like probe for SEV support. Currently these are handled by a minimal #VC handler that uses the MSR-based GHCB protocol to fetch the CPUID values from the hypervisor. When SEV-SNP is enabled, use the firmware-validated CPUID values from the CPUID page instead [1]. [1]: SEV SNP Firmware ABI Specification, Rev. 0.8, 8.13.2.6 Cc: Michael Roth <michael.roth@amd.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Michael Roth <michael.roth@amd.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
* OvmfPkg/ResetVector: pre-validate the data pages used in SEC phaseBrijesh Singh via groups.io2021-12-093-0/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 An SEV-SNP guest requires that private memory (aka pages mapped encrypted) must be validated before being accessed. The validation process consist of the following sequence: 1) Set the memory encryption attribute in the page table (aka C-bit). Note: If the processor is in non-PAE mode, then all the memory accesses are considered private. 2) Add the memory range as private in the RMP table. This can be performed using the Page State Change VMGEXIT defined in the GHCB specification. 3) Use the PVALIDATE instruction to set the Validated Bit in the RMP table. During the guest creation time, the VMM encrypts the OVMF_CODE.fd using the SEV-SNP firmware provided LAUNCH_UPDATE_DATA command. In addition to encrypting the content, the command also validates the memory region. This allows us to execute the code without going through the validation sequence. During execution, the reset vector need to access some data pages (such as page tables, SevESWorkarea, Sec stack). The data pages are accessed as private memory. The data pages are not part of the OVMF_CODE.fd, so they were not validated during the guest creation. There are two approaches we can take to validate the data pages before the access: a) Enhance the OVMF reset vector code to validate the pages as described above (go through step 2 - 3). OR b) Validate the pages during the guest creation time. The SEV firmware provides a command which can be used by the VMM to validate the pages without affecting the measurement of the launch. Approach #b seems much simpler; it does not require any changes to the OVMF reset vector code. Update the OVMF metadata with the list of regions that must be pre-validated by the VMM before the boot. Cc: Michael Roth <michael.roth@amd.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
* OvmfPkg: reserve CPUID pageBrijesh Singh via groups.io2021-12-095-0/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 Platform features and capabilities are traditionally discovered via the CPUID instruction. Hypervisors typically trap and emulate the CPUID instruction for a variety of reasons. There are some cases where incorrect CPUID information can potentially lead to a security issue. The SEV-SNP firmware provides a feature to filter the CPUID results through the PSP. The filtered CPUID values are saved on a special page for the guest to consume. Reserve a page in MEMFD that will contain the results of filtered CPUID values. Cc: Michael Roth <michael.roth@amd.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
* OvmfPkg: reserve SNP secrets pageBrijesh Singh via groups.io2021-12-095-0/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 During the SNP guest launch sequence, a special secrets page needs to be inserted by the VMM. The PSP will populate the page; it will contain the VM Platform Communication Key (VMPCKs) used by the guest to send and receive secure messages to the PSP. The purpose of the secrets page in the SEV-SNP is different from the one used in SEV guests. In SEV, the secrets page contains the guest owner's private data after the remote attestation. Cc: Michael Roth <michael.roth@amd.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
* OvmfPkg/ResetVector: introduce SEV metadata descriptor for VMM useBrijesh Singh via groups.io2021-12-093-0/+49
| | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 The OvmfPkgX86 build reserves memory regions in MEMFD. The memory regions get accessed in the SEC phase. AMD SEV-SNP require that the guest's private memory be accepted or validated before access. Introduce a Guided metadata structure that describes the reserved memory regions. The VMM can locate the metadata structure by iterating through the reset vector guid and process the areas based on the platform specific requirements. Cc: Michael Roth <michael.roth@amd.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
* OvmfPkg/ResetVector: move clearing GHCB in SecMainBrijesh Singh via groups.io2021-12-092-7/+1
| | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 In preparation for SEV-SNP support move clearing of the GHCB memory from the ResetVector/AmdSev.asm to SecMain/AmdSev.c. The GHCB page is not accessed until SevEsProtocolCheck() switch to full GHCB. So, the move does not make any changes in the code flow or logic. The move will simplify the SEV-SNP support. Cc: Michael Roth <michael.roth@amd.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
* UefiCpuPkg/MpInitLib: move SEV specific routines in AmdSev.cBrijesh Singh2021-12-097-306/+421
| | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 Move all the SEV specific function in AmdSev.c. No functional change intended. Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Michael Roth <michael.roth@amd.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Suggested-by: Jiewen Yao <Jiewen.yao@intel.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
* OvmfPkg/SecMain: move SEV specific routines in AmdSev.cBrijesh Singh via groups.io2021-12-094-154/+239
| | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3275 Move all the SEV specific function in AmdSev.c. No functional change intended. Cc: Michael Roth <michael.roth@amd.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
* BaseTools/VfrCompile: Correct Bit Field Flags for numeric/one ofHuang, Long12021-12-092-1/+4
| | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3752 Add Bit mask to numeric/one of opcode to set correctly Flags for Bit Field. VfrSyntax.g: Set "LFlags &= EDKII_IFR_DISPLAY_BIT" before "LFlags |= (EDKII_IFR_NUMERIC_SIZE_BIT & (_GET_CURRQEST_VARSIZE()));" VfrFormPkg.h: update "if (LFlags & EFI_IFR_DISPLAY)" with "if (LFlags & EDKII_IFR_DISPLAY_BIT)" in SetFlagsForBitField() Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Yuwei Chen <yuwei.chen@intel.com> Cc: Dandan Bi <dandan.bi@intel.com> Signed-off-by: Long1 Huang <long1.huang@intel.com> Reviewed-by: Dandan Bi <dandan.bi@intel.com>
* MdeModulePkg/Bus/Pci/UhciDxe: Fix the UsbHc memory allocate and free issuejdzhang2021-12-091-4/+4
| | | | | | | | | When use the UsbHcAllocMemFromBlock() and UsbHcFreeMem() to allocate memory and free memory for the UHC, it should use the corresponding host address but not the pci bus address. Signed-off-by: jdzhang <jdzhang@zd-tech.com.cn> Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
* BaseTools: Increase the DevicePath length for support more PCD value.Jiang, Xiaolu2021-12-091-1/+1
| | | | | | | | | | | | | | | Currently the PCD Value only support 13 Guid,When use more 13 pcd will cause the build tool fail, Need calculate the required memory,then allocate it. REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3718 Cc: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Yuwei Chen <yuwei.chen@intel.com> Signed-off-by: Xiaolu Jiang <xiaolu.jiang@intel.com> Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> Reviewed-by: Bob Feng <bob.c.feng@intel.com>
* UefiPayloadPkg: Add integration instruction for coreboot common errorLi, Aaron2021-12-081-0/+2
| | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3753 When integrate the latest UefiPayload with coreboot 4.14 or older, a common error would occur like "E: Not a usable UEFI firmware volume." The change adds an entry for how to solve this issue. Cc: Guo Dong <guo.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Signed-off-by: Aaron Li <aaron.li@intel.com>
* UefiPayloadPkg/UefiPayloadPkg.dsc:Add BootManagerLib for BootManagerMenuAppFeng, Ning2021-12-081-2/+4
| | | | | | | | | | | | Add PlatformBootManagerLibconstructor for BootManagerMenuApp, to get the value PcdBootManagefile overrided by platform side. Signed-off-by: Ning Feng <ning.feng@intel.com> Cc: Guo Dong <guo.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Cc: Maurice Ma <maurice.ma@intel.com> Cc: Benjamin You <benjamin.you@intel.com> Reviewed-by: Zhiguang Liu <zhiguang.liu@intel.com>
* UefiPayloadPkg: Skip ModuleInfo HOB in PayloadJiang, Guomin2021-12-081-1/+31
| | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3754 1. DxeCore will use ModuleInfo to install LoadedImage protocol for DxeCore. 2. DxeIpl will create the ModuleInfo of UniversalPayload. and UniversalPayload will create the ModuleInfo of DxeCore. 3. UniversalPayload should skip the ModuleInfo from the DxeIpl to avoid the mismatched ModuleInfo for DxeCore. Changes: 1. Use function IsHobNeed to check if the HOB should be added 2. Add the ModuleInfo check logic in IsHobNeed function Signed-off-by: Guomin Jiang <guomin.jiang@intel.com> Cc: Guo Dong <guo.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Cc: Maurice Ma <maurice.ma@intel.com> Cc: Benjamin You <benjamin.you@intel.com>
* UefiPayloadPkg: Add performance measurement featureLiu, Zhiguang2021-12-082-1/+39
| | | | | | | | | | | | | Add a Macro to enable performance measurement feature. For any platform that uses UniversalPayload, we assume it supports BaseCpuTimerLib and use it to align timerlib to get more accurate performance result. Reviewed-by: Guo Dong <guo.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Maurice Ma <maurice.ma@intel.com> Cc: Benjamin You <benjamin.you@intel.com> Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
* UefiPayloadPkg: Add missing Guid gUefiAcpiBoardInfoGuidLiu, Zhiguang2021-12-081-0/+3
| | | | | | | | | | The library PciSegmentInfoLibAcpiBoardInfo consumes the Guid gUefiAcpiBoardInfoGuid. Reviewed-by: Guo Dong <guo.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Maurice Ma <maurice.ma@intel.com> Cc: Benjamin You <benjamin.you@intel.com> Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
* UefiPayloadPkg: Increase SystemMemoryUefiRegionSize from 32M to 64MLiu, Zhiguang2021-12-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | Current, the SystemMemoryUefiRegionSize is 32M, which means in universal payload entry, we can at most use 32M heap. However, this can't meet the memory requirment for 5 level page table. In UefiPayloadPkg\UefiPayloadEntry\X64\VirtualMemory.c, we assume the Physical Address at most has 52 bits. Using 1G table support, with 52 bits Physical Address, to build page table, we need one page to hold 16 PML5 entries, each PML5 entry points to one page containing 512 PML4 entries. One PML4 entry points to one page containing 512 PML3 entries. Each PML3 entries will point to 1G memory space. Totally 8209 pages are needed, which is around 32M bytes. Therefore, increase SystemMemoryUefiRegionSize from 32M to 64M to support 5 level page tables. Reviewed-by: Guo Dong <guo.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Cc: Maurice Ma <maurice.ma@intel.com> Cc: Benjamin You <benjamin.you@intel.com> Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
* UefiPayloadPkg/PayloadEntry: Inherit 4/5-level paging from bootloaderNi, Ray2021-12-083-51/+39
| | | | | | | | | | | | | | | | | The patch removes the dep on PcdUse5LevelPageTable. Now the payload inherits the 5-level paging setting from bootloader in IA-32e mode and uses 4-level paging in legacy protected mode. This fix the potential issue when bootloader enables 5-level paging but 64bit payload sets 4-level page table to CR3 resulting CPU exception because PcdUse5LevelPageTable is FALSE. Signed-off-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Guo Dong <guo.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Reviewed-by: Maurice Ma <maurice.ma@intel.com> Cc: Benjamin You <benjamin.you@intel.com>
* UefiPayloadPkg/UefiPayloadPkg.fdf: Update DXE Apriori listCheng, Gao2021-12-081-0/+2
| | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3729 Put ReportStatusCodeRouterRuntimeDxe and StatusCodeHandlerRuntimeDxe in DXE Apriori list to enable DEBUG() via serial port through PeiDxeDebugLibReportStatusCode DebugLib instance as early as possible. The earliest point to add them is right before BlSupportDxe. Signed-off-by: Gao Cheng <gao.cheng@intel.com> Reviewed-by: Guo Dong <guo.dong@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com> Cc: Maurice Ma <maurice.ma@intel.com> Cc: Benjamin You <benjamin.you@intel.com>
* .pytool/Plugin/UncrustifyCheck: Add Uncrustify CI pluginMichael Kubacki2021-12-078-0/+1255
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3748 Adds a new CI plugin for Uncrustify. This is used to check coding standard compliance of source code to the EDK II C Coding Standards Specification. An external dependency is added in the plugin directory to retrieve the Uncrustify executable. Currently, the executable is from an edk2 fork of the application host in this repository: https://dev.azure.com/projectmu/Uncrustify/ Note that the Uncrustify application outputs the commit ID that the application was built from when given the --version parameter. This ID can be mapped to the version specified in the Uncrustify CI plugin external dependency file (uncrustify_ext_dep.yaml) such as 73.0.3 by visiting the Uncrustify edk2 fork release pipeline page which associates the NuGet package version with the commit ID it was built from: https://dev.azure.com/projectmu/Uncrustify/_build The default Uncrustify configuration files are added in the plugin directory. Additional details are in the Readme.md file added in the Uncrustify plugin directory. Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Sean Brogan <sean.brogan@microsoft.com> Cc: Bret Barkelew <Bret.Barkelew@microsoft.com> Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com> Reviewed-by: Bret Barkelew <bret.barkelew@microsoft.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Tested-by: Michael D Kinney <michael.d.kinney@intel.com>
* UnitTestFrameworkPkg: Apply uncrustify changesMichael Kubacki2021-12-0718-309/+368
| | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3737 Apply uncrustify changes to .c/.h files in the UnitTestFrameworkPkg package Cc: Andrew Fish <afish@apple.com> Cc: Leif Lindholm <leif@nuviainc.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com> Reviewed-by: Bret Barkelew <bret.barkelew@microsoft.com>
* UefiPayloadPkg: Apply uncrustify changesMichael Kubacki2021-12-0776-4104/+4313
| | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3737 Apply uncrustify changes to .c/.h files in the UefiPayloadPkg package Cc: Andrew Fish <afish@apple.com> Cc: Leif Lindholm <leif@nuviainc.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* UefiCpuPkg: Apply uncrustify changesMichael Kubacki2021-12-07143-13055/+14150
| | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3737 Apply uncrustify changes to .c/.h files in the UefiCpuPkg package Cc: Andrew Fish <afish@apple.com> Cc: Leif Lindholm <leif@nuviainc.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-03 15:02:13 +0000