summaryrefslogtreecommitdiffstats
path: root/OvmfPkg
Commit message (Collapse)AuthorAgeFilesLines
* OvmfPkg/CloudHv: Remove Q35 specificsSebastien Boeuf2022-01-131-10/+0
| | | | | | | | | Anything specific to the QEMU Q35 platform is not relevant for the CloudHv target. Acked-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
* OvmfPkg/CloudHv: Remove legacy 8259 PIC supportSebastien Boeuf2022-01-132-5/+0
| | | | | | | | | Cloud Hypervisor does not emulate any 8259 PIC, therefore there's no reason to load the corresponding driver for it. Acked-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
* OvmfPkg/CloudHv: Connect serial consoleSebastien Boeuf2022-01-133-10/+10
| | | | | | | | | | Cloud Hypervisor doesn't emulate any LPC bridge, therefore we simply need to rely on the serial I/O port to be connected as a console. It reuses the code from Xen since it's very generic. Acked-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
* OvmfPkg/CloudHv: Replace legacy 8254 PIT with local APIC timerSebastien Boeuf2022-01-132-2/+3
| | | | | | | | | | | Cloud Hypervisor doesn't emulate the legacy 8254 PIT, which is why instead of relying on it as the timer UEFI services, rely on the XenTimerDxe implementation. This is not Xen specific, as it simply uses the local APIC timer triggering interrupts on the vector 32. Acked-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
* OvmfPkg/CloudHv: Add new target for Cloud HypervisorSebastien Boeuf2022-01-132-0/+1530
| | | | | | | | | | | | Adding the new target CloudHvX64, copied directly from OvmfPkgX64. The point is to create a target dedicated for Cloud Hypervisor rather than trying to support both QEMU and Cloud Hypervisor on the same target. Improvements and cleanups will be performed in follow up patches. Acked-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
* OvmfPkg/AmdSev/SecretPei: Mark SEV launch secret area as reservedDov Murik2022-01-041-1/+1
| | | | | | | | | | | | | | | | | | | | | Mark the SEV launch secret MEMFD area as reserved, which will allow the guest OS to use it during the lifetime of the OS, without creating copies of the sensitive content. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Erdem Aktas <erdemaktas@google.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> Cc: Tobin Feldman-Fitzthum <tobin@linux.ibm.com> Signed-off-by: Dov Murik <dovmurik@linux.ibm.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Jiewen Yao <Jiewen.Yao@intel.com> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
* OvmfPkg: Bhyve: Delete unused AcpiTables/Ssdt.asl fileRebecca Cran2021-12-231-15/+0
| | | | | | | The Ssdt.asl file isn't used, so delete it. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Reviewed-by: Peter Grehan <grehan@freebsd.org>
* OvmfPkg: Call PlatformInitializeConsole for GPU passthrough caseStefan Berger2021-12-173-0/+17
| | | | | | | | | | | | | For GPU passthrough support we have to initialize the console after EfiBootManagerDispatchDeferredImages() has loaded ROMs, so call it after this. This was the calling order before the TCG physical presence support had to be moved and the console initialized earlier so user interaction could be supported before processing TCG physical presence opcodes. Signed-off-by: Stefan Berger <stefanb@linux.ibm.com> Tested-by: Shivanshu Goyal <shivanshu3@gmail.com> Acked-by: Jiewen Yao <jiewen.yao@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg/Bhyve: fix tls-enabled buildGerd Hoffmann2021-12-171-1/+1
| | | | | | | | Path doesn't exist below OvmfPkg/Bhyve, use the OvmfPkg version instead. Fixes build with -D NETWORK_TLS_ENABLE. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg/PlatformPei: Revert "stop using cmos for memory detection"Ard Biesheuvel2021-12-151-4/+55
| | | | | | | | This reverts commit 41d8bb30386ceab55787fc9f5aac6434e2493e27, as it breaks Cloud Hypervisor. Reported-by: Sebastien Boeuf <sebastien.boeuf@intel.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg: rework TPM configurationGerd Hoffmann2021-12-1514-18/+41
| | | | | | | | | | Rename TPM_ENABLE to TPM2_ENABLE so naming is in line with the ArmVirtPkg config option name. Add separate TPM1_ENABLE option for TPM 1.2 support. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Tested-by: Stefan Berger <stefanb@linux.ibm.com>
* OvmfPkg: create Tcg12ConfigPei.infGerd Hoffmann2021-12-154-12/+59
| | | | | | | | | | | | | | | | Split Tcg2ConfigPei.inf into two variants: Tcg12ConfigPei.inf with TPM 1.2 support included and Tcg2ConfigPei.inf supporting TPM 2.0 only. This allows x86 builds to choose whenever TPM 1.2 support should be included or not by picking the one or the other inf file. Switch x86 builds to Tcg12ConfigPei.inf, so they continue to have TPM 1.2 support. No functional change. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Stefan Berger <stefanb@linux.ibm.com> Tested-by: Stefan Berger <stefanb@linux.ibm.com>
* OvmfPkg: drop TPM_CONFIG_ENABLEGerd Hoffmann2021-12-157-13/+8
| | | | | | | | | Drop TPM_CONFIG_ENABLE config option. Including TPM support in the build without also including the TPM configuration menu is not useful. Suggested-by: Stefan Berger <stefanb@linux.ibm.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Tested-by: Stefan Berger <stefanb@linux.ibm.com>
* OvmfPkg: move tcg configuration to dsc and fdf include filesGerd Hoffmann2021-12-1519-359/+185
| | | | | | | | | | | With this in place the tpm configuration is not duplicated for each of our four ovmf config variants (ia32, ia32x64, x64, amdsev) and it is easier to keep them all in sync when updating the tpm configuration. No functional change. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
* OvmfPkg: remove unused TPM options from MicrovmX64.dscGerd Hoffmann2021-12-151-2/+0
| | | | Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg/PlatformPei: stop using cmos for memory detectionGerd Hoffmann2021-12-131-55/+4
| | | | | | | | Not needed for qemu 1.7 (released in 2013) and newer. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3593 Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg/PlatformPei: prefer etc/e820 for memory detectionGerd Hoffmann2021-12-131-5/+14
| | | | | | | | | | Prefer the e820 map provided via qemu firmware config interface for memory detection. Use rtc cmos only as fallback, which should be rarely needed these days as qemu supports etc/e820 since 2013. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3593 Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
* OvmfPkg/PlatformPei: ScanOrAdd64BitE820Ram improvementsGerd Hoffmann2021-12-131-8/+24
| | | | | | | | | | | | | | | | | | Add a bool parameter to ScanOrAdd64BitE820Ram to explicitly specify whenever ScanOrAdd64BitE820Ram should add HOBs for high memory (above 4G) or scan only. Also add a lowmem parameter so ScanOrAdd64BitE820Ram can report the memory size below 4G. This allows a more flexible usage of ScanOrAdd64BitE820Ram, a followup patch will use it for all memory detection. No functional change. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3593 Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
* OvmfPkg/Microvm: add READMEGerd Hoffmann2021-12-131-0/+50
| | | | | | | Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3599 Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
* OvmfPkg/Microvm/virtio: add virtio-mmio supportGerd Hoffmann2021-12-132-0/+3
| | | | | | | | | | | | Add virtio-mmio support (VirtioMmioDeviceLib and VirtioFdtDxe). With this patch added and a new enough qemu version (6.2+) edk2 will detect virtio-mmio devices, so it is possible to boot from storage (virtio-blk, virtio-scsi) or network (virtio-net). Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3689 Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
* OvmfPkg/Microvm/fdt: add empty fdtGerd Hoffmann2021-12-131-4/+22
| | | | | | | | | | | | | | | | | | | | FdtClient is unhappy without a device tree, so add an empty fdt which we can use in case etc/fdt is not present in fw_cfg. On ARM machines a device tree is mandatory for hardware detection, that's why FdtClient fails hard. On microvm the device tree is only used to detect virtio-mmio devices (this patch series) and the pcie host (future series). So edk2 can continue with limited functionality in case no device tree is present: no storage, no network, but serial console and direct kernel boot works. qemu release 6.2 & newer will provide a device tree for microvm. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3689 Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
* OvmfPkg/Microvm/fdt: load fdt from fw_cfgGerd Hoffmann2021-12-132-0/+46
| | | | | | | | | | | | Needed for hardware detection: virtio-mmio devices for now, later also pcie root bridge. Depends on patched qemu which actually provides an fdt: https://gitlab.com/kraxel/qemu/-/commits/sirius/microvm-device-tree Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3689 Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
* OvmfPkg/Microvm/fdt: add device tree supportGerd Hoffmann2021-12-132-0/+8
| | | | | | | | Add fdt parser from EmbeddedPkg (FdtLib and FdtClientDxe) to MicrovmX64. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3689 Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
* OvmfPkg/PlatformCI: add XenBuild.pyGerd Hoffmann2021-12-132-0/+46
| | | | | | Add build test for OvmfXen. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg/PlatformCI: dummy grub.efi for AmdSevGerd Hoffmann2021-12-131-0/+5
| | | | | | | | | | | | Building grub.efi for AmdSev is difficult because it depends on patches not yet merged to upstream grub. So shortcut the grub build by simply creating an empty grub.efi file. That allows to at least build-test the AmdSev variant. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Acked-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Dov Murik <dovmurik@linux.ibm.com>
* OvmfPkg/PlatformCI: add AmdSevBuild.pyGerd Hoffmann2021-12-132-0/+47
| | | | | | | | | Add build test for OvmfPkg/AmdSev. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Acked-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
* OvmfPkg/PlatformCI: add MicrovmBuild.pyGerd Hoffmann2021-12-132-0/+47
| | | | | | | | | Add build test for OvmfPkg/Microvm. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Acked-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
* OvmfPkg/PlatformCI: add BhyveBuild.pyGerd Hoffmann2021-12-132-0/+46
| | | | | | | | Add build test for OvmfPkg/Bhyve. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Acked-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg/PlatformCI: add QEMU_SKIPGerd Hoffmann2021-12-131-0/+5
| | | | | | | | | Skip the qemu boot test in case QEMU_SKIP is set to true. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Acked-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
* OvmfPkg/PlatformCI: factor out PlatformBuildLib.pyGerd Hoffmann2021-12-132-217/+228
| | | | | | | | | | | Move SettingsManager and PlatformBuilder classes to PlatformBuildLib.py file, keep only CommonPlatform class in PlatformBuild.py. Allows reusing these classes for other builds. Pure code motion, no functional change. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Acked-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg/Bhyve: add MemEncryptSevLibGerd Hoffmann2021-12-131-0/+1
| | | | | | | | | | Fixes build failure: build.py... /home/kraxel/projects/edk2/OvmfPkg/Bhyve/BhyveX64.dsc(...): error 1001: Module type [SEC] is not supported by library instance [/home/kraxel/projects/edk2/OvmfPkg/Library/BaseMemEncryptSevLib/DxeMemEncryptSevLib.inf] consumed by [/home/kraxel/projects/edk2/OvmfPkg/Sec/SecMain.inf] Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg/Microvm: add PcdConfidentialComputingGuestAttrGerd Hoffmann2021-12-131-0/+3
| | | | | | | | | | | | | | | Fixes build failure: /home/kraxel/projects/edk2/OvmfPkg/PlatformPei/AmdSev.c: In function ‘AmdSevInitialize’: /home/kraxel/projects/edk2/MdePkg/Include/Library/PcdLib.h:511:38: error: implicit declaration of function ‘_PCD_SET_MODE_64_S_PcdConfidentialComputingGuestAttr’ [-Werror=implicit-function-declaration] 511 | #define PcdSet64S(TokenName, Value) _PCD_SET_MODE_64_S_##TokenName ((Value)) | ^~~~~~~~~~~~~~~~~~~ /home/kraxel/projects/edk2/OvmfPkg/PlatformPei/AmdSev.c:410:17: note: in expansion of macro ‘PcdSet64S’ 410 | PcdStatus = PcdSet64S (PcdConfidentialComputingGuestAttr, CCAttrAmdSevSnp); | ^~~~~~~~~ cc1: all warnings being treated as errors Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg-EmuVariableFvbRuntimeDxe: Support Access To Memory Above 4Glixianglai2021-12-119-9/+23
| | | | | | | | | | | | | | | | In FvbInitialize Function, PcdFlashNvStorageVariableBase64 PcdFlashNvStorageFtwWorkingBase PcdFlashNvStorageFtwSpareBase will not exceed 0x100000000, Due to truncation and variable type limitations. That leads to the NV variable cannot be saved to the memory above 4G. Modify as follows: 1.Remove the forced type conversion of UINT32. 2.Use UINT64 type variables. Signed-off-by: xianglai li <lixianglai@loongson.cn> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* OvmfPkg/OvmfXen: Fix Xen buildJason Andryuk2021-12-111-0/+1
| | | | | | | | | | | | | | | | | | | | | | | commit 202fb22be6e9 "OvmfPkg/SecMain: validate the memory used for decompressing Fv" broke building OvmfXen with: edk2/OvmfPkg/OvmfXen.dsc(...): error 1001: Module type [SEC] is not supported by library instancer [edk2/OvmfPkg/Library/BaseMemEncryptSevLib/DxeMemEncryptSevLib.inf] consumed by [edk2/OvmfPkg/Sec/SecMain.inf] The above commit added a reference to MemEncryptSevLib into SecMain.inf, but OvmfXen.dsc doesn't have a MemEncryptSevLib entry for SEC. Add one like OvmfPkgX64.dsc has. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Julien Grall <julien@xen.org> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Jason Andryuk <jandryuk@gmail.com>
* OvmfPkg: Install ACPI tables for Cloud HypervisorSebastien Boeuf2021-12-115-1/+141
| | | | | | | | | | Adding support for retrieving the Cloud Hypervisor ACPI tables as a fallback mechanism if tables are not found through fw_cfg. Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Rob Bradford <robert.bradford@intel.com> Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
* OvmfPkg: Generalize AcpiPlatformDxeSebastien Boeuf2021-12-1112-14/+14
| | | | | | | | | | | | Don't make the package Qemu centric so that we can introduce some alternative support for other VMMs not using the fw_cfg mechanism. This patch is purely about renaming existing files with no functional change. Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
* OvmfPkg: Retrieve SMBIOS from Cloud HypervisorSebastien Boeuf2021-12-115-5/+66
| | | | | | | | | | Add a fallback on the SMBIOS code to find the SMBIOS table for Cloud Hypervisor if it couldn't be found for Qemu through fw_cfg. Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Rob Bradford <robert.bradford@intel.com> Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
* OvmfPkg: Create global entry point for SMBIOS parsingSebastien Boeuf2021-12-114-35/+54
| | | | | | | | | Move the generic entry point part out of Qemu.c to anticipate the addition of new ways of retrieving the SMBIOS table. Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
* OvmfPkg: Handle Cloud Hypervisor host bridgeSebastien Boeuf2021-12-1110-3/+78
| | | | | | | | | | Handle things differently when the detected host bridge matches the Cloud Hypervisor PCI host bridge identifier. Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Rob Bradford <robert.bradford@intel.com> Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.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>
* 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>
* 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>
* 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>
* 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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-02 11:03:43 +0000