summaryrefslogtreecommitdiffstats
path: root/OvmfPkg
Commit message (Collapse)AuthorAgeFilesLines
* OvmfPkg: strip trailing whitespaceLeif Lindholm2019-10-0427-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>
* OvmfPkg/EnrollDefaultKeys: clean up Base64Decode() retval handlingLaszlo Ersek2019-09-051-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>
* OvmfPkg/OvmfXen: use RealTimeClockRuntimeDxe from EmbeddedPkgAnthony PERARD2019-08-212-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>
* OvmfPkg: Move XenRealTimeClockLib from ArmVirtPkgAnthony PERARD2019-08-212-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>
* OvmfPkg: Introduce XenIoPvhDxe to initialize Grant TablesAnthony PERARD2019-08-214-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>
* OvmfPkg: Introduce PcdXenGrantFramesAnthony PERARD2019-08-214-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>
* OvmfPkg/PlatformBootManagerLib: Use a Xen console for ConOut/ConInAnthony PERARD2019-08-216-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>
* OvmfPkg/OvmfXen: Introduce XenTimerDxeAnthony PERARD2019-08-215-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>
* 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/PlatformBootManagerLib: Handle the absence of PCI bus on Xen PVHAnthony PERARD2019-08-211-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>
* OvmfPkg/PlatformBootManagerLib: Use XenDetected from XenPlatformLibAnthony PERARD2019-08-212-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>
* OvmfPkg/XenPlatformLib: Cache result for XenDetectedAnthony PERARD2019-08-211-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>
* OvmfPkg/XenPlatformPei: Ignore missing PCI Host Bridge on Xen PVHAnthony PERARD2019-08-211-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>
* OvmfPkg/XenPlatformPei: Reserve VGA memory region, to boot LinuxAnthony PERARD2019-08-211-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>
* OvmfPkg/XenPlatformPei: Rework memory detectionAnthony PERARD2019-08-214-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>
* OvmfPkg/XenPlatformPei: no hvmloader: get the E820 table via hypercallAnthony PERARD2019-08-211-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>
* OvmfPkg: Import XENMEM_memory_map hypercall to Xen/memory.hAnthony PERARD2019-08-211-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>
* OvmfPkg/XenPlatformPei: Introduce XenPvhDetectedAnthony PERARD2019-08-212-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>
* OvmfPkg/XenPlatformPei: Setup HyperPages earlierAnthony PERARD2019-08-213-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>
* OvmfPkg/XenPlatformPei: Introduce XenHvmloaderDetectedAnthony PERARD2019-08-212-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>
* OvmfPkg/XenPlatformPei: Reinit XenHypercallLibAnthony PERARD2019-08-212-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>
* OvmfPkg/XenHypercallLib: Enable it in PEIMAnthony PERARD2019-08-214-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>
* OvmfPkg/AcpiPlatformDxe: Use Xen PVH RSDP if it existAnthony PERARD2019-08-211-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>
* OvmfPkg/AcpiPlatformDxe: Use XenPlatformLibAnthony PERARD2019-08-216-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>
* OvmfPkg/Library/XenPlatformLib: New libraryAnthony PERARD2019-08-215-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>
* OvmfPkg/XenPlatformPei: Grab RSDP from PVH guest start of day structAnthony PERARD2019-08-214-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>
* OvmfPkg/XenPlatformPei: Use mXenHvmloaderInfo to get E820Anthony PERARD2019-08-211-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>
* OvmfPkg/XenPlatformPei: Detect OVMF_INFO from hvmloaderAnthony PERARD2019-08-213-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>
* 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/XenResetVector: Allow jumpstart from either hvmloader or PVHAnthony PERARD2019-08-214-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>
* OvmfPkg/XenResetVector: Saving start of day pointer for PVH guestsAnthony PERARD2019-08-215-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>
* OvmfPkg/XenResetVector: Add new entry point for Xen PVHAnthony PERARD2019-08-213-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>
* OvmfPkg/OvmfXen: Creating an ELF headerAnthony PERARD2019-08-212-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>
* OvmfPkg: Introduce XenPlatformPeiAnthony PERARD2019-08-2113-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>
* OvmfPkg: Introduce XenResetVectorAnthony PERARD2019-08-216-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>
* OvmfPkg: Create platform OvmfXenAnthony PERARD2019-08-212-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>
* OvmfPkg/ResetSystemLib: Add missing dependency on PciLibAnthony PERARD2019-08-212-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>
* OvmfPkg/PlatformPei: Change referenced MSR name.Eric Dong2019-08-091-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>
* OvmfPkg/build.sh: use newer '-drive if=pflash' syntax when running qemuRebecca Cran2019-07-291-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>
* OvmfPkg/build.sh: remove $ADD_QEMU_HDARebecca Cran2019-07-291-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>
* OvmfPkg/build.sh: remove literal carriage returnrebecca@bsdio.com2019-07-241-1/+1
| | | | | Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg/build.sh: enable multitheaded build by defaultRebecca Cran2019-07-231-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>
* OvmfPkg: link SM3 support into Tcg2Pei and Tcg2DxeImran Desai2019-07-193-0/+6
| | | | | | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1781 GITHUB: https://github.com/idesai/edk2/tree/enable_sm3_measured_boot_v6 EDK2 Support for SM3 digest algorithm is needed to enable TPM with SM3 PCR banks. This digest algorithm is part of the China Crypto algorithm suite. This integration has dependency on the openssl_1_1_1b integration into edk2. This patch links SM3 support into Tcg2Pei and Tcg2Dxe. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Cc: Stefan Berger <stefanb@linux.ibm.com> Signed-off-by: Imran Desai <imran.desai@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20190718225326.40839-5-imran.desai@intel.com> Acked-by: Jiewen Yao <jiewen.yao@intel.com>
* Revert "OvmfPkg: link SM3 support into Tcg2Pei and Tcg2Dxe"Laszlo Ersek2019-07-043-6/+0
| | | | | | | | | | | | | | | | | | This reverts commit a7c7d21ffa9ad14b418e728a882df0a9b8815bf6. The reason is that said commit had not been reviewed by OvmfPkg maintainers/reviewers, before it was pushed. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Imran Desai <imran.desai@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Leif Lindholm <leif.lindholm@linaro.org> Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Cc: Stefan Berger <stefanb@linux.ibm.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1781 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
* OvmfPkg: use DxeTpmMeasurementLib if and only if TPM2_ENABLEGary Lin2019-07-043-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (a) OvmfPkg first had to resolve the TpmMeasurementLib class -- for SECURE_BOOT_ENABLE only -- when the DxeImageVerificationLib instance became dependent on TpmMeasurementLib. For details, refer to commit 0d28d286bf4d ("OvmfPkg: resolve TpmMeasurementLib dependency introduced in r14687", 2013-09-21). (b) At the time, only one instance of TpmMeasurementLib existed, namely DxeTpmMeasurementLib. This lib instance didn't do anything -- like it was desirable for OVMF --, because OVMF didn't include any Tcg / TrEE protocol implementations. (c) In commit 308521b13354 ("MdeModulePkg: Move TpmMeasurementLib LibraryClass from SecurityPkg", 2015-07-01), TpmMeasurementLibNull was introduced. (d) In commit 285542ebbb03 ("OvmfPkg: Link AuthVariableLib for following merged variable driver deploy", 2015-07-01), a TpmMeasurementLib resolution became necessary regardless of SECURE_BOOT_ENABLE. And so TpmMeasurementLib was resolved to TpmMeasurementLibNull in OVMF, but only in the non-SECURE_BOOT_ENABLE case. This step -- possibly, the larger series containing commit 285542ebbb03 -- missed an opportunity for simplification: given (b), the DxeTpmMeasurementLib instance should have been simply replaced with the TpmMeasurementLibNull instance, regardless of SECURE_BOOT_ENABLE. (e) In commit 1abfa4ce4835 ("Add TPM2 support defined in trusted computing group.", 2015-08-13), the TrEE dependency was replaced with a Tcg2 dependency in DxeTpmMeasurementLib. (f) Starting with commit 0c0a50d6b3ff ("OvmfPkg: include Tcg2Dxe module", 2018-03-09), OVMF would include a Tcg2 protocol implementation, thereby satisfying DxeTpmMeasurementLib's dependency. With TPM2_ENABLE, it would actually make sense to consume DxeTpmMeasurementLib -- however, DxeTpmMeasurementLib would never be used without SECURE_BOOT_ENABLE. Therefore, we have the following four scenarios: - TPM2_ENABLE + SECURE_BOOT_ENABLE: works as expected. - Neither enabled: works as expected. - Only TPM2_ENABLE: this build is currently incorrect, because Variable/RuntimeDxe consumes TpmMeasurementLib directly, but TpmMeasureAndLogData() will never reach the TPM because we link TpmMeasurementLibNull into the variable driver. This is a problem from the larger series containing (f). - Only SECURE_BOOT_ENABLE: this build works as expected, but it is wasteful -- given that the protocol database will never contain Tcg2 without TPM2_ENABLE, we should simply use TpmMeasurementLibNull. This is a problem from (d). Resolving TpmMeasurementLib to DxeTpmMeasurementLib as a function of *only* TPM2_ENABLE, we can fix / optimize the last two cases. v2: - Amend the title and description suggested by Laszlo - Move TpmMeasurementLib to the existed TPM2_ENABLE block Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Cc: Stefan Berger <stefanb@linux.ibm.com> Signed-off-by: Gary Lin <glin@suse.com> Message-Id: <20190704040731.5303-1-glin@suse.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: link SM3 support into Tcg2Pei and Tcg2DxeImran Desai2019-07-033-0/+6
| | | | | | | | | | | | | | | | | | | BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1781 EDK2 Support for SM3 digest algorithm is needed to enable TPM with SM3 PCR banks. This digest algorithm is part of the China Crypto algorithm suite. This integration has dependency on the openssl_1_1_1b integration into edk2. This patch links SM3 support into Tcg2Pei and Tcg2Dxe. Signed-off-by: Imran Desai <imran.desai@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Cc: Stefan Berger <stefanb@linux.ibm.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: jiewen.yao@intel.com
* OvmfPkg/XenBusDxe: Don't call DisconnectController in Stop()Anthony PERARD2019-07-011-6/+0
| | | | | | | | | | | | Calling DisconnectController() on children isn't part of the job of EFI_DRIVER_BINDING_PROTOCOL.Stop() as it only needs to deallocate resources allocated in Start(). The disconnection will happen when both DevicePath and XenBus protocols gets uninstalled. Reported-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Message-Id: <20190701111403.7007-1-anthony.perard@citrix.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/XenBusDxe: Close XenIoProtocol openned by childrenAnthony PERARD2019-07-011-0/+4
| | | | | | | | | | | | In XenBusDxe, the XenBusAddDevice() opens the gXenIoProtocolGuid on behalf of child controllers. It is never closed and prevents us from uninstalling the protocol. Close it where we stop all the children in XenBusDxe->Stop(). Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20190701105012.25758-1-anthony.perard@citrix.com>
* OvmfPkg: don't assign PCI BARs above 4GiB when CSM enabledDavid Woodhouse2019-06-262-0/+8
| | | | | | | | | | | | | | | | | | | | Mostly, this is only necessary for devices that the CSM might have native support for, such as VirtIO and NVMe; PciBusDxe will already degrade devices to 32-bit if they have an OpROM. However, there doesn't seem to be a generic way of requesting PciBusDxe to downgrade specific devices. There's IncompatiblePciDeviceSupportProtocol but that doesn't provide the PCI class information or a handle to the device itself, so there's no simple way to just match on all NVMe devices, for example. Just leave gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Size set to zero for CSM builds, until/unless that can be fixed. Signed-off-by: David Woodhouse <dwmw2@infradead.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20190626113742.819933-5-dwmw2@infradead.org>
* OvmfPkg: Don't build in QemuVideoDxe when we have CSMDavid Woodhouse2019-06-266-3/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | QemuVideoDxe installs its own legacy INT 10h handler for the benefit of systems like Windows 2008r2 which attempt to use INT 10h even when booted via EFI. This interacts extremely badly with a CSM actually attempting to install a real video BIOS. The last thing done before invoking a legacy OpROM is to call INT 10h to set a plain text mode. In the case where it's the video BIOS OpROM being loaded, INT 10h will normally point to an iret stub in the CSM itself. Unless QemuVideoDxe has changed INT10h to point to a location in the 0xC0000 segment that it didn't allocate properly, so the real OpROM has been shadowed over them top of it, and the INT 10h vector now points to some random place in the middle of the newly-shadowed OpROM. Don't Do That Then. QemuVideoDxe doesn't do any acceleration and just sets up a linear framebuffer, so we don't lose much by just unconditionally using BiosVideoDxe instead when CSM is present. Signed-off-by: David Woodhouse <dwmw2@infradead.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20190626113742.819933-4-dwmw2@infradead.org>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-02 06:29:45 +0000