summaryrefslogtreecommitdiffstats
path: root/OvmfPkg
Commit message (Collapse)AuthorAgeFilesLines
* OvmfPkg: Add CpuPageTableLib required by SecCore & CpuMpPeiJiaxin Wu2023-05-318-9/+8
| | | | | | | | | | | | | Add CpuPageTableLib required by SecCore & CpuMpPei in OvmfPkg. 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: Ray Ni <ray.ni@intel.com> Cc: Zeng Star <star.zeng@intel.com> Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* OvmfPkg/MicrovmX64: enable 1G pagesGerd Hoffmann2023-05-291-0/+3
| | | | | | | Reduces the memory footprint and speeds up booting. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg/OvmfPkgIa32X64: enable 1G pagesGerd Hoffmann2023-05-291-0/+3
| | | | | | | Reduces the memory footprint and speeds up booting. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg/PlatformInitLib: check PcdUse1GPageTableGerd Hoffmann2023-05-292-0/+6
| | | | | | | | | | | | If PcdUse1GPageTable is not enabled restrict the physical address space used to 1TB, to limit the amount of memory needed for identity mapping page tables. The same already happens in case the processor has no support for gigabyte pages. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg/PciHotPlugInitDxe: Do not reserve IO ports by default.Gerd Hoffmann2023-05-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | Flip the default for IO address space reservations for PCI(e) bridges and root ports with hotplug support from TRUE to FALSE. PCI(e) bridges will still get IO address space assigned in case: (a) Downstream devices actually need IO address space, or (b) Explicit configuration, using "qemu -device pcie-root-port,io-reserve=<size>". In case IO address space is exhausted edk2 will stop assigning resources to PCI(e) bridges. This is not limited to IO resources, the affected bridges will not get any memory resources assigned either. This patch solves this issue by not handing out the scarce IO address space, which is not needed in most cases anyway. Result is a more consistent PCI configuration in virtual machine configurations with many PCie root ports. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg/Bhyve/PlatformPei: drop S3Verification()Gerd Hoffmann2023-05-291-29/+0
| | | | | | | Drop S3Verification () which is dead code. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg/PlatformPei: drop S3Verification()Gerd Hoffmann2023-05-291-31/+0
| | | | | | | | | | | | | Not needed any more, SMM + 64-bit PEI + S3 suspend works now. Fixed by commits: - 8bd2028f9ac3 ("MdeModulePkg: Supporting S3 in 64bit PEI") - 6acf72901a2e ("UefiCpuPkg: Supporting S3 in 64bit PEI") See also https://bugzilla.tianocore.org/show_bug.cgi?id=4195 Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* OvmfPkg/VirtIoSerialDxe: Update for VS2015x86 compatibilityMichael D Kinney2023-05-291-5/+5
| | | | | | | | | | | | Move initialization of local variable structure from declaration to statements to fix VS2015x86 build break. 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> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Ard Biesheuvel <ardb+tianocore@kernel.org>
* OvmfPkg: RiscVVirt: Add missing SerialPortInitialize to SecAndrei Warkentin2023-05-173-1/+5
| | | | | | | | | | | | | | If the SerialPortLib had any initialization needed, this would be skipped in the RiscVVirt Sec. Follow the example seen elsewhere (ArmVirtPkg PrePi). Seen with BaseSerialPortLibRiscVSbiLibRam not using DBCN in Sec, yet using DBCN elsewhere. Cc: Daniel Schaefer <git@danielschaefer.me> Signed-off-by: Andrei Warkentin <andrei.warkentin@intel.com> Reviewed-by: Sunil V L <sunilvl@ventanamicro.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
* OvmfPkg: drop PlatformBootManagerLibGrubGerd Hoffmann2023-05-105-2129/+0
| | | | | | | | Not used any more, remove. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Acked-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg/AmdSev: stop using PlatformBootManagerLibGrubGerd Hoffmann2023-05-101-2/+8
| | | | | | | | | Use PlatformBootManagerLib with PcdBootRestrictToFirmware set to TRUE instead. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Acked-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg/NvVarsFileLib: disable in case PcdBootRestrictToFirmware is setGerd Hoffmann2023-05-102-1/+4
| | | | | | | | In case PcdBootRestrictToFirmware is set, disable loading EFI variables from NvVars file. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg/PlatformBootManagerLib: add PcdBootRestrictToFirmwareGerd Hoffmann2023-05-103-4/+71
| | | | | | | | | | | | Add new PCD PcdBootRestrictToFirmware. When set to TRUE restrict boot options to EFI applications embedded into the firmware image. Behavior should be identical to the PlatformBootManagerLibGrub library variant. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Acked-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg: Relax assertion that interrupts do not occur at TPL_HIGH_LEVELMichael Brown2023-05-091-3/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | At TPL_HIGH_LEVEL, CPU interrupts are disabled (as per the UEFI specification) and so we should never encounter a situation in which an interrupt occurs at TPL_HIGH_LEVEL. The specification also restricts usage of TPL_HIGH_LEVEL to the firmware itself. However, nothing actually prevents a UEFI application from calling gBS->RaiseTPL(TPL_HIGH_LEVEL) and then violating the invariant by enabling interrupts via the STI or equivalent instruction. Some versions of the Microsoft Windows bootloader are known to do this. NestedInterruptTplLib maintains the invariant that interrupts are disabled at TPL_HIGH_LEVEL (even when performing the dark art of deliberately manipulating the stack so that IRET will return with interrupts still disabled), but does not itself rely on external code maintaining this invariant. Relax the assertion that the interrupted TPL is below TPL_HIGH_LEVEL to an error message, to allow UEFI applications such as these versions of the Microsoft Windows bootloader to continue to function. Debugged-by: Gerd Hoffmann <kraxel@redhat.com> Debugged-by: Laszlo Ersek <lersek@redhat.com> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=2189136 Signed-off-by: Michael Brown <mcb30@ipxe.org> Acked-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg: Clarify invariants for NestedInterruptTplLibMichael Brown2023-05-091-2/+8
| | | | | | | | | | | | | | | | NestedInterruptTplLib relies on CPU interrupts being disabled to guarantee exclusive (and hence atomic) access to the shared state in IsrState. Nothing in the calling interrupt handler should have re-enabled interrupts before calling NestedInterruptRestoreTPL(), and the loop in NestedInterruptRestoreTPL() itself maintains the invariant that interrupts are disabled at the start of each iteration. Add assertions to clarify this invariant, and expand the comments around the calls to RestoreTPL() and DisableInterrupts() to clarify the expectations around enabling and disabling interrupts. Signed-off-by: Michael Brown <mcb30@ipxe.org> Acked-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: move OvmfTpmDxe.fdf.inc to Include/FdfGerd Hoffmann2023-05-066-5/+5
| | | | | Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* OvmfPkg: move OvmfTpmPei.fdf.inc to Include/FdfGerd Hoffmann2023-05-066-5/+5
| | | | | Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
* OvmfPkg/PlatformBootManagerLib: setup virtio serial consoleGerd Hoffmann2023-05-041-0/+47
| | | | | | | In case a virtio-serial device is present in the system register the first serial port as console. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg/VirtioSerialDxe: wire up in OvmfPkg*Gerd Hoffmann2023-05-048-0/+8
| | | | | | Add the driver to the ovmf builds. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg/VirtioSerialDxe: add driverGerd Hoffmann2023-05-045-0/+1884
| | | | | | | | | | | | | | | | | | | | Add a driver for the virtio serial device. The virtio serial device also known as virtio console device because initially it had only support for a single tty, intended to be used as console. Support for multiple streams and named data ports has been added later on. The driver supports tty ports only, they are registered as SerialIo UART in the system. Named ports are detected and logged, but not exposed as devices. They are usually used by guest agents to communicate with the host. It's not clear whenever it makes sense for the firmware to run such agents and if so which efi protocol could be to expose the ports. So leaving that for another day. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg: add IndustryStandard/VirtioSerial.hGerd Hoffmann2023-05-041-0/+64
| | | | | | | | | | | | | Add header files with structs and defines for the virtio serial device. The virtio serial device also known as virtio console device because initially it had only support for a single tty, intended to be used as console. Support for multiple streams and named data ports has been added later on. https://docs.oasis-open.org/virtio/virtio/v1.2/cs01/virtio-v1.2-cs01.html#x1-2900003 Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg: replace SECURE_BOOT_FEATURE_ENABLED with PcdSecureBootSupportedGerd Hoffmann2023-05-0411-64/+20
| | | | | | | Drop the '-D SECURE_BOOT_FEATURE_ENABLED' compile time option, use a new FeaturePcd instead. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg: allow setting Firmware Version from build command lineOliver Steffen2023-05-045-0/+16
| | | | | | | | | | | | | | | | Initialize gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVersionString with with the value of the variable "FIRMWARE_VER", if is is defined. Applies to all flavors of OvmfPkg. This behavior is already implemented in ArmVirtXen.dsc. It allows specifying the firmware version string on the build command line with -D FIRMARE_VER=... Introduce a common include file to be used in the .dsc files for the different OVMF flavors, and add the changes there. (ArmVirtPkg already has such a file). Signed-off-by: Oliver Steffen <osteffen@redhat.com>
* OvmfPkg/CcExitLib: Use documented XSave area base size for SEV-SNPRoth, Michael via groups.io2023-04-261-5/+4
| | | | | | | | | | | | | Currently OVMF tries to rely on the base size advertised via the CPUID table entries corresponding to leaf 0xD, sub-leafs 0x0/0x1. This will generally work for KVM guests, but might not for other SEV-SNP hypervisor implementations. Make the handling more robust by simply using the base area size documented by the APM. Reviewed-by: Tom Lendacky <thomas.lendacky@amd.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>
* OvmfPkg/CcExitLib: Fix SEV-SNP XSave area size calculationRoth, Michael via groups.io2023-04-261-3/+1
| | | | | | | | | | | | | | | | | | | | CPUID leaf 0xD sub-leafs 0x0 and 0x1 contain cumulative sizes for the enabled XSave areas. Those sizes are calculated by tallying up all the other sub-leafs that contain per-area size information for XSave areas that are currently enabled in XCr0/XSS. The current check has the logic inverted. Fix that. This doesn't seem to cause problems currently, but could in the future if OVMF made more extensive use of XSave areas. It was noticed while implementing SNP-related tests for KVM Unit Tests, which re-uses the OVMF #VC handler in some cases. Reported-by: Pavan Kumar Paluri <papaluri@amd.com> Cc: Pavan Kumar Paluri <papaluri@amd.com> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.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>
* OvmfPkg/AmdSevDxe: Update ConfidentialComputing blob struct definitionRoth, Michael via groups.io2023-04-262-3/+7
| | | | | | | | | | | | | | | | | | | | The Confidential Computing blob defined here is intended to match the definition defined by linux guest kernel. Previously, both definitions relied on natural alignment, but that relies on both OVMF and kernel being compiled as 64-bit. While there aren't currently any plans to enable SNP support for 32-bit compilations, the kernel definition has since been updated to use explicit padding/reserved fields to avoid this dependency. Update OVMF to match that definition. While at it, also fix up the Reserved fields to match the numbering used in the kernel. No functional changes (for currently-supported environments, at least). Reviewed-by: Tom Lendacky <thomas.lendacky@amd.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>
* OvmfPkg/AmdSevDxe: Allocate SEV-SNP CC blob as EfiACPIReclaimMemoryMichael Roth2023-04-261-14/+48
| | | | | | | | | | | | | | The SEV-SNP Confidential Computing blob contains metadata that should remain accessible for the life of the guest. Allocate it as EfiACPIReclaimMemory to ensure the memory isn't overwritten by the guest operating system later. Reported-by: Dov Murik <dovmurik@linux.ibm.com> Suggested-by: Dov Murik <dovmurik@linux.ibm.com> Reviewed-by: Dov Murik <dovmurik@linux.ibm.com> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Michael Roth <michael.roth@amd.com>
* OvmfPkg/VirtioMmioDeviceLib: virtio 1.0: Fix SetQueueAlignment.Jeff Brasen2023-04-121-1/+3
| | | | | | | Nothing to do here for virtio 1.0 devices Signed-off-by: Jeff Brasen <jbrasen@nvidia.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg: Update code to be more C11 compliant by using __func__Rebecca Cran2023-04-10123-540/+540
| | | | | | | | | | | | | __FUNCTION__ is a pre-standard extension that gcc and Visual C++ among others support, while __func__ was standardized in C99. Since it's more standard, replace __FUNCTION__ with __func__ throughout OvmfPkg. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
* OvmfPkg: Drop special Xcode5 version of exception handler libraryArd Biesheuvel2023-04-068-32/+0
| | | | | | | | | The generic and XCODE5 versions of this library are now identical, so drop the special case. The library will be removed entirely in a subsequent patch. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Jiewen Yao <jiewen.yao@intel.com>
* OvmfPkg: Consume new alignment-related macrosGerd Hoffmann2023-04-012-6/+3
| | | | | | | | | | This patch substitutes the macros that were renamed in the second patch with the new, shared alignment macros. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com> Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
* OvmfPkg: Rename IS_ALIGNED macros to avoid name collisionsGerd Hoffmann2023-04-012-5/+5
| | | | | | | | | | | | | This patch is a preparation for the patches that follow. The subsequent patches will introduce and integrate new alignment-related macros, which collide with existing definitions in OvmfPkg. Temporarily rename them to avoid build failure, till they can be substituted with the new, shared definitions. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com> Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
* OvmfPkg/CI: Revert SMP modeMichael Kubacki2023-03-311-1/+0
| | | | | | | | | | | | | | | | | This is causing excessive boot times in the VS2019 IA32/X64 Full run to shell tasks (> 2 minutes) and blocking all edk2 CI. This patch removes the change so it can be root caused separately without blocking other patches unrelated to OVMF. Reverts f92a9dce10281c103b04d6b38283e0ff1d677b91 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: Michael D Kinney <michael.d.kinney@intel.com> Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
* OvmfPkg/CI: Boot OVMF in SMP mode.Gerd Hoffmann2023-03-291-1/+1
| | | | | | Increase the chance that CI finds bugs in MP changes. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg: Use Xcode5 version of CpuExceptionHandlerLib for CLANGDWARFRebecca Cran2023-03-291-1/+1
| | | | | | | | | | | | | | | | | | | | | The CLANGDWARF toolchain has the same problem as XCODE5 linking CpuExceptionHandlerLib. So, use the Xcode5SecPeiCpuExceptionHandlerLib.inf when building with the CLANGDWARF toolchain. Since the difference is that the non-Xcode5 version uses `mov` while the Xcode5 version uses `lea`, they can be merged in future with the single version using `lea`. [ardb: the main difference is that the 'mov' instructions result in absolute symbol references, which are necessary because the code in question is copied in memory independently from the code that carries the symbols it refers to. The Xcode5 version has additional runtime handling to fix up the copied code with the correct absolute references.] Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Acked-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg: Replace static struct initialization with ZeroMem callRebecca Cran2023-03-291-1/+3
| | | | | | | | | | | Replace the static struct initialization with a call to ZeroMem to avoid generating a call to memset in certain build configurations. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Oliver Smith-Denny <osd@smith-denny.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
* OvmfPkg/PlatformInitLib: simplify mtrr setupGerd Hoffmann2023-03-281-21/+15
| | | | | | | | | | | | With the new mmconfig location at 0xe0000000 above the 32-bit PCI MMIO window we don't have to special-case the mmconfig xbar any more. We'll just add a mtrr uncachable entry starting at MMIO window base and ending at 4GB. Update comments to match reality. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
* OvmfPkg/PlatformInitLib: move mmconfig to 0xe0000000Gerd Hoffmann2023-03-286-10/+10
| | | | | | | | | | | | | | | | | Also swap the ordering of 32bit PCI MMIO window on q35, i.e. use the room between end of low memory and the start of the mmconfig bar. With a typical configuration on modern qemu with gigabyte-aligned memory the MMIO window start at 0x8000000, sized 1532 MB. In case there is memory present above 0x80000000 the window will start at 0xc0000000 instead, with 512 MB size. This depends on qemu commit 4a4418369d6d ("q35: fix mmconfig and PCI0._CRS"), so it raises the bar for the lowest supported version to qemu 4.1 (released Aug 2019). Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
* OvmfPkg/PlatformInitLib: update address space layout commentGerd Hoffmann2023-03-281-13/+15
| | | | | | | | Move the commment up so it is placed just before the address space calculations start. Also add q35 memory layout. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
* OvmfPkg/RiscVVirt: Support multiple reserved memory rangesSunil V L2023-03-281-77/+149
| | | | | | | | | | | | | | | | | | | | | | M-mode firmware ranges should not be used by EDK2/OS. Currently, we search for mmode_resv0 node in FDT and mark it as the reserved memory in EFI memory map. However, if there are multiple M-mode firmware ranges, then this will miss those extra ranges allowing the OS to access the memory and hit a fault. This issue is exposed since recent opensbi started creating two ranges for text and data. Fix this by searching for all reserved memory nodes and marking them as reserved in the EFI memory map. 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: Andrei Warkentin <andrei.warkentin@intel.com> Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Reviewed-by: Andrei Warkentin <andrei.warkentin@intel.com>
* OvmfPkg/PlatformBootManagerLib: use utf8 for the serial console.Gerd Hoffmann2023-03-232-5/+5
| | | | | | | | Time to leave behind relics from the last century and arrive in the modern world. Drop PC-ANSI Terminal Type for the serial console, use UTF-8 instead. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg/PlatformCI: Add CI coverage for RiscVVirtQemuSunil V L2023-03-162-0/+46
| | | | | | | | | | | Add support for building RiscVVirtQemu platform in CI. 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> Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
* OvmfPkg: Remove UefiCpuLib from module INFs.Yu Pu2023-03-1016-16/+0
| | | | | | | | | | | | Because UefiCpuPkg/UefiCpuLib is merged to MdePkg/CpuLib, remove the dependency of UefiCpuLib. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Yu Pu <yu.pu@intel.com> Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
* OvmfPkg: Add CpuLib to module INFs that depend on UefiCpuLib.Zhiguang Liu2023-03-105-0/+5
| | | | | | | | | | | | There are two libraries: MdePkg/CpuLib and UefiCpuPkg/UefiCpuLib and UefiCpuPkg/UefiCpuLib will be merged to MdePkg/CpuLib. To avoid build failure, add CpuLib dependency to all modules that depend on UefiCpuLib. Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
* OvmfPkg/SmbiosPlatformDxe: tweak fallback release dateGerd Hoffmann2023-03-091-1/+1
| | | | | | | | | | In case PcdFirmwareReleaseDateString is not set use a valid date as fallback. Using "unknown" makes Windows unhappy. Fixes: 4cb94f20b002 ("OvmfPkg/SmbiosPlatformDxe: use PcdFirmware*") Reported-by: ruifeng.gao@intel.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg: RiscVVirt: add SATA supportAndrei Warkentin2023-03-082-0/+14
| | | | | | | | | Tested with a PCIe pass-thru'd AHCI controller. Cc: Sunil V L <sunilvl@ventanamicro.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Signed-off-by: Andrei Warkentin <andrei.warkentin@intel.com>
* OvmfPkg: Add CpuPageTableLib required by MpInitLib.Yuanhao Xie2023-03-077-7/+16
| | | | | | | | | | | | | Add CpuPageTableLib required by MpInitLib in OvmfPkg. 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> Signed-off-by: Yuanhao Xie <yuanhao.xie@intel.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Tested-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* OvmfPkg/SmmCpuFeaturesLib: Check SmBase relocation supported or notWu, Jiaxin2023-03-062-2/+14
| | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4337 This patch is to check SmBase relocation supported or not. If gSmmBaseHobGuid found, means SmBase info has been relocated and recorded in the SmBase array. ASSERT it's not supported in OVMF. Cc: Eric Dong <eric.dong@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Zeng Star <star.zeng@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Ray Ni <ray.ni@intel.com>
* OvmfPkg/RiscVVirt: Add Stack HOBedk2-stable202302Sunil V L2023-03-011-3/+6
| | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4350 Currently, stack HOB is not created for the stack memory. This causes stack memory to be treated as free memory and any memory allocation which happens at this address causes random memory corruption. Fix this by creating the stack HOB which marks the memory as BS data. Cc: Liming Gao <gaoliming@byosoft.com.cn> Cc: Andrei Warkentin <andrei.warkentin@intel.com> 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> Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Reported-by: Andrei Warkentin <andrei.warkentin@intel.com> Tested-by: Andrei Warkentin <andrei.warkentin@intel.com> Reviewed-by: Andrei Warkentin <andrei.warkentin@intel.com>
* OvmfPkg/RiscVVirt: Fix SCT memory allocation test case failureSunil V L2023-02-231-2/+3
| | | | | | | | | | | | | | | Fix the UEFI memory range calculation by including the correct stack memory range. Without this fix, SCT hangs in MemoryAllocation test cases which call AllocateAddress(). 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: Andrei Warkentin <andrei.warkentin@intel.com> Reported-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Reviewed-by: Andrei Warkentin <andrei.warkentin@intel.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-09-05 22:16:06 +0000