summaryrefslogtreecommitdiff
path: root/OvmfPkg
AgeCommit message (Collapse)AuthorFilesLines
2019-11-15OvmfPkg DSC: Update tool chain name to CLANGPDBLiming Gao3-9/+9
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2341 Signed-off-by: Liming Gao <liming.gao@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2019-11-05OvmfPkg: Disable variable runtime cacheMichael Kubacki3-0/+3
Sets gEfiMdeModulePkgTokenSpaceGuid.PcdEnableVariableRuntimeCache to FALSE in OvmfPkgIa32.dsc, OvmfPkgIa32X64.dsc, and OvmfPkgX64.dsc so that when SMM_REQUIRE is TRUE, the SMM variable driver will not use the runtime variable cache. This is done for OvmfPkg because it currently depends upon a SMM variable GetVariable ()implementation as a simple method to exercise the SMM driver stack. This allows the following commands to be used for variables such as Boot####, BootOrder, and BootNext to test SMM timing and stability differences on the BSP (e.g. CPU#0) vs an AP (e.g. CPU#1). # taskset -c 0 efibootmgr # taskset -c 1 efibootmgr Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Signed-off-by: Michael Kubacki <michael.a.kubacki@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2019-10-24OvmfPkg: Enable CLANG9 tool chainLiming Gao3-3/+9
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1603 1. Apply CLANG9 Linker option. 2. Exclude -mno-mmx -mno-sse compiler option for CLANG9 These two options will cause CLANG Linker crush. Signed-off-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2019-10-22OvmfPkg: Make SOURCE_DEBUG_ENABLE actually need to be set to TRUEPeter Jones8-38/+42
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-10-16OvmfPkg/PlatformBootManagerLib: Don't update progress if Pcd is 0Pete Batard1-3/+12
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2266 Independently of how we decide to address other aspects of the regression introduced with commit 2de1f611be06ded3a59726a4052a9039be7d459b, it doesn't make much sense to call for a progress update if PcdPlatformBootTimeOut is zero. PcdPlatformBootTimeOut 0, which is the cause of the bug (division by zero) should be considered to indicate that a platform is not interested in displaying a progress report, so we alter PlatformBootManagerWaitCallback to behave that way. We also change one variable name to make the code more explicit. Signed-off-by: Pete Batard <pete@akeo.ie> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Message-Id: <20191014150311.16740-2-pete@akeo.ie>
2019-10-09OvmfPkg/PlatformDxe: fix EFI_HII_HANDLE parameters of internal functionsLaszlo Ersek1-2/+2
In the following call tree: PlatformInit () mInstalledPackages = HiiAddPackages () GopInstalled () PopulateForm (PackageList = mInstalledPackages) CreateResolutionOptions (PackageList) HiiSetString (PackageList HiiUpdateForm (PackageList) PlatformDxe passes around an EFI_HII_HANDLE that (a) originates from HiiAddPackages() and (b) is ultimately passed to HiiSetString() and HiiUpdateForm(). The intermediate functions PopulateForm() and CreateResolutionOptions() however take that parameter as an (EFI_HII_HANDLE*). There is no bug in practice (because the affected functions never try to de-reference the "PackageList" parameter, they just pass it on), but the function prototypes are semantically wrong. Fix that. This could remain hidden so long because pointer-to-VOID silently converts to/from any pointer-to-object type, and the UEFI spec mandates that EFI_HII_HANDLE be a typedef to (VOID*). Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2019-10-09OvmfPkg/VirtioNetDxe: fix SignalEvent() callLaszlo Ersek1-1/+1
The SignalEvent() boot service takes an EFI_EVENT, not an (EFI_EVENT*). Fix the call in the notification function of "EFI_SIMPLE_NETWORK_PROTOCOL.WaitForPacket". This is an actual bug. The reason it's never been triggered is likely that the "SNP.WaitForPacket" event is rarely waited for by applications -- edk2 itself has zero instances of that, for example. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2019-10-09OvmfPkg/XenBusDxe: fix UninstallMultipleProtocolInterfaces() callLaszlo Ersek1-1/+1
Unlike the InstallMultipleProtocolInterfaces() boot service, which takes an (EFI_HANDLE*) as first parameter, the UninstallMultipleProtocolInterfaces() boot service takes an EFI_HANDLE as first parameter. This is an actual bug. It must have remained hidden until now because it's on an error path. Fix the UninstallMultipleProtocolInterfaces() call. 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> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Julien Grall <julien.grall@arm.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
2019-10-04OvmfPkg: strip trailing whitespaceLeif Lindholm27-301/+301
Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Anthony Perard <anthony.perard@citrix.com> Cc: Julien Grall <julien.grall@arm.com> Cc: David Woodhouse <dwmw2@infradead.org> Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
2019-09-05OvmfPkg/EnrollDefaultKeys: clean up Base64Decode() retval handlingLaszlo Ersek1-8/+2
Since commit 35e242b698cd ("MdePkg/BaseLib: rewrite Base64Decode()", 2019-07-16), Base64Decode() guarantees that DestinationSize is larger on output than it was on input if RETURN_BUFFER_TOO_SMALL is returned. Clean up the retval handling for the first Base64Decode() call in EnrollDefaultKeys, which used to work around the ambiguity in the previous Base64Decode() interface contract. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1981 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2019-08-21OvmfPkg/OvmfXen: use RealTimeClockRuntimeDxe from EmbeddedPkgAnthony PERARD2-2/+3
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: Move XenRealTimeClockLib from ArmVirtPkgAnthony PERARD2-0/+223
Move XenRealTimeClockLib from ArmVirtPkg to OvmfPkg so it can be used from the OvmfPkg by the following patch, "OvmfPkg/OvmfXen: use RealTimeClockRuntimeDxe from EmbeddedPkg" 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-35-anthony.perard@citrix.com>
2019-08-21OvmfPkg: Introduce XenIoPvhDxe to initialize Grant TablesAnthony PERARD4-0/+93
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: Introduce PcdXenGrantFramesAnthony PERARD4-2/+8
Introduce PcdXenGrantFrames to replace a define in XenBusDxe and allow the same value to be used in a different module. The reason for the number of page to be 4 doesn't exist anymore, so simply remove the comment. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20190813113119.14804-33-anthony.perard@citrix.com>
2019-08-21OvmfPkg/PlatformBootManagerLib: Use a Xen console for ConOut/ConInAnthony PERARD6-4/+58
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 PERARD5-4/+576
"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/PlatformBootManagerLib: Handle the absence of PCI bus on Xen PVHAnthony PERARD1-0/+6
When running in a Xen PVH guest, there's nothing to do in PciAcpiInitialization() because there isn't any PCI bus. When the Host Bridge DID isn't recognised, simply continue. (The value of PcdOvmfHostBridgePciDevId would be 0 because it isn't set.) 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-29-anthony.perard@citrix.com>
2019-08-21OvmfPkg/PlatformBootManagerLib: Use XenDetected from XenPlatformLibAnthony PERARD2-34/+2
Replace the XenDetected() implementation by the one from XenPlatformLib. 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-28-anthony.perard@citrix.com>
2019-08-21OvmfPkg/XenPlatformLib: Cache result for XenDetectedAnthony PERARD1-4/+16
We are going to replace XenDetected() implementation in PlatformBootManagerLib by the one in XenPlatformLib. PlatformBootManagerLib's implementation does cache the result of GetFirstGuidHob(), so we do something similar in XenPlatformLib. 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-27-anthony.perard@citrix.com>
2019-08-21OvmfPkg/XenPlatformPei: Ignore missing PCI Host Bridge on Xen PVHAnthony PERARD1-0/+6
When the device ID of the host bridge is unknown, check if we are running as a PVH guest as there is no PCI bus in that case. 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-26-anthony.perard@citrix.com>
2019-08-21OvmfPkg/XenPlatformPei: Reserve VGA memory region, to boot LinuxAnthony PERARD1-0/+16
Linux panic if the VGA region isn't reserved. When Linux is booted on EFI system, it expects the memory at 0xa0000 to _not_ be conventional memory. Otherwise a variable isn't initialised properly and Linux panic when a virtual console/terminal is asked to be created. See for more detail: https://lists.xenproject.org/archives/html/xen-devel/2019-03/msg02139.html 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-25-anthony.perard@citrix.com>
2019-08-21OvmfPkg/XenPlatformPei: Rework memory detectionAnthony PERARD4-22/+148
When running as a Xen PVH guest, there is no CMOS to read the memory size from. Rework GetSystemMemorySize(Below|Above)4gb() so they can work without CMOS by reading the e820 table. Rework XenPublishRamRegions to also care for the reserved and ACPI entry in the e820 table. The region that was added by InitializeXen() isn't needed as that same entry is in the e820 table provided by hvmloader. MTRR settings aren't modified anymore, on HVM it's already done by hvmloader, on PVH it is supposed to have sane default. MTRR will need to be done properly but keeping what's already been done by programs that have run before OVMF will do for now. 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-24-anthony.perard@citrix.com>
2019-08-21OvmfPkg/XenPlatformPei: no hvmloader: get the E820 table via hypercallAnthony PERARD1-1/+45
When the Xen PVH entry point has been used, hvmloader hasn't run and hasn't prepared an E820 table. The only way left to get an E820 table is to ask Xen via an hypercall. We keep the result cached to avoid making a second hypercall which would give the same result. 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-23-anthony.perard@citrix.com>
2019-08-21OvmfPkg: Import XENMEM_memory_map hypercall to Xen/memory.hAnthony PERARD1-0/+23
The informations to make a XENMEM_memory_map hypercall is copied over from the public header of the Xen Project, with the type name modified to build on OVMF. 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-22-anthony.perard@citrix.com>
2019-08-21OvmfPkg/XenPlatformPei: Introduce XenPvhDetectedAnthony PERARD2-0/+18
XenPvhDetected() can be used to figure out if OVMF has started via the Xen PVH entry point. 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-21-anthony.perard@citrix.com>
2019-08-21OvmfPkg/XenPlatformPei: Setup HyperPages earlierAnthony PERARD3-11/+19
We are going to need to make an hypercall in order to retreive the E820 table from the hypervisor before been able to setup the memory. Calling XenConnect earlier will allow to setup the XenHypercallLib earlier to allow to make hypercalls. While here, add some comments in XenConnect(). 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-20-anthony.perard@citrix.com>
2019-08-21OvmfPkg/XenPlatformPei: Introduce XenHvmloaderDetectedAnthony PERARD2-0/+12
This new XenHvmloaderDetected() return true if the hvmloader firmware has runned before OVMF. 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-19-anthony.perard@citrix.com>
2019-08-21OvmfPkg/XenPlatformPei: Reinit XenHypercallLibAnthony PERARD2-0/+10
The XenPlatformPei needs to make hypercalls, but the XenHypercallLib was initialised before the HyperPage was ready. Now that XenPlatformPei has initialised the HyperPage, reinitialise the XenHypercallLib. 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-18-anthony.perard@citrix.com>
2019-08-21OvmfPkg/XenHypercallLib: Enable it in PEIMAnthony PERARD4-9/+31
Allow to use Xen hypercalls earlier, during the PEIM stage, but XenHypercallLibInit() must be called once the XenInfo HOB is created with the HyperPage setup. Change the return value of XenHypercallLibInit so failure can be detected when the call shouldn't fail, but still have the constructor always succeed. 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-17-anthony.perard@citrix.com>
2019-08-21OvmfPkg/AcpiPlatformDxe: Use Xen PVH RSDP if it existAnthony PERARD1-0/+17
If the firmware have been started via the Xen PVH entry point, a RSDP pointer would have been provided. Use it. 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-16-anthony.perard@citrix.com>
2019-08-21OvmfPkg/AcpiPlatformDxe: Use XenPlatformLibAnthony PERARD6-31/+5
This patch replace the XenDetected() function by the one in XenPlatformLib. 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-15-anthony.perard@citrix.com>
2019-08-21OvmfPkg/Library/XenPlatformLib: New libraryAnthony PERARD5-0/+160
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/XenPlatformPei: Grab RSDP from PVH guest start of day structAnthony PERARD4-0/+175
Check if there's a start of the day struct provided to PVH guest, save the ACPI RSDP address for later. This patch import import arch-x86/hvm/start_info.h from xen.git. 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-13-anthony.perard@citrix.com>
2019-08-21OvmfPkg/XenPlatformPei: Use mXenHvmloaderInfo to get E820Anthony PERARD1-9/+9
Use the already checked pointer mXenHvmloaderInfo to retrieve the E820 table produced by hvmloader. 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-12-anthony.perard@citrix.com>
2019-08-21OvmfPkg/XenPlatformPei: Detect OVMF_INFO from hvmloaderAnthony PERARD3-9/+23
EFI_XEN_OVMF_INFO is only useful to retrieve the E820 table. The mXenHvmloaderInfo isn't used yet, but will be use in a further patch to retrieve the E820 table. Also remove the unused pointer from the XenInfo HOB as that information is only useful in the XenPlatformPei. 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-11-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/XenResetVector: Allow jumpstart from either hvmloader or PVHAnthony PERARD4-7/+194
This patch allows the ResetVector to be run indenpendently from build time addresses. The goal of the patch is to avoid having to create RAM just below 4G when creating a Xen PVH guest while being compatible with the way hvmloader currently load OVMF, just below 4G. Only the new PVH entry point will do the calculation. The ResetVector will figure out its current running address by creating a temporary stack, make a call and calculate the difference between the build time address and the address at run time. This patch copies and make the necessary modification to some other asm files: - copy of UefiCpuPkg/.../Flat32ToFlat64.asm: Allow Transition32FlatTo64Flat to be run from anywhere in memory - copy of UefiCpuPkg/../SearchForBfvBase.asm: Add a extra parameter to indicate where to start the search for the boot firmware volume. 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-9-anthony.perard@citrix.com>
2019-08-21OvmfPkg/XenResetVector: Saving start of day pointer for PVH guestsAnthony PERARD5-0/+18
As described in the Xen PVH documentation [1], "ebx: contains the physical memory address where the loader has placed the boot start info structure". To have this pointer saved to be able to use it later in the PEI phase, we allocate some space in the MEMFD for it. We use 'XPVH' as a signature (for "Xen PVH"). [1] https://xenbits.xenproject.org/docs/unstable/misc/pvh.html 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-8-anthony.perard@citrix.com>
2019-08-21OvmfPkg/XenResetVector: Add new entry point for Xen PVHAnthony PERARD3-0/+129
Add a new entry point for Xen PVH that enter directly in 32bits. Information on the expected state of the machine when this entry point is used can be found at: https://xenbits.xenproject.org/docs/unstable/misc/pvh.html Also, compare to the original file [1], the two `nop' of the "resetVector" entry point are removed. There were introduced by 8332983e2e33 ("UefiCpuPkg: Replace the un-necessary WBINVD instruction at the reset vector with two NOPs in VTF0.", 2011-08-04), but don't seems to be useful. This is the entry point used by HVM guest (hvmloader). [1] UefiCpuPkg/ResetVector/Vtf0/Ia16/ResetVectorVtf0.asm 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-7-anthony.perard@citrix.com>
2019-08-21OvmfPkg/OvmfXen: Creating an ELF headerAnthony PERARD2-3/+238
This patch changes the flash device image of OvmfXen to make it look like it's an ELF. For this, we replace the empty embedded variable store by a binary array, which is a ELF file header. The ELF header explain to a loader to load the binary at the address 1MB, then jump to the PVH entry point which will be created in a later patch. The header also includes a Xen ELF note that is part of the PVH ABI. That patch include OvmfXenElfHeaderGenerator.c which can be use to regenerate the ELF header, but this will be a manual step. 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-6-anthony.perard@citrix.com>
2019-08-21OvmfPkg: Introduce XenPlatformPeiAnthony PERARD13-2/+1693
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 PERARD6-2/+391
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 PERARD2-0/+1168
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>
2019-08-21OvmfPkg/ResetSystemLib: Add missing dependency on PciLibAnthony PERARD2-2/+2
Add missing dependency on PciLib and remove extra includes of OvmfPlatforms.h. Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20190813113119.14804-2-anthony.perard@citrix.com>
2019-08-09OvmfPkg/PlatformPei: Change referenced MSR name.Eric Dong1-2/+2
Change referenced MSR name to avoid later build failure. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2019-07-29OvmfPkg/build.sh: use newer '-drive if=pflash' syntax when running qemuRebecca Cran1-1/+1
Specify the firmware to use via the newer '-drive if=pflash' syntax which allows specifying the raw format parameter. This avoids warnings with newer version of QEMU. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
2019-07-29OvmfPkg/build.sh: remove $ADD_QEMU_HDARebecca Cran1-14/+0
$ADD_QEMU_HDA was added because QEMU used to refuse to run without a disk. Since newer versions run without any disks, remove it. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
2019-07-24OvmfPkg/build.sh: remove literal carriage returnrebecca@bsdio.com1-1/+1
Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2019-07-23OvmfPkg/build.sh: enable multitheaded build by defaultRebecca Cran1-1/+1
Enable multithreaded builds by default when building OvmfPkg using build.sh. This can drastically reduce build times. For example, on a modern ThreadRipper system the time required to build decreases from 3 minutes to 1 minute. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
generated by cgit v1.1 at 2024-08-15 09:36:02 +0000