summaryrefslogtreecommitdiffstats
path: root/OvmfPkg/Include
Commit message (Collapse)AuthorAgeFilesLines
...
* OvmfPkg/LsiScsiDxe: Probe PCI devices and look for LsiScsiGary Lin2020-07-171-0/+20
| | | | | | | | | | | | Implement LsiScsiControllerSupported() to probe the PCI ID and look for LSI 53C895A. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Signed-off-by: Gary Lin <glin@suse.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200717061130.8881-5-glin@suse.com>
* OvmfPkg/MptScsiDxe: Implement the PassThru methodNikita Leshenko2020-05-051-0/+9
| | | | | | | | | | | | Machines should be able to boot after this commit. Tested with different Linux distributions (Ubuntu, CentOS) and different Windows versions (Windows 7, Windows 10, Server 2016). Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2390 Signed-off-by: Nikita Leshenko <nikita.leshchenko@oracle.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200504210607.144434-12-nikita.leshchenko@oracle.com> [lersek@redhat.com: MPT_SCSI_DMA_ADDR_HIGH: drop redundant space char]
* OvmfPkg/MptScsiDxe: Initialize hardwareNikita Leshenko2020-05-051-0/+128
| | | | | | | | | | | | | | Reset and send the IO controller initialization request. The reply is read back to complete the doorbell function but it isn't useful to us because it doesn't contain relevant data or status codes. See "LSI53C1030 PCI-X to Dual Channel Ultra320 SCSI Multifunction Controller" technical manual for more information. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2390 Signed-off-by: Nikita Leshenko <nikita.leshchenko@oracle.com> Message-Id: <20200504210607.144434-11-nikita.leshchenko@oracle.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/MptScsiDxe: Probe PCI devices and look for MptScsiNikita Leshenko2020-05-051-0/+23
| | | | | | | | | | | | | The MptScsiControllerSupported function is called on handles passed in by the ConnectController() boot service and if the handle is the lsi53c1030 controller the function would return success. A successful return value will attach our driver to the device. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2390 Signed-off-by: Nikita Leshenko <nikita.leshchenko@oracle.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Liran Alon <liran.alon@oracle.com> Message-Id: <20200504210607.144434-5-nikita.leshchenko@oracle.com>
* OvmfPkg: Add BaseResetSystemLibBhyveRebecca Cran2020-05-051-0/+2
| | | | | | | | | | | | | | | Introduce BaseResetSystemLibBhyve.inf, to support powering off bhyve guests. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Message-Id: <20200504021853.76658-1-rebecca@bsdio.com> [lersek@redhat.com: MODULE_TYPE: replace DXE_DRIVER with BASE] [lersek@redhat.com: replace <OvmfPlatforms.h> with <IndustryStandard/Bhyve.h>] [lersek@redhat.com: strip ".inf" from subject line] Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Add VBE2 mode info structure to LegacyVgaBios.hRebecca Cran2020-04-301-0/+38
| | | | | | | | | | | | bhyve uses the older VESA BIOS Extensions 2.0, so add the mode info structure to IndustryStandard/LegacyVgaBios.h Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Message-Id: <20200430011503.613044-1-rebecca@bsdio.com>
* OvmfPkg: Add bhyve support into AcpiTimerLibRebecca Cran2020-04-302-0/+17
| | | | | | | | | | | | | On bhyve, the ACPI timer is located at a fixed IO address; it need not be programmed into, nor fetched from, the PMBA -- power management base address -- register of the PCI host bridge. Signed-off-by: Rebecca Cran <rebecca@bsdio.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Message-Id: <20200430011212.612386-1-rebecca@bsdio.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: introduce QemuFwCfgSimpleParserLibLaszlo Ersek2020-04-281-0/+128
| | | | | | | | | | | | | | | | We already parse some boolean and integer values from named fw_cfg files (usually into PCDs), and we're going to cover more. Add a dedicated library for centralizing the parsing logic. Cc: Ard Biesheuvel <ard.biesheuvel@arm.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Per Sundstrom <per_sundstrom@yahoo.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2681 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200424075353.8489-2-lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
* OvmfPkg/PvScsiDxe: Define device interface structures and constantsLiran Alon2020-03-301-0/+165
| | | | | | | | | | | These definitions will be used by the following commits to complete the implementation of PVSCSI device driver. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2567 Acked-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Liran Alon <liran.alon@oracle.com> Message-Id: <20200328200100.60786-12-liran.alon@oracle.com> Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
* OvmfPkg/PvScsiDxe: Probe PCI devices and look for PvScsiLiran Alon2020-03-301-0/+21
| | | | | | | | | | | | | PvScsiControllerSupported() is called on handles passed in by the ConnectController() boot service and if the handle is the PVSCSI controller, the function would return success. A success return value will attach our driver to the device. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2567 Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Liran Alon <liran.alon@oracle.com> Message-Id: <20200328200100.60786-5-liran.alon@oracle.com> Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
* OvmfPkg: create protocol and GUID header for loaded x86 Linux kernelsArd Biesheuvel2020-03-051-0/+32
| | | | | | | | | | In preparation of moving the legacy x86 loading to an implementation of the QEMU load image library class, introduce a protocol header and GUID that we will use to identify legacy loaded x86 Linux kernels in the protocol database. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: introduce QemuLoadImageLib library classArd Biesheuvel2020-03-051-0/+84
| | | | | | | | | | Introduce the QemuLoadImageLib library class that we will instantiate to load the kernel image passed via the QEMU command line using the standard LoadImage boot service. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2566 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: add GUID for the QEMU kernel loader fs media device pathArd Biesheuvel2020-03-051-0/+18
| | | | | | | | | | | | | | | In an upcoming patch, we will introduce a separate DXE driver that exposes the virtual SimpleFileSystem implementation that carries the kernel and initrd passed via the QEMU command line, and a separate library that consumes it, to be incorporated into the boot manager. Since the GUID used for the SimpleFileSystem implementation's device path will no longer be for internal use only, create a well defined GUID to identify the media device path. Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2566 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/CpuHotplugSmm: add function for collecting CPUs with eventsLaszlo Ersek2020-03-041-0/+2
| | | | | | | | | | | | | | | | | | | | | Add a function that collects the APIC IDs of CPUs that have just been hot-plugged, or are about to be hot-unplugged. Pending events are only located and never cleared; QEMU's AML needs the firmware to leave the status bits intact in the hotplug register block. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200226221156.29589-10-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
* OvmfPkg/CpuHotplugSmm: define the QEMU_CPUHP_CMD_GET_ARCH_ID macroLaszlo Ersek2020-03-041-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | QEMU commit 3a61c8db9d25 ("acpi: cpuhp: add CPHP_GET_CPU_ID_CMD command", 2020-01-22) introduced a new command in the modern CPU hotplug register block that lets the firmware query the arch-specific IDs (on IA32/X64: the APIC IDs) of CPUs. Add a macro for this command value, because we'll need it later. At the same time, add a sanity check for the modern hotplug interface to CpuHotplugSmm. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200226221156.29589-9-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
* OvmfPkg/CpuHotplugSmm: introduce skeleton for CPU Hotplug SMM driverLaszlo Ersek2020-03-041-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | Add a new SMM driver skeleton that registers a root SMI handler, and checks if the SMI control value (written to 0xB2) indicates a CPU hotplug SMI. QEMU's ACPI payload will cause the OS to raise a broadcast SMI when a CPU hotplug event occurs, namely by writing value 4 to IO Port 0xB2. In other words, control value 4 is now allocated for this purpose; introduce the ICH9_APM_CNT_CPU_HOTPLUG macro for it. The standard identifiers in this driver use the new MM (Management Mode) terminology from the PI spec, not the earlier SMM (System Management Mode) terms. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200226221156.29589-7-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
* OvmfPkg: add definition of LINUX_EFI_INITRD_MEDIA_GUIDArd Biesheuvel2020-03-041-0/+17
| | | | | | | | | | Add LINUX_EFI_INITRD_MEDIA_GUID to our collection of GUID definitions, it can be used in a media device path to specify a Linux style initrd that can be loaded by the OS using the LoadFile2 protocol. 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/Xen: Fix various typosAntoine Coeur2020-02-105-7/+7
| | | | | | | | | | | | | | | | Fix various typos in comments and documentation. 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@xen.org> Signed-off-by: Antoine Coeur <coeur@gmx.fr> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Acked-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com> Message-Id: <20200207010831.9046-61-philmd@redhat.com>
* OvmfPkg/Virtio: Fix few typosAntoine Coeur2020-02-101-1/+1
| | | | | | | | | | | | | Fix few typos in comments and documentation. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Antoine Coeur <coeur@gmx.fr> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com> Message-Id: <20200207010831.9046-59-philmd@redhat.com>
* OvmfPkg/IndustryStandard: add MCH_DEFAULT_SMBASE* register macrosLaszlo Ersek2020-02-051-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In Intel datasheet 316966-002 (the "q35 spec"), Table 5-1 "DRAM Controller Register Address Map (D0:F0)" leaves the byte register at config space offset 0x9C unused. On QEMU's Q35 board, for detecting the "SMRAM at default SMBASE" feature, firmware is expected to write MCH_DEFAULT_SMBASE_QUERY (0xFF) to offset MCH_DEFAULT_SMBASE_CTL (0x9C), and read back the register. If the value is MCH_DEFAULT_SMBASE_IN_RAM (0x01), then the feature is available, and the range mentioned below is open (accessible to code running outside of SMM). Then, once firmware writes MCH_DEFAULT_SMBASE_LCK (0x02) to the register, the MCH_DEFAULT_SMBASE_SIZE (128KB) range at 0x3_0000 (SMM_DEFAULT_SMBASE) gets closed and locked down, and the register becomes read-only. The area is reopened, and the register becomes read/write, at platform reset. Add the above-listed macros to "Q35MchIch9.h". (There are some other unused offsets in Table 5-1; for example we had scavenged 0x50 for implementing the extended TSEG feature. 0x9C is the first byte-wide register standing in isolation after 0x50.) Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Message-Id: <20200129214412.2361-4-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg/IndustryStandard: increase vertical whitespace in Q35 macro defsLaszlo Ersek2020-02-051-50/+50
| | | | | | | | | | | | | | | | | In a subsequent patch, we'll introduce new DRAM controller macros in "Q35MchIch9.h". Their names are too long for the currently available vertical whitespace, so increase the latter first. There is no functional change in this patch ("git show -b" displays nothing). Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Message-Id: <20200129214412.2361-3-lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg/IndustryStandard: define macros for QEMU's CPU hotplug registersLaszlo Ersek2020-01-293-0/+50
| | | | | | | | | | | | | | | | | | | | | | | | | In v1.5.0, QEMU's "pc" (i440fx) board gained a "CPU present bitmap" register block. In v2.0.0, this was extended to the "q35" board. In v2.7.0, a new (read/write) register interface was laid over the "CPU present bitmap", with an option for the guest to switch the register block to the new (a.k.a. modern) interface. Both interfaces are documented in "docs/specs/acpi_cpu_hotplug.txt" in the QEMU tree. Add macros for a minimal subset of the modern interface, just so we can count the possible CPUs (as opposed to boot CPUs) in a later patch in this series. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1515 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20191022221554.14963-3-lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg: strip trailing whitespaceLeif Lindholm2019-10-0410-35/+35
| | | | | | | | | | | | | 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: 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/XenHypercallLib: Enable it in PEIMAnthony PERARD2019-08-211-0/+12
| | | | | | | | | | | | | | | 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/Library/XenPlatformLib: New libraryAnthony PERARD2019-08-211-0/+53
| | | | | | | | | | | 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-212-0/+147
| | | | | | | | | | | | 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: Detect OVMF_INFO from hvmloaderAnthony PERARD2019-08-211-4/+0
| | | | | | | | | | | | | | 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: introduce OVMF_PK_KEK1_APP_PREFIX_GUIDLaszlo Ersek2019-04-301-0/+45
| | | | | | | | | | | | | | | | | | | | | | | | For the EnrollDefaultKeys application, the hypervisor is expected to add a string entry to the "OEM Strings" (Type 11) SMBIOS table, with the following format: 4e32566d-8e9e-4f52-81d3-5bb9715f9727:<Base64 X509 cert for PK and first KEK> The string representation of the GUID at the front is the "application prefix", in terms of QEMU commit <https://git.qemu.org/?p=qemu.git;a=commit;h=2d6dcbf93fb0>. Introduce this GUID in the usual manner. 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> Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1747 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Gary Lin <glin@suse.com>
* OvmfPkg/EnrollDefaultKeys: extract MICROSOFT_VENDOR_GUIDLaszlo Ersek2019-04-301-0/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | The GUID 77FA9ABD-0359-4D32-BD60-28F4E78F784B is specified in MSDN, at <https://msdn.microsoft.com/en-us/ie/dn932805(v=vs.94)>, therefore it deserves an entry in the package DEC file, and a header file under "Include/Guid". (Arguably, this GUID declaration / definition could even live under SecurityPkg, but the edk2 tradition has been to hoist GUIDs, protocols/PPIs, and lib classes from OvmfPkg to a core package only when dependent C code is added to the core package.) 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> Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1747 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Gary Lin <glin@suse.com>
* OvmfPkg/IndustryStandard/Xen: replace MIT license text with SPDX IDLaszlo Ersek2019-04-1217-289/+17
| | | | | | | | | | | | | | | | | | | | | | The header files under "OvmfPkg/Include/IndustryStandard/Xen" include the MIT License text. Replace those license blocks with "SPDX-License-Identifier: MIT" (which refers to <https://spdx.org/licenses/MIT.html>) for easier parsing by machines (and humans). This follows the tree-wide adoption of "SPDX-License-Identifier"s, made for <https://bugzilla.tianocore.org/show_bug.cgi?id=1373>. 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: Lars Kurth <lars.kurth@citrix.com> Cc: xen-devel@lists.xenproject.org Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1654 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
* OvmfPkg: Copy Legacy8259 protocol definitions from IntelFrameworkPkgHao Wu2019-04-111-0/+291
| | | | | | | | | | | | | | | REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1496 This commit copies the exact Legacy8259 protocol header file from IntelFrameworkPkg to OvmfPkg. Also, the protocol GUID definition is duplicated in the OvmfPkg DEC file. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Ray Ni <ray.ni@intel.com> Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: Replace BSD License with BSD+Patent LicenseMichael D Kinney2019-04-0944-309/+44
| | | | | | | | | | | | | | | | | | | | https://bugzilla.tianocore.org/show_bug.cgi?id=1373 Replace BSD 2-Clause License with BSD+Patent License. This change is based on the following emails: https://lists.01.org/pipermail/edk2-devel/2019-February/036260.html https://lists.01.org/pipermail/edk2-devel/2018-October/030385.html RFCs with detailed process for the license change: V3: https://lists.01.org/pipermail/edk2-devel/2019-March/038116.html V2: https://lists.01.org/pipermail/edk2-devel/2019-March/037669.html V1: https://lists.01.org/pipermail/edk2-devel/2019-March/037500.html Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: add library to track boot option loading/starting on the consoleLaszlo Ersek2019-02-251-0/+41
| | | | | | | | | | | | | | | | | | | | | | | | Introduce the Platform Boot Manager Print Status Code Library (for short, PlatformBmPrintScLib) class for catching and printing the LoadImage() / StartImage() preparations, and return statuses, that are reported by UefiBootManagerLib. In the primary library instance, catch only such status codes that UefiBootManagerLib reports from the same module that contains PlatformBmPrintScLib. The intent is to establish a reporting-printing channel within BdsDxe, between UefiBootManagerLib and PlatformBmPrintScLib. Ignore status codes originating elsewhence, e.g. from UiApp's copy of UefiBootManagerLib. 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@linaro.org> Cc: Ray Ni <ray.ni@intel.com> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1515418 Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* Revert "OvmfPkg: VMWare SVGA display device register definitions"yuchenlin2018-11-201-104/+0
| | | | | | | | | | | | | This reverts commit 9bcca53fe466cdff397578328d9d87d257aba493. We reverted VMWare SVGA driver. We don't need these definitions too. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: yuchenlin <yuchenlin@synology.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com> (cherry picked from commit 328409ce8de7f318ee9c929b64302bd361cd1dbd) Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
* Reapply "OvmfPkg: VMWare SVGA display device register definitions"Laszlo Ersek2018-11-121-0/+104
| | | | | | | | | | | | | | | | | | | | | This reverts commit 328409ce8de7f318ee9c929b64302bd361cd1dbd, reapplying 9bcca53fe466cdff397578328d9d87d257aba493. Note that the commit now being reverted is technically correct; the only reason we're reverting it is because it should not have been pushed past the Soft Feature Freeze for the edk2-stable201811 tag. 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@linaro.org> Cc: Philippe Mathieu-Daudé <philmd@redhat.com> Cc: yuchenlin <yuchenlin@synology.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1319 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: yuchenlin <yuchenlin@synology.com>
* Revert "OvmfPkg: VMWare SVGA display device register definitions"yuchenlin2018-11-061-104/+0
| | | | | | | | | | | This reverts commit 9bcca53fe466cdff397578328d9d87d257aba493. We reverted VMWare SVGA driver. We don't need these definitions too. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: yuchenlin <yuchenlin@synology.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: add QEMU_RAMFB_GUIDGerd Hoffmann2018-06-141-0/+25
| | | | | | | | | Add GUID header file for the QemuRamfbDxe driver. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg/Virtio10Dxe: convert to PciCapLibLaszlo Ersek2018-05-241-5/+2
| | | | | | | | | | | | | | | | | Replace the manual capability list parsing in OvmfPkg/Virtio10Dxe with PciCapLib and PciCapPciIoLib API calls. The VIRTIO_PCI_CAP_LINK structure type is now superfluous. (Well, it always has been; we should have used EFI_PCI_CAPABILITY_HDR.) Also, EFI_PCI_CAPABILITY_VENDOR_HDR is now included at the front of VIRTIO_PCI_CAP. No driver other than Virtio10Dxe relies on VIRTIO_PCI_CAP. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg: introduce PciCapPciIoLibLaszlo Ersek2018-05-241-0/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a library class, and a UEFI_DRIVER lib instance, that are layered on top of PciCapLib, and allow clients to plug an EFI_PCI_IO_PROTOCOL backend into PciCapLib, for config space access. (Side note: Although the UEFI spec says that EFI_PCI_IO_PROTOCOL_CONFIG() returns EFI_UNSUPPORTED if "[t]he address range specified by Offset, Width, and Count is not valid for the PCI configuration header of the PCI controller", this patch doesn't directly document the EFI_UNSUPPORTED error code, for ProtoDevTransferConfig() and its callers ProtoDevReadConfig() and ProtoDevWriteConfig(). Instead, the patch refers to "unspecified error codes". The reason is that in edk2, the PciIoConfigRead() and PciIoConfigWrite() functions [1] can also return EFI_INVALID_PARAMETER for the above situation. Namely, PciIoConfigRead() and PciIoConfigWrite() first call PciIoVerifyConfigAccess(), which indeed produces the standard EFI_UNSUPPORTED error code, if the device's config space is exceeded. However, if PciIoVerifyConfigAccess() passes, and we reach RootBridgeIoPciRead() and RootBridgeIoPciWrite() [2], then RootBridgeIoCheckParameter() can still fail, e.g. if the root bridge doesn't support extended config space (see commit 014b472053ae3). For all kinds of Limit violations in IO, MMIO, and config space, RootBridgeIoCheckParameter() returns EFI_INVALID_PARAMETER, not EFI_UNSUPPORTED. That error code is then propagated up to, and out of, PciIoConfigRead() and PciIoConfigWrite(). [1] MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c [2] MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c ) Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg: introduce PciCapPciSegmentLibLaszlo Ersek2018-05-241-0/+82
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a library class, and a BASE lib instance, that are layered on top of PciCapLib, and allow clients to plug a PciSegmentLib backend into PciCapLib, for config space access. (Side note: The "MaxDomain" parameter is provided because, in practice, platforms exist where a PCI Express device may show up on a root bridge such that the root bridge doesn't support access to extended config space. Earlier the same issue was handled for MdeModulePkg/PciHostBridgeDxe in commit 014b472053ae3. However, that solution does not apply to the PciSegmentLib class, because: (1) The config space accessor functions of the PciSegmentLib class, such as PciSegmentReadBuffer(), have no way of informing the caller whether access to extended config space actually succeeds. (For example, in the UefiPciSegmentLibPciRootBridgeIo instace, which could in theory benefit from commit 014b472053ae3, the EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL.Pci.Read() status code is explicitly ignored, because there's no way for the lib instance to propagate it to the PciSegmentLib caller. If the EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL.Pci.Read() call fails, then DxePciSegmentLibPciRootBridgeIoReadWorker() returns Data with indeterminate value.) (2) There is no *general* way for any firmware platform to provide, or use, a PciSegmentLib instance in which access to extended config space always succeeds. In brief, on a platform where config space may be limited to 256 bytes, access to extended config space through PciSegmentLib may invoke undefined behavior; therefore PciCapPciSegmentLib must give platforms a way to prevent such access.) Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg: introduce PciCapLibLaszlo Ersek2018-05-241-0/+429
| | | | | | | | | | | | | | Add a library class, and a BASE lib instance, to work more easily with PCI capabilities in PCI config space. Functions are provided to parse capabilities lists, and to locate, describe, read and write capabilities. PCI config space access is abstracted away. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Suggested-by: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
* OvmfPkg/IndustryStandard: add QemuTpm.h headerMarc-André Lureau2018-05-221-0/+69
| | | | | | | | | Add some common macros and type definitions corresponding to the QEMU TPM interface. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
* OvmfPkg: remove BLOCK_MMIO_PROTOCOL and BlockMmioToBlockIoDxeLaszlo Ersek2018-04-101-50/+0
| | | | | | | | | | | | | | | | | | | | | | BLOCK_MMIO_PROTOCOL and BlockMmioToBlockIoDxe were introduced to OvmfPkg in March 2010, in adjacent commits b0f5144676fa and efd82c5794ec. In the past eight years, no driver or application seems to have materialized that produced BLOCK_MMIO_PROTOCOL instances. Meanwhile the UEFI spec has developed the EFI_RAM_DISK_PROTOCOL, which edk2 implements (and OVMF includes) as RamDiskDxe. Rather than fixing issues in the unused BlockMmioToBlockIoDxe driver, remove the driver, together with the BLOCK_MMIO_PROTOCOL definition that now becomes unused too. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Steven Shi <steven.shi@intel.com> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=926 Reported-by: Steven Shi <steven.shi@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
* OvmfPkg/QemuBootOrderLib: add ConnectDevicesFromQemu()Laszlo Ersek2018-03-141-2/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | QemuBootOrderLib expects PlatformBootManagerLib to call the following triplet: (1) EfiBootManagerConnectAll(), (2) EfiBootManagerRefreshAllBootOption(), (3) SetBootOrderFromQemu(). This leads to bad performance, when many devices exist such that the firmware can drive them, but they aren't marked for booting in the "bootorder" fw_cfg file. Namely, (1) EfiBootManagerConnectAll() talks to all hardware, which takes long. Plus some DriverBindingStart() functions write NV variables, which is also slow. (For example, the IP config policy for each NIC is stored in an NV var that is named after the MAC). (2) EfiBootManagerRefreshAllBootOption() generates boot options from the protocol instances produced by (1). Writing boot options is slow. (3) Under the above circumstances, SetBootOrderFromQemu() removes most of the boot options produced by (2). Erasing boot options is slow. Introduce ConnectDevicesFromQemu() as a replacement for (1): only connect devices that the QEMU user actually wants to boot off of. (There's a slight loss of compatibility when a platform switches from EfiBootManagerConnectAll() to ConnectDevicesFromQemu(). EfiBootManagerConnectAll() may produce UEFI device paths that are unknown to QemuBootOrderLib (that is, for neither PCI- nor virtio-mmio-based devices). The BootOrderComplete() function lets such unmatched boot options survive at the end of the boot order. With ConnectDevicesFromQemu(), these options will not be auto-generated in the first place. They may still be produced by other means. SetBootOrderFromQemu() is not modified in any way; reordering+filtering boot options remains a separate task.) Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Shannon Zhao <zhaoshenglong@huawei.com> Cc: Xiang Zheng <xiang.zheng@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> # ArmVirtQemu Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Xiang Zheng <xiang.zheng@linaro.org>
* OvmfPkg/QemuBootOrderLib: add missing EFIAPI specifiersLaszlo Ersek2018-03-141-0/+2
| | | | | | | | | | | | | | Public library APIs should be declared as EFIAPI. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Shannon Zhao <zhaoshenglong@huawei.com> Cc: Xiang Zheng <xiang.zheng@linaro.org> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> # ArmVirtQemu Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Xiang Zheng <xiang.zheng@linaro.org>
* OvmfPkg/MemEncryptSevLib: find pages of initial SMRAM save state mapLaszlo Ersek2018-03-061-0/+23
| | | | | | | | | | | | | | | | | | | | | In the next three patches, we're going to modify three modules under OvmfPkg. When OVMF is built with -D SMM_REQUIRE and runs in an SEV guest, each affected module will have to know the page range that covers the initial (pre-SMBASE relocation) SMRAM save state map. Add a helper function to MemEncryptSevLib that calculates the "base address" and "number of pages" constants for this page range. (In a RELEASE build -- i.e., with assertions disabled and optimization enabled --, the helper function can be compiled to store two constants determined at compile time.) Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
* OvmfPkg/MemEncryptSevLib: clean up MemEncryptSevSetPageEncMask() declLaszlo Ersek2018-03-061-15/+17
| | | | | | | | | | | | | | | | The declaration and the definition(s) of the function should have identical leading comments and/or identical parameter lists. Replace any leftover "clear" references to the C-bit with "set" references. Also remove any excess space in the comment block, and unindent the trailing "**/" if necessary. Correct several parameter references. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
* OvmfPkg/MemEncryptSevLib: clean up MemEncryptSevClearPageEncMask() declLaszlo Ersek2018-03-061-16/+18
| | | | | | | | | | | | | | | The declaration and the definition(s) of the function should have identical leading comments and/or identical parameter lists. Also remove any excess space in the comment block, and unindent the trailing "**/" if necessary. Correct several parameter references. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
* OvmfPkg/MemEncryptSevLib: clean up MemEncryptSevIsEnabled() declLaszlo Ersek2018-03-061-2/+2
| | | | | | | | | | | | | | | The declaration and the definition(s) of the function should have identical leading comments and/or identical parameter lists. Also remove any excess space in the comment block, and unindent the trailing "**/" if necessary. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-26 16:00:09 +0000