summaryrefslogtreecommitdiff
path: root/OvmfPkg/OvmfXen.dsc
AgeCommit message (Collapse)AuthorFilesLines
2020-04-28OvmfPkg/OvmfXen: Introduce DEBUG_ON_HYPERVISOR_CONSOLE build flagAnthony PERARD1-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>
2020-04-28OvmfPkg/OvmfXen: Remove DEBUG_ON_SERIAL_PORTAnthony PERARD1-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>
2020-04-22OvmfPkg/ResetSystemLib: introduce the DxeResetSystemLib instanceLaszlo Ersek1-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]
2020-04-22OvmfPkg/ResetSystemLib: rename to BaseResetSystemLibLaszlo Ersek1-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>
2020-04-07OvmfPkg: remove handling of properties tableArd Biesheuvel1-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>
2020-04-01OvmfPkg: Fix SMM/RT driver section alignment for XCODE5/CLANGPDBVitaly Cheptsov1-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]
2020-03-06OvmfPkg/OvmfXen: fix build by providing QemuLoadImageLib resolutionArd Biesheuvel1-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>
2020-03-04OvmfPkg: add the 'initrd' dynamic shell commandArd Biesheuvel1-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>
2020-02-05OvmfPkg: introduce PcdCsmEnable feature flagLaszlo Ersek1-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>
2020-01-29OvmfPkg/OvmfXen.dsc: remove PcdCpu* dynamic defaultsLaszlo Ersek1-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>
2019-10-22OvmfPkg: Make SOURCE_DEBUG_ENABLE actually need to be set to TRUEPeter Jones1-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>
2019-08-21OvmfPkg/OvmfXen: use RealTimeClockRuntimeDxe from EmbeddedPkgAnthony PERARD1-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>
2019-08-21OvmfPkg: Introduce XenIoPvhDxe to initialize Grant TablesAnthony PERARD1-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>
2019-08-21OvmfPkg/PlatformBootManagerLib: Use a Xen console for ConOut/ConInAnthony PERARD1-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>
2019-08-21OvmfPkg/OvmfXen: Introduce XenTimerDxeAnthony PERARD1-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>
2019-08-21OvmfPkg/OvmfXen: Override PcdFSBClock to Xen vLAPIC timer frequencyAnthony PERARD1-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>
2019-08-21OvmfPkg/Library/XenPlatformLib: New libraryAnthony PERARD1-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>
2019-08-21OvmfPkg/OvmfXen: use a TimerLib instance that depends only on the CPUAnthony PERARD1-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>
2019-08-21OvmfPkg: Introduce XenPlatformPeiAnthony PERARD1-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>
2019-08-21OvmfPkg: Introduce XenResetVectorAnthony PERARD1-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>
2019-08-21OvmfPkg: Create platform OvmfXenAnthony PERARD1-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.1 at 2024-09-07 19:41:19 +0000