summaryrefslogtreecommitdiffstats
path: root/OvmfPkg/OvmfXen.dsc
Commit message (Collapse)AuthorAgeFilesLines
* OvmfPkg/OvmfXen: Set PcdFSBClockAnthony PERARD2021-04-131-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Update gEfiMdePkgTokenSpaceGuid.PcdFSBClock so it can have the correct value when SecPeiDxeTimerLibCpu start to use it for the APIC timer. Currently, nothing appear to use the value in PcdFSBClock before XenPlatformPei had a chance to set it even though TimerLib is included in modules run before XenPlatformPei. XenPlatformPei doesn't use any of the functions that would use that value. No other modules in the PEI phase seems to use the TimerLib before PcdFSBClock is set. There are currently two other modules in the PEI phase that needs the TimerLib: - S3Resume2Pei, but only because LocalApicLib needs it, but nothing is using the value from PcdFSBClock. - CpuMpPei, but I believe it only runs after XenPlatformPei Before the PEI phase, there's the SEC phase, and SecMain needs TimerLib because of LocalApicLib. And it initialise the APIC timers for the debug agent. But I don't think any of the DebugLib that OvmfXen could use are actually using the *Delay functions in TimerLib, and so would not use the value from PcdFSBClock which would be uninitialised. A simple runtime test showed that TimerLib doesn't use PcdFSBClock value before it is set. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2490 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20210412133003.146438-8-anthony.perard@citrix.com> [lersek@redhat.com: cast Freq to UINT32 for PcdSet32S(), not for ASSERT()]
* OvmfPkg: Add MicrocodeLib in DSC files.Ray Ni2021-04-091-0/+1
| | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3303 Signed-off-by: Ray Ni <ray.ni@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg: Consume MdeLibs.dsc.inc for RegisterFilterLibDandan Bi2021-03-311-1/+4
| | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3246 MdeLibs.dsc.inc was added for some basic/default library instances provided by MdePkg and RegisterFilterLibNull Library was also added into it as the first version of MdeLibs.dsc.inc. So update platform dsc to consume MdeLibs.dsc.inc for RegisterFilterLibNull which will be consumed by IoLib and BaseLib. Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Signed-off-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Acked-by: Ard Biesheuvel <ardb@kernel.org>
* OvmfPkg: strip build paths in release buildsRoss Burton2021-03-241-0/+1
| | | | | | | | | | | | GenFw will embed a NB10 section which contains the path to the input file, which means the output files have build paths embedded in them. To reduce information leakage and ensure reproducible builds, pass --zero in release builds to remove this information. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3256 Signed-off-by: Ross Burton <ross.burton@arm.com> Message-Id: <20210324115819.605436-1-ross.burton@arm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Introduce PciHostBridgeUtilityLib classJiahui Cen via groups.io2021-01-201-0/+1
| | | | | | | | | | | | | | | | | | | | | | Introduce a new PciHostBridgeUtilityLib class to share duplicate code between OvmfPkg and ArmVirtPkg. Extract function PciHostBridgeUtilityResourceConflict from PciHostBridgeResourceConflict in OvmfPkg/PciHostBridgeLib. BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3059 Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Rebecca Cran <rebecca@bsdio.com> Cc: Peter Grehan <grehan@freebsd.org> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Julien Grall <julien@xen.org> Signed-off-by: Jiahui Cen <cenjiahui@huawei.com> Signed-off-by: Yubo Miao <miaoyubo@huawei.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20210119011302.10908-2-cenjiahui@huawei.com>
* OvmfPkg: disable list length checks in NOOPT and DEBUG buildsLaszlo Ersek2021-01-191-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In NOOPT and DEBUG builds, if "PcdMaximumLinkedListLength" is nonzero, then several LIST_ENTRY *node* APIs in BaseLib compare the *full* list length against the PCD. This turns the time complexity of node-level APIs from constant to linear, and that of full-list manipulations from linear to quadratic. As an example, consider the EFI_SHELL_FILE_INFO list, which is a data structure that's widely used in the UEFI shell. I randomly extracted 5000 files from "/usr/include" on my laptop, spanning 1095 subdirectories out of 1538, and then ran "DIR -R" in the UEFI shell on this tree. These are the wall-clock times: PcdMaximumLinkedListLength PcdMaximumLinkedListLength =1,000,000 =0 -------------------------- --------------------------- FAT 4 min 31 s 18 s virtio-fs 5 min 13 s 1 min 33 s Checking list lengths against an arbitrary maximum (default: 1,000,000) seems useless even in NOOPT and DEBUG builds, while the cost is significant; so set the PCD to 0. Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien@xen.org> Cc: Leif Lindholm <leif@nuviainc.com> Cc: Peter Grehan <grehan@freebsd.org> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Cc: Rebecca Cran <rebecca@bsdio.com> Cc: Sami Mujawar <sami.mujawar@arm.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3152 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Message-Id: <20210113085453.10168-10-lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
* OvmfPkg/XenPlatformPei: Use CPUID to get physical address width on XenIgor Druzhinin2021-01-191-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We faced a problem with passing through a PCI device with 64GB BAR to UEFI guest. The BAR is expectedly programmed into 64-bit PCI aperture at 64G address which pushes physical address space to 37 bits. That is above 36-bit width that OVMF exposes currently to a guest without tweaking PcdPciMmio64Size knob. The reverse calculation using this knob was inhereted from QEMU-KVM platform code where it serves the purpose of finding max accessible physical address without necessary trusting emulated CPUID physbits value (that could be different from host physbits). On Xen we expect to use CPUID policy to level the data correctly to prevent situations with guest physbits > host physbits e.g. across migrations. The next aspect raising concern - resource consumption for DXE IPL page tables and time required to map the whole address space in case of using CPUID bits directly. That could be mitigated by enabling support for 1G pages in DXE IPL configuration. 1G pages are available on most CPUs produced in the last 10 years and those without don't have many phys bits. Remove all the redundant code now (including PcdPciMmio64.. handling that's not used on Xen anyway) and grab physbits directly from CPUID that should be what baremetal UEFI systems do. Signed-off-by: Igor Druzhinin <igor.druzhinin@citrix.com> Message-Id: <1610509335-23314-1-git-send-email-igor.druzhinin@citrix.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Julien Grall <julien@xen.org> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com> [lersek@redhat.com: fix up authorship from groups.io-mangled From line] [lersek@redhat.com: wrap commit message at 74 characters]
* OvmfPkg: add TimeBaseLib resolution for OvmfXenLeif Lindholm2021-01-081-0/+1
| | | | | | | | | | | | | | | | Commit 55ee36b0c490 ("EmbeddedPkg/RealTimeClockRuntimeDxe: Use helper functions from TimeBaseLib") added a TimeBaseLib dependency to RealTimeClockRuntimeDxe, which now breaks build of OvmfXen.dsc. Add a resolution for EmbeddedPkg/Library/TimeBaseLib/TimeBaseLib.inf. Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Julien Grall <julien@xen.org> Signed-off-by: Leif Lindholm <leif@nuviainc.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/MemEncryptSevLib: Add an interface to retrieve the encryption maskTom Lendacky2021-01-071-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3108 To ensure that we always use a validated encryption mask for an SEV-ES guest, create a new interface in the MemEncryptSevLib library to return the encryption mask. This can be used in place of the multiple locations where CPUID is used to retrieve the value (which would require validation again) and allows the validated mask to be returned. The PEI phase will use the value from the SEV-ES work area. Since the SEV-ES work area isn't valid in the DXE phase, the DXE phase will use the PcdPteMemoryEncryptionAddressOrMask PCD which is set during PEI. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Rebecca Cran <rebecca@bsdio.com> Cc: Peter Grehan <grehan@freebsd.org> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Julien Grall <julien@xen.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <e12044dc01b21e6fc2e9535760ddf3a38a142a71.1610045305.git.thomas.lendacky@amd.com>
* OvmfPkg/OvmfXen.dsc: Enable MD5 while enable iSCSIGao, Zhichao2020-11-171-0/+3
| | | | | | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3003 There is a plan to make MD5 disable as default. The new MACRO ENABLE_MD5_DEPRECATED_INTERFACES would be introduced to enable MD5. Make the definition ahead of the change to avoid build error after the MACRO changed. Enable iSCSI. Signed-off-by: Zhichao Gao <zhichao.gao@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Leif Lindholm <leif@nuviainc.com> Message-Id: <20201112055558.2348-11-zhichao.gao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Build-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Add VariablePolicy engine to OvmfPkg platformBret Barkelew2020-11-171-0/+4
| | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=2522 Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Bret Barkelew <brbarkel@microsoft.com> Signed-off-by: Bret Barkelew <brbarkel@microsoft.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: enable HttpDynamicCommandVladimir Olovyannikov2020-10-011-0/+4
| | | | | | | | | | | Enable HttpDynamicCommand (Shell command "http") for OvmfPkg platforms. BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2857 Signed-off-by: Vladimir Olovyannikov <vladimir.olovyannikov@broadcom.com> Message-Id: <20200722205434.4348-3-vladimir.olovyannikov@broadcom.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com> [lersek@redhat.com: remove groups.io corruption from Author meta-datum]
* OvmfPkg: Add RngLib based on TimerLib for CryptoMatthew Carlson2020-09-181-0/+1
| | | | | | | | | | | | | | | | | | | | Updates the DSC's for Ovmf based platforms to add a RngLib that uses the TimerLib. This is due to a later change that adds TimerLib as a dependency for OpenSSL. The TimerLib based RngLib mimics the behavior of OpenSSL previously and it is recommended to switch to a better source of entropy than the system's performance counter. Ref: https://github.com/tianocore/edk2/pull/845 Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1871 Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Julien Grall <julien@xen.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Matthew Carlson <matthewfcarlson@gmail.com>
* OvmfPkg: Prepare OvmfPkg to use the VmgExitLib libraryTom Lendacky2020-08-161-0/+1
| | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198 Various CpuExceptionHandlerLib libraries will updated to use the new VmgExitLib library. To prevent any build breakage, update the OvmfPkg DSC files that use a form of the CpuExceptionHandlerLib library to include the VmgExitLib library. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Julien Grall <julien@xen.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/OvmfPkg*.dsc: Change PCDs type about status codeTan, Ming2020-06-181-3/+3
| | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2786 Since the type of PcdStatusCodeUseSerial and PcdStatusCodeUseMemory in MdeModulePkg.dec are changed, so change them from PcdsFeatureFlag to PcdsFixedAtBuild in dsc files. Cc: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Signed-off-by: Ming Tan <ming.tan@intel.com>
* OvmfPkg: Skip initrd command on Xcode toolchainRoman Bolshakov2020-05-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | OVMF booting stops with the assert if built with Xcode on macOS: Loading driver at 0x0001FAB8000 EntryPoint=0x0001FABF249 LinuxInitrdDynamicShellCommand.efi InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 1F218398 ProtectUefiImageCommon - 0x1F218140 - 0x000000001FAB8000 - 0x0000000000008A60 ASSERT_EFI_ERROR (Status = Unsupported) ASSERT LinuxInitrdDynamicShellCommand.c(378): !EFI_ERROR (Status) The assert comes from InitializeHiiPackage() after an attempt to retrieve HII package list from ImageHandle. Xcode still doesn't support HII resource section and LinuxInitrdDynamicShellCommand depends on it. Likewise 277a3958d93a ("OvmfPkg: Don't include TftpDynamicCommand in XCODE5 tool chain"), disable initrd command if built with Xcode toolchain Fixes: ec41733cfd10 ("OvmfPkg: add the 'initrd' dynamic shell command") Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Liming Gao <liming.gao@intel.com> Cc: Andrew Fish <afish@apple.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com> Message-Id: <20200514134820.62047-1-r.bolshakov@yadro.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Use toolchain appropriate CpuExceptionHandlerLibLendacky, Thomas2020-05-111-0/+4
| | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2340 During the SEC phase, use the XCODE5 CpuExceptionHandlerLib library in place of the standard library when building with the XCODE5 toolchain. The SEC XCODE5 version of the library performs binary patching and should only be used when building with the XCODE5 toolchain. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Julien Grall <julien@xen.org> Cc: Liming Gao <liming.gao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Message-Id: <0cfdd51deb6d39e08380645f2022b9b76e29f66f.1588856809.git.thomas.lendacky@amd.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
* OvmfPkg/OvmfXen: Introduce DEBUG_ON_HYPERVISOR_CONSOLE build flagAnthony PERARD2020-04-281-0/+11
| | | | | | | | | | | | Introduce DEBUG_ON_HYPERVISOR_CONSOLE build flag to enable logging debug output to the Xen console. This will work with both Xen HVM guest and Xen PVH guest whereas the default PlatformDebugLibIoPort works only in HVM when QEMU is present. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Message-Id: <20200423095358.2518197-6-anthony.perard@citrix.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/OvmfXen: Remove DEBUG_ON_SERIAL_PORTAnthony PERARD2020-04-281-39/+1
| | | | | | | | | | | | | | | | | | | | Remove support for DEBUG_ON_SERIAL_PORT because OvmfXen can't be build with it due to a circular dependency: DebugLib : BaseDebugLibSerialPort -> SerialPortLib : XenConsoleSerialPortLib -> XenHypercallLib : XenHypercallLib -> DebugLib Also, if that dependency is fixed, I think it would be harder to find which console the debug is sent to when running an HVM guest. The xen console isn't the serial console used by default. Furthermore, XenHypercallLib isn't initialised early enough, so we would loose debug output from the SEC phase and early PEI phase. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200423095358.2518197-2-anthony.perard@citrix.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
* OvmfPkg/ResetSystemLib: introduce the DxeResetSystemLib instanceLaszlo Ersek2020-04-221-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The BaseResetSystemLib instance is not suitable for OS runtime, because its ResetShutdown() implementation calls PciRead16 (OVMF_HOSTBRIDGE_DID). On q35, this boils down to a memory-mapped config space access -- but we never ask the OS to map MMCONFIG for runtime. There are at least three alternatives to approach this: (1) Investigate "MdePkg/Library/DxeRuntimePciExpressLib", which offers some kind of runtime mapping for MMCONFIG. (2) Consume PciCf8Lib directly, rather than PciLib, in ResetSystemLib. Then we'll read OVMF_HOSTBRIDGE_DID from the config space with IO port accesses on q35 too, not just on i440fx. IO ports don't depend on page tables. (3) In the lib constructor, cache "mAcpiPmBaseAddress" based on "PcdOvmfHostBridgePciDevId" (which is set by PlatformPei). Then the host bridge type will be known at runtime without PCI config space accesses. This patch follows approach (3), in order to mirror AcpiTimerLib. Notes: * This patch is best viewed with "git show --find-copies-harder -C43". * PCDs are not usable in the DXE_CORE, as the PCD PPI is gone, and the PCD protocol is not available yet. (The DXE_CORE does consume ResetSystemLib in practice, when OVMF is built with -D SOURCE_DEBUG_ENABLE.) Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien@xen.org> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Cc: Rebecca Cran <rebecca@bsdio.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2675 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200417153751.7110-7-lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Rebecca Cran <rebecca@bsdio.com> [lersek@redhat.com: move third Note (with repro info) to BZ comment]
* OvmfPkg/ResetSystemLib: rename to BaseResetSystemLibLaszlo Ersek2020-04-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | In preparation for introducing DxeResetSystemLib, rename the current (only) ResetSystemLib instance to BaseResetSystemLib. In the DSC files, keep the ResetSystemLib resolution in the same [LibraryClasses] section, but move it near the TimerLib resolution, as the differences between the ResetSystemLib instances will mostly follow those seen under OvmfPkg/Library/AcpiTimerLib. (While OvmfXen does not use "OvmfPkg/Library/AcpiTimerLib", perform the same movement there too, for keeping future DSC diffing simple.) Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien@xen.org> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Cc: Rebecca Cran <rebecca@bsdio.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2675 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200417153751.7110-6-lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
* OvmfPkg: remove handling of properties tableArd Biesheuvel2020-04-071-1/+0
| | | | | | | | | | | | | | The UEFI properties table and the associated memory protection feature was severely broken from the start, and has been deprecated for a while. Let's drop all references to it from OVMF so we can safely remove it from the DXE core as well. Link: https://bugzilla.tianocore.org/show_bug.cgi?id=2633 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Jiewen Yao <Jiewen.yao@intel.com> Acked-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
* OvmfPkg: Fix SMM/RT driver section alignment for XCODE5/CLANGPDBVitaly Cheptsov2020-04-011-2/+6
| | | | | | | | | | | | | | | | REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2642 This patch resolves the problem of using memory protection attributes when OVMF firmware is compiled with XCODE5 and CLANGPDB. Cc: Andrew Fish <afish@apple.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Marvin Häuser <mhaeuser@outlook.de> Signed-off-by: Vitaly Cheptsov <vit9696@protonmail.com> Message-Id: <20200329132158.35259-2-cheptsov@ispras.ru> Acked-by: Laszlo Ersek <lersek@redhat.com> [lersek@redhat.com: fix whitespace issues reported by git-am] [lersek@redhat.com: replace "CC:" tags with "Cc:" ones for PatchCheck.py]
* OvmfPkg/OvmfXen: fix build by providing QemuLoadImageLib resolutionArd Biesheuvel2020-03-061-1/+1
| | | | | | | | | | | | | | | | | Commit 859b55443a4253ba ("OvmfPkg/PlatformBootManagerLib: switch to QemuLoadImageLib") replaced a dependency on LoadLinuxLib with one on QemuLoadImageLib in the PlatformBootManagerLib implementation that is shared between all OVMF builds, without taking into account that even the Xen targeted builds incorporate this code, which is only used to load kernels passed via the QEMU command line. Since this is dead code on Xen, we can satisfy the dependency using the generic version of QemuLoadImageLib, which does not rely on LoadLinuxLib, which we can therefore drop from OvmfXen.dsc. Fixes: 859b55443a4253bad8bb618d04a51b2ded67f24b Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: add the 'initrd' dynamic shell commandArd Biesheuvel2020-03-041-0/+4
| | | | | | | | | | Add the 'initrd' dynamic shell command to the build so we can load Linux initrds straight from the shell using the new generic protocol, which does not rely on initrd= being passed on the command line. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2564 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: introduce PcdCsmEnable feature flagLaszlo Ersek2020-02-051-0/+3
| | | | | | | | | | | | | | | | | | | | | In the DXE phase and later, it is possible for a module to dynamically determine whether a CSM is enabled. An example can be seen in commit 855743f71774 ("OvmfPkg: prevent 64-bit MMIO BAR degradation if there is no CSM", 2016-05-25). SEC and PEI phase modules cannot check the Legacy BIOS Protocol however. For their sake, introduce a new feature PCD that simply reflects the CSM_ENABLE build flag. Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien@xen.org> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200129214412.2361-11-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg/OvmfXen.dsc: remove PcdCpu* dynamic defaultsLaszlo Ersek2020-01-291-4/+0
| | | | | | | | | | | | | | | | | | | PcdCpuMaxLogicalProcessorNumber and PcdCpuApInitTimeOutInMicroSeconds are only referenced in "OvmfPkg/PlatformPei/PlatformPei.inf", and OvmfXen does not include that module. Remove the unnecessary dynamic PCD defaults from "OvmfXen.dsc". Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien.grall@arm.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1515 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Message-Id: <20191022221554.14963-2-lersek@redhat.com> Acked-by: Anthony PERARD <anthony.perard@citrix.com>
* OvmfPkg: Make SOURCE_DEBUG_ENABLE actually need to be set to TRUEPeter Jones2019-10-221-8/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | Currently some tests check the value of SOURCE_DEBUG_ENABLE, and some tests check if it's defined or not. Additionally, in UefiPayloadPkg as well as some other trees, we define it as FALSE in the .dsc file. This patch changes all of the Ovmf platforms to explicitly define it as FALSE by default, and changes all of the checks to test if the value is TRUE. Signed-off-by: Peter Jones <pjones@redhat.com> Message-Id: <20190920184507.909884-1-pjones@redhat.com> [lersek@redhat.com: drop Contributed-under line, per TianoCore BZ#1373] [lersek@redhat.com: replace "!= TRUE" with more idiomatic "== FALSE"] Cc: Andrew Fish <afish@apple.com> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Julien Grall <julien.grall@arm.com> Cc: Leif Lindholm <leif.lindholm@linaro.org> Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Peter Jones <pjones@redhat.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Acked-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
* OvmfPkg/OvmfXen: use RealTimeClockRuntimeDxe from EmbeddedPkgAnthony PERARD2019-08-211-1/+2
| | | | | | | | | | | | | A Xen PVH guest doesn't have a RTC that OVMF would expect, so PcatRealTimeClockRuntimeDxe fails to initialize and prevent the firmware from finish to boot. To prevent that, we will use XenRealTimeClockLib which simply always return the same time. This will work on both Xen PVH and HVM guests. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20190813113119.14804-36-anthony.perard@citrix.com>
* OvmfPkg: Introduce XenIoPvhDxe to initialize Grant TablesAnthony PERARD2019-08-211-0/+2
| | | | | | | | | | | | | | | XenIoPvhDxe use XenIoMmioLib to reserve some space to be use by the Grant Tables. The call is only done if it is necessary, we simply detect if the guest is PVH, as in this case there is currently no PCI bus, and no PCI Xen platform device which would start the XenIoPciDxe and allocate the space for the Grant Tables. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20190813113119.14804-34-anthony.perard@citrix.com>
* OvmfPkg/PlatformBootManagerLib: Use a Xen console for ConOut/ConInAnthony PERARD2019-08-211-0/+4
| | | | | | | | | | | | | | | | | | | | On a Xen PVH guest, none of the existing serial or console interface works, so we add a new one, based on XenConsoleSerialPortLib, and implemented via SerialDxe. That is a simple console implementation that can work on both PVH guest and HVM guests, even if it is rarely going to be used on HVM. Have PlatformBootManagerLib look for the new console, when running as a Xen guest. Since we use VENDOR_UART_DEVICE_PATH, fix its description and coding style. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20190813113119.14804-32-anthony.perard@citrix.com>
* OvmfPkg/OvmfXen: Introduce XenTimerDxeAnthony PERARD2019-08-211-2/+1
| | | | | | | | | | | | | | | | "OvmfPkg/8254TimerDxe" is replaced with a Xen-specific EFI_TIMER_ARCH_PROTOCOL implementation. Also remove 8259InterruptControllerDxe as it is not used anymore. This Timer uses the local APIC timer as time source as it can work on both a Xen PVH guest and an HVM one. Based on the "OvmfPkg/8254TimerDxe" implementation. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20190813113119.14804-31-anthony.perard@citrix.com>
* OvmfPkg/OvmfXen: Override PcdFSBClock to Xen vLAPIC timer frequencyAnthony PERARD2019-08-211-0/+3
| | | | | | | | | | | PcdFSBClock is used by SecPeiDxeTimerLibCpu, the TimerLib implementation. It will also be used by XenTimerDxe. Override PcdFSBClock to match Xen vLAPIC timer frequency. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20190813113119.14804-30-anthony.perard@citrix.com>
* OvmfPkg/Library/XenPlatformLib: New libraryAnthony PERARD2019-08-211-0/+1
| | | | | | | | | | | The purpose of XenPlatformLib is to regroup the few functions that are used in several places to detect if Xen is detected, and to get the XenInfo HOB. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20190813113119.14804-14-anthony.perard@citrix.com>
* OvmfPkg/OvmfXen: use a TimerLib instance that depends only on the CPUAnthony PERARD2019-08-211-6/+1
| | | | | | | | | | | | | | | | | | | | | | The ACPI Timer isn't present in a PVH guest, but local APIC works on both PVH and HVM. Note that the use of SecPeiDxeTimerLibCpu might be an issue with a driver of type DXE_RUNTIME_DRIVER. I've attempted to find out which of the DXE_RUNTIME_DRIVER uses the TimerLib at runtime. I've done that by replacing the TimerLib evaluation in [LibraryClasses.common.DXE_RUNTIME_DRIVER] by a different one and checking every module that uses it (with the --report-file=report build option). ResetSystemRuntimeDxe is calling the TimerLib API at runtime to do the operation "EfiResetCold", so this may never complete if the OS have disabled the Local APIC Timer. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20190813113119.14804-10-anthony.perard@citrix.com>
* OvmfPkg: Introduce XenPlatformPeiAnthony PERARD2019-08-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Introduce XenPlatformPei, a copy of OvmfPkg/PlatformPei without some of QEMU specific initialization, Xen does not support QemuFwCfg. This new module will be adjusted to accommodate Xen PVH. fw_cfg dependents that have been removed, which are dynamically skipped when running PlatformPei on Xen: - GetFirstNonAddress(): controlling the 64-bit PCI MMIO aperture via the (experimental) "opt/ovmf/X-PciMmio64Mb" file - GetFirstNonAddress(): honoring the hotplug DIMM area ("etc/reserved-memory-end") in the placement of the 64-bit PCI MMIO aperture - NoexecDxeInitialization() is removed, so PcdPropertiesTableEnable and PcdSetNxForStack are left constant FALSE (not set dynamically from fw_cfg "opt/ovmf/PcdXxxx") - MaxCpuCountInitialization(), PublishPeiMemory(): the max CPU count is not taken from the QemuFwCfgItemSmpCpuCount fw_cfg key; PcdCpuMaxLogicalProcessorNumber is used intact and PcdCpuApInitTimeOutInMicroSeconds is never changed or used. - InitializeXenPlatform(), S3Verification(): S3 is assumed disabled (not consulting "etc/system-states" via QemuFwCfgS3Enabled()). - InstallFeatureControlCallback(): the feature control MSR is not set from "etc/msr_feature_control" (also removed FeatureControl.c as there is nothing been executed) Also removed: - SMRAM/TSEG-related low mem size adjusting (PcdSmmSmramRequire is assumed FALSE) in PublishPeiMemory(), - QemuInitializeRam() entirely, Xen related changes: - Have removed the module variable mXen, as it should be always true. - Have the platform PEI initialization fails if Xen has not been detected. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20190813113119.14804-5-anthony.perard@citrix.com>
* OvmfPkg: Introduce XenResetVectorAnthony PERARD2019-08-211-1/+1
| | | | | | | | | | | | | | | | | | | | Introduce XenResetVector, a copy of OvmfPkg/ResetVector, with one changes: - SEC_DEFAULT_CR0: enable cache (bit 30 or CD set to 0) Xen copies the OVMF code to RAM, there is no need to disable cache. This new module will later be modified to add a new entry point, more detail in a following commit "OvmfPkg/XenResetVector: Add new entry point for Xen PVH" Value FILE_GUID of XenResetVector have not changed compare to ResetVector because it is a special value (gEfiFirmwareVolumeTopFileGuid). Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20190813113119.14804-4-anthony.perard@citrix.com>
* OvmfPkg: Create platform OvmfXenAnthony PERARD2019-08-211-0/+729
OvmfXen is a copy of OvmfX64, removing VirtIO and some SMM. This new platform will be changed to make it works on two types of Xen guest: HVM and PVH. Compare to OvmfX64, this patch: - changed: PLATFORM_GUID, OUTPUT_DIRECTORY, FLASH_DEFINITION - removed: VirtioLib class resolution - removed: all UEFI_DRIVER modules for virtio devices - removed: DXE_SMM_DRIVER and SMM_CORE lib class resolutions - removed: DXE_SMM_DRIVER and SMM_CORE FDF rules - removed: Everything related to SMM_REQUIRE==true - removed: Everything related to SECURE_BOOT_ENABLE==true - removed: Everything related to TPM2_ENABLE==true - changed: PcdPciDisableBusEnumeration dynamic default flipped to TRUE - changed: default FD_SIZE_IN_KB to 2M. - reverted d272449d9e1e, "OvmfPkg: raise DXEFV size to 11 MB" Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20190813113119.14804-3-anthony.perard@citrix.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-02 21:47:55 +0000