summaryrefslogtreecommitdiff
path: root/OvmfPkg/Include
AgeCommit message (Collapse)Author
2016-05-17OvmfPkg: introduce ICH9_PMBASE_VALUELaszlo Ersek
According to the ICH9 spec, PMBASE "provides 128 bytes of I/O space for ACPI, GPIO, and TCO logic. This is placed on a 128-byte boundary". On the Q35 machine type of QEMU, our current PMBASE setting of 0xB000 is the only thing that prevents us from lowering the base of the PCI IO port aperture from 0xC000. (The base must be aligned to 0x1000 due to PCI bridge requirements.) By moving our PMBASE to 0x0600 (moving the register block to 0x0600..0x067F inclusive), which is also what SeaBIOS uses on Q35, we will be able to lower the PCI IO port aperture base to 0x6000 (the next IO port under it being taken by the "vmport" device, at fixed 0x5658), while steering clear of other QEMU devices. On PIIX4, freeing up the 0x1000 IO ports at 0xB000 wouldn't help much, because the 0xA000 block right below it is occupied by unmovable devices (see <https://bugzilla.redhat.com/show_bug.cgi?id=1333238#c19> for details). Doing this for Q35 only has two more benefits: - It won't interfere with Xen guests, - The Q35 machine type with the smallest version number is "pc-q35-2.4", which is guaranteed to have an ACPI generator. This matters because the ACPI tables (FACP, DSDT) have to reflect the PM base address that we program. Cc: Gabriel Somlo <somlo@cmu.edu> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1333238 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Tested-by: Gabriel Somlo <somlo@cmu.edu>
2016-05-17OvmfPkg: add and use industry standard macro PIIX4_PMBA_MASKLaszlo Ersek
We already have the identical purpose (but different value) macro for ICH9, namely ICH9_PMBASE_MASK in "OvmfPkg/Include/IndustryStandard/Q35MchIch9.h". Also, stop bit-negating signed integer constants. Cc: Gabriel Somlo <somlo@cmu.edu> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1333238 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Tested-by: Gabriel Somlo <somlo@cmu.edu>
2016-05-17OvmfPkg: replace PcdAcpiPmBaseAddress with PIIX4_PMBA_VALUELaszlo Ersek
In the next patches, we'll differentiate the PMBA IO port address that we program on PIIX4 vs. Q35. Normally we'd just turn PcdAcpiPmBaseAddress into a dynamic PCD. However, because we need this value in BaseRomAcpiTimerLib too (which cannot access RAM and dynamic PCDs), it must remain a build time constant. We will introduce its Q35 counterpart later. As first step, replace the PCD with a new macro in "OvmfPlatforms.h"; Jordan prefers the latter to fixed PCDs in this instance. Cc: Gabriel Somlo <somlo@cmu.edu> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1333238 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Tested-by: Gabriel Somlo <somlo@cmu.edu>
2016-04-06OvmfPkg: VirtioLib: add Virtio10WriteFeatures() functionLaszlo Ersek
In VirtIo 1.0, a device can reject a self-inconsistent feature bitmap through the new VSTAT_FEATURES_OK status bit. (For example if the driver requests a higher level feature but clears a prerequisite feature.) This function is a small wrapper around VIRTIO_DEVICE_PROTOCOL.SetGuestFeatures() that also verifies if the VirtIo 1.0 device accepts the feature bitmap. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-04-06OvmfPkg: IndustryStandard: add definitions from the VirtIo 1.0 specLaszlo Ersek
These header files are intentionally minimal, and intentionally kept apart from the VirtIo 0.9.5 headers. The header inclusion chains end up like this (the Virtio10*.h header files in the middle are new): Virtio.h -> Virtio10.h -> Virtio095.h ^ ^ | | VirtioNet.h -> Virtio10Net.h -> Virtio095Net.h Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Jordan Justen <jordan.l.justen@intel.com>
2016-04-06OvmfPkg: IndustryStandard: factor out Virtio095Net.hLaszlo Ersek
In the upcoming virtio-1.0 series, we'll introduce "Virtio10Net.h". However, the "VirtioNet.h" header file should continue to expose the Virtio Network Device specific type and macro definitions for all virtio versions that OvmfPkg supports. Therefore extract "Virtio095Net.h" like this: VirtioNet.h -> Virtio095Net.h so that in the upcoming patches, we can insert "Virtio10Net.h" in the middle of the inclusion chain. This follows the example of "Acpi.h" and "Pci.h" under "MdePkg/Include/IndustryStandard". Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Suggested-by: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-04-06OvmfPkg: IndustryStandard: factor out Virtio095.hLaszlo Ersek
In the upcoming virtio-1.0 series, we'll introduce "Virtio10.h". However, the "Virtio.h" header file should continue to expose the generic type and macro definitions for all virtio versions that OvmfPkg supports. Therefore extract "Virtio095.h" like this: Virtio.h -> Virtio095.h so that in the upcoming patches, we can insert "Virtio10.h" in the middle of the inclusion chain. This follows the example of "Acpi.h" and "Pci.h" under "MdePkg/Include/IndustryStandard". Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Suggested-by: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-04-06OvmfPkg: VIRTIO_DEVICE_PROTOCOL: pass VRING object to SetQueueAddress()Laszlo Ersek
In virtio-1.0, it is not enough to pass the base address of the virtio queue to the hypervisor (as a frame number); instead it will want the addresses of the descriptor table, the available ring, and the used ring separately. Pass the VRING object to the SetQueueAddress() member function; this will enable a virtio-1.0 implementation. Convert the current producers and consumers to this prototype. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-04-06OvmfPkg: VIRTIO_DEVICE_PROTOCOL: remove GetQueueAddress() memberLaszlo Ersek
This function was never consumed by drivers, and the current prototype is unsupportable with virtio-1.0. Remove the function from the protocol definition, and drop the current (unused) implementations. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-04-06OvmfPkg: VIRTIO_DEVICE_PROTOCOL: widen the Features bitmap to 64 bitsLaszlo Ersek
The virtio-1.0 spec widens the Features bitmap to 64 bits. Modify the declarations of the GetDeviceFeatures() and SetGuestFeatures() protocol member functions accordingly. Normally, a protocol cannot be changed in incompatible ways if the GUID stays the same; however, we've always been extremely clear that VIRTIO_DEVICE_PROTOCOL is internal to edk2. See for example the top of "OvmfPkg/Include/Protocol/VirtioDevice.h". In this patch, all producers and consumers of the GetDeviceFeatures() and SetGuestFeatures() protocol members are updated. The drivers that currently produce these members are "legacy" drivers (in virtio-1.0 terminology), and they cannot (and will not) handle feature bits above BIT31. Therefore their conversion is only for compatibility with the modified protocol interface. The consumers will be responsible for checking the VIRTIO_DEVICE_PROTOCOL.Revision field, and for not passing feature bits that these backends cannot handle. The VirtioMmioGetDeviceFeatures() implementation stores the result of an MmioRead32() call with normal assignment, so it needs no change beyond adapting its prototype. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-03-23OvmfPkg: introduce gRootBridgesConnectedEventGroupGuidLaszlo Ersek
QEMU's ACPI table generator can only create meaningful _CRS objects -- apertures -- for the root buses if all of the PCI devices behind those buses are actively decoding their IO and MMIO resources, at the time of the firmware fetching the "etc/table-loader" fw_cfg file. This is not a QEMU error; QEMU follows the definition of BARs (which are meaningless when decoding is disabled). Currently we hook up AcpiPlatformDxe to the PCI Bus driver's gEfiPciEnumerationCompleteProtocolGuid cue. Unfortunately, when the PCI Bus driver installs this protocol, it's *still* not the right time for fetching "etc/table-loader": although resources have been allocated and BARs have been programmed with them, the PCI Bus driver has also cleared IO and MMIO decoding in the command registers of the devices. Furthermore, we couldn't reenable IO and MMIO decoding temporarily in our gEfiPciEnumerationCompleteProtocolGuid callback even if we wanted to, because at that time the PCI Bus driver has not produced PciIo instances yet. Our Platform BDSes are responsible for connecting the root bridges, hence they know exactly when the PciIo instances become available -- not when PCI enumeration completes (signaled by the above protocol), but when the ConnectController() calls return. This is when our Platform BDSes should explicitly cue in AcpiPlatformDxe. Then AcpiPlatformDxe can temporarily enable IO and MMIO decoding for all devices, while it contacts QEMU for the ACPI payload. This patch introduces the event group GUID that we'll use for unleashing AcpiPlatformDxe from our Platform BDSes. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-03-10OvmfPkg: IndustryStandard/Q35MchIch9.h: add PCIEXBAR macrosLaszlo Ersek
Section 5.1.16 ("PCIEXBAR -- PCI Express Register Range Base Address") in Intel document #316966-002 (already referenced near the top of this header file) describes the Q35 DRAM Controller register that configures the memory-mapped PCI config space (also known as MMCONFIG, and ECAM / Enhanced Configuration Access Method). In this patch we add the macros we'll need later. We'll only support the 256 MB memory-mapped config space -- enough for buses [0, 255]. Cc: Gabriel Somlo <somlo@cmu.edu> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: Michał Zegan <webczat_200@poczta.onet.pl> Ref: https://github.com/tianocore/edk2/issues/32 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Marcel Apfelbaum <marcel@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Tested-by: Gabriel Somlo <somlo@cmu.edu> Tested-by: Michał Zegan <webczat_200@poczta.onet.pl>
2016-02-24OvmfPkg: VirtioFlush(): return the number of bytes written by the hostLaszlo Ersek
VirtioLib provides an API for simple, synchronous (request/response-style) virtio communication. The guest driver builds one descriptor chain, link for link, with VirtioPrepare() and VirtioAppendDesc(), then submits the chain, and awaits the processing, with VirtioFlush(). The descriptor chain is always built at the beginning of the descriptor area, with the head descriptor having descriptor index 0. In order to submit the descriptor chain to the host, the guest always pushes a new "available element" to the Available Ring, in genuine queue-like fashion, with the new element referencing the head descriptor (which always has index 0, see above). In turn, after processing, the host always pushes a new "used element" to the Used Ring, in genuine queue-like fashion, with the new element referencing the head descriptor of the chain that was just processed. The same element also reports the number of bytes that the host wrote, consecutively across the host-writeable buffers that were linked by the descriptors. (See "OvmfPkg/VirtioNetDxe/TechNotes.txt" for a diagram about the descriptor area and the rings.) Because at most one descriptor chain can be in flight with VirtioLib at any time, - the Available Ring and the Used Ring proceed in lock-step, - and the head descriptor that the new "available" and "used" elements can ever reference has index 0. Based on the above, we can modify VirtioFlush() to return the number of bytes written by the host across the descriptor chain. The virtio-block and virtio-scsi drivers don't care (they have other ways to parse the data produced by the host), while the virtio-net driver doesn't use VirtioFlush() at all (it employs VirtioLib only to set up its rings). However, the virtio entropy device, to be covered in the upcoming patches, reports the amount of randomness produced by the host only through this quantity. Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2015-11-30OvmfPkg: SmmCpuFeaturesLib: customize state save map formatPaolo Bonzini
This adjusts the previously introduced state save map access functions, to account for QEMU and KVM's 64-bit state save map following the AMD spec rather than the Intel one. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> [lersek@redhat.com: reflow commit message, convert patch to CRLF] Cc: Paolo Bonzini <pbonzini@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Michael Kinney <michael.d.kinney@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19057 6f19259b-4bc3-4df7-8a09-765794883524
2015-08-11OvmfPkg/Xen: use lower case x in hex immediate valueArd Biesheuvel
The Clang assembler for AArch64 chokes on the value 0XEA1 since it expects the 0x prefix to use a lower case x. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18204 6f19259b-4bc3-4df7-8a09-765794883524
2015-06-09OvmfPkg/PlatformPei: Initialise RCBA (B0:D31:F0 0xf0) registerPaulo Alcantara
This patch initialises root complex register block BAR in order to support TCO watchdog emulation features (e.g. reboot upon NO_REBOOT bit not set) on QEMU. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Paulo Alcantara <pcacjr@zytor.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17601 6f19259b-4bc3-4df7-8a09-765794883524
2015-05-13OvmfPkg: extract some bits and port offsets common to Q35 and I440FXLaszlo Ersek
The PMBA_RTE and ACPI_TIMER_OFFSET macros apply equally to both boards, plus they are triplicated between the various AcpiTimerLib instances. Define them centrally in "OvmfPlatforms.h". Cc: Gabriel Somlo <somlo@cmu.edu> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Gabriel Somlo <somlo@cmu.edu> Tested-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17436 6f19259b-4bc3-4df7-8a09-765794883524
2015-05-13OvmfPkg: new macros for platform specific register addresses and valuesLaszlo Ersek
Define some new macros for register addresses (both PCI and IO) and register values (bits) that we're going to use soon. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Gabriel Somlo <somlo@cmu.edu> Tested-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17433 6f19259b-4bc3-4df7-8a09-765794883524
2015-05-13OvmfPkg: split Include/OvmfPlatforms.hLaszlo Ersek
Move platform specific macros to their own include files. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17432 6f19259b-4bc3-4df7-8a09-765794883524
2015-03-03OvmfPkg: XenHypercallLib: introduce XenHypercallIsAvailable()Laszlo Ersek
Similarly to QemuFwCfgLib, we prefer mellow library construction code and an explicit "are you available" query function in the XenHypercallLib class. In this step we introduce that query function, but move no client code to it yet. Suggested-by: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17000 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-28ArmVirtualizationPkg: add XenIoMmioLibArd Biesheuvel
This adds a XenIoMmioLib declaration and implementation that can be invoked to install the XENIO_PROTOCOL and a corresponding grant table address on a EFI handle. Contributed-under: TianoCore Contribution Agreement 1.0 Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16979 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-28Ovfm/Xen: add a Vendor Hardware device path GUID for the XenBus rootArd Biesheuvel
On non-PCI Xen guests (such as ARM), the XenBus root is not a PCI device but an abstract 'platform' device. Add a dedicated Vendor Hardware device path GUID to identify this node. Contributed-under: TianoCore Contribution Agreement 1.0 Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16978 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-28Ovmf/Xen: add Xen PV console SerialPortLib driverArd Biesheuvel
This implements a SerialPortLib instance that wires up to the PV console ring used by domU guests. Also imports the required upstream Xen io/console.h header. Contributed-under: TianoCore Contribution Agreement 1.0 Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16976 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-28Ovmf/Xen: implement XenHypercallLib for ARMArd Biesheuvel
This patch adds an implementation of XenHypercallLib for both AArch64 and AArch32 execution modes on ARM systems. Contributed-under: TianoCore Contribution Agreement 1.0 Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16974 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-28Ovmf/Xen: introduce XENIO_PROTOCOLArd Biesheuvel
This introduces the abstract XENIO_PROTOCOL that will be used to communicate the Xen grant table address to drivers supporting this protocol. Primary purpose is allowing us to change the XenBusDxe implementation so that it can support non-PCI Xen implementations such as Xen on ARM. Contributed-under: TianoCore Contribution Agreement 1.0 Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16971 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-28Ovmf/Xen: move XenBusDxe hypercall code to separate libraryArd Biesheuvel
This moves all of the Xen hypercall code that was private to XenBusDxe to a new library class XenHypercallLib. This will allow us to reimplement it for ARM, and to export the Xen hypercall functionality to other parts of the code, such as a Xen console SerialPortLib driver. Contributed-under: TianoCore Contribution Agreement 1.0 Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16970 6f19259b-4bc3-4df7-8a09-765794883524
2015-02-28Ovmf/Xen: move Xen interface version to <xen.h>Ard Biesheuvel
Tiancore has its private copy of the Xen headers, and all drivers that depend on it should use the same Xen interface version, so let's move the #define to xen.h itself. Contributed-under: TianoCore Contribution Agreement 1.0 Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16967 6f19259b-4bc3-4df7-8a09-765794883524
2015-01-14OvmfPkg: QemuBootOrderLib: expose QEMU's "-boot menu=on[,splash-time=N]"Laszlo Ersek
The QEMU command line option -boot menu=on is meant to have the guest firmware wait for a firmware-specific interval for the user to enter the boot menu. During the wait, the user can opt to enter the boot menu, or interrupt the wait and proceed to booting at once. If the wait interval elapses, the firmware should boot as it normally would. The QEMU command line option -boot menu=on,splash-time=N means the same, except the firmware should wait for cca. N milliseconds instead of a firmware-specific interval. We can approximate this behavior quite well for edk2's virtual platforms because the Intel BDS front page already supports a progress bar, with semantics similar to the above. Let's distill the fw_cfg bits underlying "-boot menu=on,splash-time=N" for the BDS policies, in the form of a timeout value they can pass to Intel's PlatformBdsEnterFrontPage(). If the boot menu is not requested, we return "gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdPlatformBootTimeOut", which is what the virtual platforms use right now. If the boot menu is requested without specifying the timeout, we return the same PCD, unless it would cause us to skip the boot menu at once. In the latter case, we return 3 seconds (as an approximation of the 2500 ms SeaBIOS default.) RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1170507 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Olivier Martin <Olivier.martin@arm.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16610 6f19259b-4bc3-4df7-8a09-765794883524
2015-01-02OvmfPkg: introduce VIRTIO_MMIO_TRANSPORT_GUIDLaszlo Ersek
Soon there will be more than one modules (in separate packages) that need to have an understanding about the GUID used in the VenHw() device path nodes that describe virtio-mmio transports. Define such a GUID explicitly. Preserve the current value (which happens to be the FILE_GUID of ArmPlatformPkg/ArmVirtualizationPkg/VirtFdtDxe/VirtFdtDxe.inf) for compatibility with external users. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16572 6f19259b-4bc3-4df7-8a09-765794883524
2015-01-02OvmfPkg: extract QemuBootOrderLibLaszlo Ersek
and rebase OvmfPkg's PlatformBdsLib on the standalone library. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16570 6f19259b-4bc3-4df7-8a09-765794883524
2014-11-14OvmfPkg: Factor out platform detection (q35 vs. piix4)Gabriel Somlo
Introduce macros to detect the underlying platform and access its ACPI power management registers, based on querying the host bridge device ID. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gabriel Somlo <somlo@cmu.edu> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16372 6f19259b-4bc3-4df7-8a09-765794883524
2014-10-31OvmfPkg/Xen*: Pass struct XENSTORE_TRANSACTION argument as a pointerAnthony PERARD
As EDK II does not allow calls with a struct. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16294 6f19259b-4bc3-4df7-8a09-765794883524
2014-10-31OvmfPkg/Include/...Xen: Convert __i386__/__x86_64__ to MDE_CPU_IA32/MDE_CPU_X64.Anthony PERARD
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16293 6f19259b-4bc3-4df7-8a09-765794883524
2014-10-29OvmfPkg/XenPvBlkDxe: Add BlockFront client.Samuel Thibault
This is the code that will do the actual communication between OVMF and a PV block backend, where the block device lives. The protocol used is describe in the blkif.h header. This implementation originally comes from Mini-OS, a part of the Xen Project. Change in V4: - add file header to BlockFront.h (license, copyright, brief desc) Change in V3: - Improve comment of XenBusReadUint64. - Moving blkif.h to this patch with the necessary #pragma pack(4) applied for Ia32. - Add a note about the license in the commit message - Add "The protocol used is describe in the blkif.h header." in the commit message - Have a mandatory sector-size multiple of 512 or fail to initialize. - use Sector instead of Offset for IO request. with Sector been 512-byte unit. - print something if EventChannelNotify return an error. Change in V2: - trigger CoW is probably not needed on OVMF (as opposed to Mini-OS), removed the test. - comments - renamed XenbusReadInteger to XenBusReadUint64 - remove callback from IoData, use simple status instead - return a status from the synchronus io - Close protocol if blockfront init fail. - fix few debug print - Rename XenbusIo to XenBusIo - XenPvBlkWaitForBackendState will return an error if the new backend states is not the expected state. - Add the license License: This patch adds some files which are under the MIT license. Signed-off-by: Samuel Thibault <samuel.thibault@eu.citrix.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16273 6f19259b-4bc3-4df7-8a09-765794883524
2014-10-29OvmfPkg/XenBusDxe: Add Event Channel into XenBus protocol.Anthony PERARD
This patch adds three event channel related functions: - EventChannelAllocate: Allocate an event channel port that can be bind from a specified domain. - EventChannelNotify: Send an event to the remote end of a channel. - EventChannelClose: Close a local event channel port. Change in V3: - eventchannel, update protocol to return error code. - expand patch description - Add comments in the XenBus Protocol header. Change in V2: - coding style - adding comment to functions - Rename Xenbus to XenBus. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16271 6f19259b-4bc3-4df7-8a09-765794883524
2014-10-29OvmfPkg/XenBusDxe: Introduce XenBus support itself.Anthony PERARD
This is a bus-like on top of XenStore. It will look for advertised ParaVirtualized devices and initialize them by producing XenBus protocol. Change in V4: - Replace the license by the commonly used file header text. - Clean XenBus.h header (remove copyright that does not belong to the file anymore; and rewrite the brief description of the file) - Fix description on the function Change in V3: - Insert to ChildList later, once populated. - Remove XENBUS_XENSTORE_NODE macro. - add comment to XenBusAddDevice and XenBusEnumerateBus about concurrency calls. - Add a description to the introduced member to the protocol. Change in V2: - comment, file header - Fix comment style - Error handling in the main init function - coding style - Fix error path in add device. Origin: FreeBSD 10.0 License: This patch adds XenBus.c which is under the MIT licence. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16270 6f19259b-4bc3-4df7-8a09-765794883524
2014-10-29OvmfPkg/XenBusDxe: Add XenStore function into the XenBus protocolAnthony PERARD
Change in V3: - Have XenStoreWaitWatch/XenBusWaitForWatch return a XENSTORE_STATUS instead of VOID. - Add description of the introducted member of the protocol. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Acked-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16269 6f19259b-4bc3-4df7-8a09-765794883524
2014-10-29OvmfPkg/XenBusDxe: Add XenStore client implementationAnthony PERARD
XenStore is a key/value database, which is running on another virtual machine. It can be accessed through shared memory. This is a client implementation. Change in V3: - moving xs_wire.h from patch #1 to this patch - fix return value of XenStoreListDirectory - Use a timeout to print a debug message if the other side of the xenstore ring does not notify through the event channel. This is done with the new XenStoreWaitForEvent function. - Have XenStoreReadReply check status of XenStoreProcessMessage and return an error if needed. - Have XenStoreTalkv return the status of XenStoreReadReply. - Have a loop to check for the quiescent of the response ring in the XenStoreInitComms function. (with a timeout of 5 seconds) - use the recently introduced XenStore 'closing' feature. Change in V2: - Change comment style, from freebsd to ovmf - Fix type of EventChannel - Fix debug print, no more cast - Implement XenStoreDeinit. - Clean up comments - Fix few codding style issue - Add FAIL xenstore status value. Origin: FreeBSD 10.0 License: This patch adds several files under the MIT licence. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Acked-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16267 6f19259b-4bc3-4df7-8a09-765794883524
2014-10-29OvmfPkg/XenBusDxe: Add Event Channel Notify.Anthony PERARD
This first function is used to notify the other side that there is something to do. The other side is another Xen domain. Change in V4: - Replace the license by the commonly used file header text. Change in V3: - Return error code from hypercall instead of ASSERT for XenEventChannelNotify - moving event_channel.h to this patch. Change in V2: - file header - coding style - adding comment to functions - Licenses License: This patch adds event_channel.h which is under MIT licence. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16265 6f19259b-4bc3-4df7-8a09-765794883524
2014-10-29OvmfPkg: Introduce XenBus Protocol.Anthony PERARD
This protocol will be used for communication between a PV driver (like a PV block driver) and the XenBus/XenStore. Change in V5: - Replace the license by the commonly used file header text. Change in V3: - Add disclaimer about the volatile nature of the protocol. - Add a description on the two introduced members to the protocol. Change in V2: - Comment, file header - Protocol License - Declare xen interface version earlier - Rename protocol from Xenbus to XenBus Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16262 6f19259b-4bc3-4df7-8a09-765794883524
2014-10-29OvmfPkg: Add public headers from Xen Project.Anthony PERARD
This patch imports publics headers in order to use features from Xen like XenStore, PV Block... There is only the necessary header files and there are only a few modifications in order to facilitate future merge of more recent header (that would be necessary to access new features). There is little modification compared to the original files: - Removed most of the unused part of the headers - Use of ZeroMem() instead of memset() - using #pragma pack(4) for IA32 compilation. - Replace types to be more UEFI compliant using a script. OVMF, when built for IA32 arch, uses the gcc switch -malign-double. This change the alignment of fields in some struct compare to what is espected by Xen and any backends. To fix the alignment, the #pragma pack(4) directive is used around the struct that need it. Command to run to change types: find OvmfPkg/Include/IndustryStandard/Xen -type f -name '*.h' -exec sed --regexp-extended --file=fix_type_in_xen_includes.sed --in-place {} \; Avoid changing the 'long' that is not a type (with the first line). $ cat fix_type_in_xen_includes.sed /as long as/b s/([^a-zA-Z0-9_]|^)uint8_t([^a-zA-Z0-9_]|$)/\1UINT8\2/g s/([^a-zA-Z0-9_]|^)uint16_t([^a-zA-Z0-9_]|$)/\1UINT16\2/g s/([^a-zA-Z0-9_]|^)uint32_t([^a-zA-Z0-9_]|$)/\1UINT32\2/g s/([^a-zA-Z0-9_]|^)uint64_t([^a-zA-Z0-9_]|$)/\1UINT64\2/g s/([^a-zA-Z0-9_]|^)int8_t([^a-zA-Z0-9_]|$)/\1INT8\2/g s/([^a-zA-Z0-9_]|^)int16_t([^a-zA-Z0-9_]|$)/\1INT16\2/g s/([^a-zA-Z0-9_]|^)int32_t([^a-zA-Z0-9_]|$)/\1INT32\2/g s/([^a-zA-Z0-9_]|^)int64_t([^a-zA-Z0-9_]|$)/\1INT64\2/g s/([^a-zA-Z0-9_]|^)void([^a-zA-Z0-9_]|$)/\1VOID\2/g s/([^a-zA-Z0-9_]|^)unsigned int([^a-zA-Z0-9_]|$)/\1UINT32\2/g s/([^a-zA-Z0-9_]|^)int([^a-zA-Z0-9_]|$)/\1INT32\2/g s/([^a-zA-Z0-9_]|^)unsigned char([^a-zA-Z0-9_]|$)/\1UINT8\2/g s/([^a-zA-Z0-9_]|^)char([^a-zA-Z0-9_]|$)/\1CHAR8\2/g s/([^a-zA-Z0-9_]|^)unsigned long([^a-zA-Z0-9_]|$)/\1UINTN\2/g s/([^a-zA-Z0-9_]|^)long([^a-zA-Z0-9_]|$)/\1INTN\2/g Change in V4: - Add a README in Xen headers directory to explain what have been done to it. It is mostly a copy/past from the commit description with some rewording. - replace unsigned char by UINT8 as there is no unsigned char in UEFI types. Change in V3: - Remove unused header sched.h - moving xs_wire.h in a later patch, where it's first needed - moving io/blkif.h in a later patch (XenPvBlkDxe: Add BlockFront client) - moving event_channel.h in a later patch (XenBusDxe: Add Event Channel Notify) - using #pragma pack(4) for IA32 - headers trimed down, removed most of the unused struct/define/... License: This patch adds many files under the MIT licence. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16257 6f19259b-4bc3-4df7-8a09-765794883524
2014-06-19OvmgPkg: QemuFwCfgLib: export QEMU_FW_CFG_FNAME_SIZELaszlo Ersek
Names of firmware configuration files always take 56 bytes (including at least one terminating NUL byte). Expose this constant to all consumers of QemuFwCfgLib because further interfaces may depend on it. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15571 6f19259b-4bc3-4df7-8a09-765794883524
2014-05-20OvmfPkg: QemuVideoDxe: Int10h stub for Windows 7 & 2008 (stdvga, QXL)Laszlo Ersek
The Windows 2008 R2 SP1 (and Windows 7) UEFI guest's default video driver dereferences the real mode Int10h vector, loads the pointed-to handler code, and executes what it thinks to be VGA BIOS services in an internal real-mode emulator. Consequently, video mode switching doesn't work in Windows 2008 R2 SP1 when it runs on the pure UEFI build of OVMF, making the guest uninstallable. This patch adds a VGABIOS "shim" to QemuVideoDxe. For the first stdvga or QXL card bound, an extremely stripped down VGABIOS imitation is installed in the C segment. It provides a real implementation for the few services that are in fact necessary for the win2k8r2sp1 UEFI guest, plus some fakes that the guest invokes but whose effect is not important. The C segment is not present in the UEFI memory map prepared by OVMF. We never add memory space that would cover it (either in PEI, in the form of memory resource descriptor HOBs, or in DXE, via gDS->AddMemorySpace()). This way the handler body is invisible to all non-buggy UEFI guests, and the rest of edk2. The Int10h real-mode IVT entry is covered with a Boot Services Code page, making that too unaccessible to the rest of edk2. (Thus UEFI guest OSes different from the Windows 2008 family can reclaim the page. The Windows 2008 family accesses the page at zero regardless of the allocation type.) The patch is the result of collaboration: Initial proof of concept IVT entry installation and handler skeleton (in NASM) by Jordan Justen. Service tracing and implementation, data collection/analysis, and C coding by yours truly. Last minute changes by Gerd Hoffmann: - Use OEM mode number (0xf1) instead of standard 800x600 mode (0x143). The resolution of the OEM mode (0xf1) is not standardized; the guest can't expect anything from it in advance. - Use 1024x768 rather than 800x600 for more convenience in the Windows 2008 R2 SP1 guest during OS installation, and after normal boot until the QXL XDDM guest driver is installed. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15540 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-22OvmfPkg: introduce gOvmfPlatformConfigGuidLaszlo Ersek
This GUID should become a new "namespace" for UEFI variables that are specific to OVMF configuration (as opposed to standard UEFI global variables). We'll also use it as the GUID of the related HII form-set (ie. the interactive user interface). Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15363 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-04OvmfPkg QemuFwCfgLib: determine if S3 support is explicitly enabledLaszlo Ersek
Such a packaged query function will come in handy in the following patches. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> [jordan.l.justen@intel.com: check for enabled rather than disabled] Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15292 6f19259b-4bc3-4df7-8a09-765794883524
2014-01-03OvmfPkg: QemuFwCfgLib: introduce InternalQemuFwCfgIsAvailable()Laszlo Ersek
This internal function allows separation of library-internal and for-clients external availability of fw_cfg. The interface contract of QemuFwCfgIsAvailable() is changed so that now it may modify fw_cfg state. All current users are compliant with the new contract. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15044 6f19259b-4bc3-4df7-8a09-765794883524
2013-12-18OvmfPkg: IndustryStandard/VirtioBlk: introduce topology-related definitionsLaszlo Ersek
Based on <https://tools.oasis-open.org/version-control/browse/wsvn/virtio/virtio-v1.0-wd01-part1-specification.txt?rev=159>, which is the last text format revision. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15002 6f19259b-4bc3-4df7-8a09-765794883524
2013-12-18OvmfPkg: IndustryStandard/VirtioBlk: add extra horizontal whitespaceLaszlo Ersek
We're going to introduce a new macro and a new VIRTIO_BLK_CONFIG member that need realignment of existing definitions and comments. Separate out the whitespace changes in this patch. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15001 6f19259b-4bc3-4df7-8a09-765794883524
2013-12-11OvmfPkg/Virtio: Removed VirtioReadDevice() / VirtIoWriteDevice() functionsOlivier Martin
These functions did not provide much more than the new protocol functions VIRTIO_DEVICE_PROTOCOL.ReadDevice() / VIRTIO_DEVICE_PROTOCOL.WriteDevice(). Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin <olivier.martin@arm.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14968 6f19259b-4bc3-4df7-8a09-765794883524
2013-12-11OvmfPkg/Virtio.h: Removed definition of VIRTIO_HDROlivier Martin
This definition is specific to VirtIo over PCI. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin <olivier.martin@arm.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Signed-off-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14967 6f19259b-4bc3-4df7-8a09-765794883524
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-02 00:52:51 +0000