Ip4ConfigDxe driver is deprecated in UEFI 2.5, so we will not support original Ip4Config Protocol,
which is replace by Ip4Config2 Protocol integrated in Ip4Dxe driver(git commit 1f6729ff (SVN r17853)).
Therefore we can remove Ip4ConfigDxe driver from this build.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17914 6f19259b-4bc3-4df7-8a09-765794883524
PeiCore hang when loads a PEIM whose section alignment requirement is 0x40
but the actual base address is 0x20 aligned.
The issue is caused by the following facts, in order:
1. GCC49 requires the section alignment of .data to be 0x40. So a new link
script gcc4.9-ld-script was added for GCC49 to specify the 0x40
alignment.
2. GenFw tool was enhanced to sync ELF's section alignment to PE header.
Before the enhancement, the section alignment of converted PE image
always equals to 0x20.
If only with #1 change, GCC49 build image won't hang in PeiCore because
the converted PE image still claims 0x20 section alignment which is
aligned to the align setting set in FDF file. But later with #2 change,
the converted PE image starts to claims 0x40 section alignment, while
build tool still puts the PEIM in 0x20 aligned address, resulting the
PeCoffLoaderLoadImage() reports IMAGE_ERROR_INVALID_SECTION_ALIGNMENT
error.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17902 6f19259b-4bc3-4df7-8a09-765794883524
The bash binary can be in various locations depending on the system: on Linux
it's in /bin while on BSD it's normally in /usr/local/bin. However, the
env binary is almost always in /usr/bin and so can be used to find and start
the shell.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Bruce Cran <bruce@cran.org.uk>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17883 6f19259b-4bc3-4df7-8a09-765794883524
We are preparing for detaching the S3Ready() functionality from the
EFI_ACPI_S3_SAVE_PROTOCOL.S3Save() protocol member function. Instead, we
will hook the same logic to the End-of-Dxe event group.
The EFI_ACPI_S3_SAVE_PROTOCOL has another member: GetLegacyMemorySize().
According to the documenation,
This function returns the size of the legacy memory (meaning below 1 MB)
that is required during an S3 resume. Before the Framework-based
firmware transfers control to the OS, it has to transition from flat
mode into real mode in case the OS supplies only a real-mode waking
vector. This transition requires a certain amount of legacy memory.
After getting the size of legacy memory below, the caller is responsible
for allocating the legacy memory below 1 MB according to the size that
is returned. The specific implementation of allocating the legacy memory
is out of the scope of this specification.
When EFI_ACPI_S3_SAVE_PROTOCOL.S3Save() is called, the address of the
legacy memory allocated above must be passed to it, in the
LegacyMemoryAddress parameter.
In practice however:
- The S3Ready() function ignores the LegacyMemoryAddress completely.
- No code in the edk2 tree calls
EFI_ACPI_S3_SAVE_PROTOCOL.GetLegacyMemorySize(), ever.
- All callers of this specific implementation of
EFI_ACPI_S3_SAVE_PROTOCOL.S3Save() in the edk2 tree pass a NULL
LegacyMemoryAddress:
BdsLibBootViaBootOption()
[IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c]
For this reason, ASSERT() explicitly that LegacyGetS3MemorySize() is never
called, and that the LegacyMemoryAddress parameter is always NULL.
This fact is important to capture in the code, because in the End-of-Dxe
callback, no LegacyMemoryAddress parameter can be taken. So let's make it
clear that we actually don't even have any use for that parameter.
This patch ports the identical change from IntelFrameworkModulePkg to
OvmfPkg.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17806 6f19259b-4bc3-4df7-8a09-765794883524
AuthVariableLib and TpmMeasurementLib library classes are now linked with
MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
to optionally support secure variables.
For OvmfPkg,
link AuthVariableLib and DxeTpmMeasurementLib in SecurityPkg
when SECURE_BOOT_ENABLE = TRUE,
and link AuthVariableLibNull and TpmMeasurementLibNull in MdeModulePkg
when SECURE_BOOT_ENABLE = FALSE.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17760 6f19259b-4bc3-4df7-8a09-765794883524
At the moment we work with a UC default MTRR type, and set three memory
ranges to WB:
- [0, 640 KB),
- [1 MB, LowerMemorySize),
- [4 GB, 4 GB + UpperMemorySize).
Unfortunately, coverage for the third range can fail with a high
likelihood. If the alignment of the base (ie. 4 GB) and the alignment of
the size (UpperMemorySize) differ, then MtrrLib creates a series of
variable MTRR entries, with power-of-two sized MTRR masks. And, it's
really easy to run out of variable MTRR entries, dependent on the
alignment difference.
This is a problem because a Linux guest will loudly reject any high memory
that is not covered my MTRR.
So, let's follow the inverse pattern (loosely inspired by SeaBIOS):
- flip the MTRR default type to WB,
- set [0, 640 KB) to WB -- fixed MTRRs have precedence over the default
type and variable MTRRs, so we can't avoid this,
- set [640 KB, 1 MB) to UC -- implemented with fixed MTRRs,
- set [LowerMemorySize, 4 GB) to UC -- should succeed with variable MTRRs
more likely than the other scheme (due to less chaotic alignment
differences).
Effects of this patch can be observed by setting DEBUG_CACHE (0x00200000)
in PcdDebugPrintErrorLevel.
Cc: Maoming <maoming.maoming@huawei.com>
Cc: Huangpeng (Peter) <peter.huangpeng@huawei.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Maoming <maoming.maoming@huawei.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17722 6f19259b-4bc3-4df7-8a09-765794883524
Maoming reported that guest memory sizes equal to or larger than 64GB
were not correctly handled by OVMF.
Enabling the DEBUG_GCD (0x00100000) bit in PcdDebugPrintErrorLevel, and
starting QEMU with 64GB guest RAM size, I found the following error in the
OVMF debug log:
> GCD:AddMemorySpace(Base=0000000100000000,Length=0000000F40000000)
> GcdMemoryType = Reserved
> Capabilities = 030000000000000F
> Status = Unsupported
This message is emitted when the DXE core is initializing the memory space
map, processing the "above 4GB" memory resource descriptor HOB that was
created by OVMF's QemuInitializeRam() function (see "UpperMemorySize").
The DXE core's call chain fails in:
CoreInternalAddMemorySpace() [MdeModulePkg/Core/Dxe/Gcd/Gcd.c]
CoreConvertSpace()
//
// Search for the list of descriptors that cover the range BaseAddress
// to BaseAddress+Length
//
CoreSearchGcdMapEntry()
CoreSearchGcdMapEntry() fails because the one entry (with type
"nonexistent") in the initial GCD memory space map is too small, and
cannot be split to cover the memory space range being added:
> GCD:Initial GCD Memory Space Map
> GCDMemType Range Capabilities Attributes
> ========== ================================= ================ ================
> NonExist 0000000000000000-0000000FFFFFFFFF 0000000000000000 0000000000000000
The size of this initial entry is determined from the CPU HOB
(CoreInitializeGcdServices()).
Set the SizeOfMemorySpace field in the CPU HOB to mPhysMemAddressWidth,
which is the narrowest valid value to cover the entire guest RAM.
Reported-by: Maoming <maoming.maoming@huawei.com>
Cc: Maoming <maoming.maoming@huawei.com>
Cc: Huangpeng (Peter) <peter.huangpeng@huawei.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Wei Liu <wei.liu2@citrix.com>
Tested-by: Maoming <maoming.maoming@huawei.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17720 6f19259b-4bc3-4df7-8a09-765794883524
We'll soon increase the maximum guest-physical RAM size supported by OVMF.
For more RAM, the DXE IPL is going to build more page tables, and for that
it's going to need a bigger chunk from the permanent PEI RAM.
Otherwise CreateIdentityMappingPageTables() would fail with:
> DXE IPL Entry
> Loading PEIM at 0x000BFF61000 EntryPoint=0x000BFF61260 DxeCore.efi
> Loading DXE CORE at 0x000BFF61000 EntryPoint=0x000BFF61260
> AllocatePages failed: No 0x40201 Pages is available.
> There is only left 0x3F1F pages memory resource to be allocated.
> ASSERT .../MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c(123):
> BigPageAddress != 0
(The above example belongs to the artificially high, maximal address width
of 52, clamped by the DXE core to 48. The address width of 48 bits
corresponds to 256 TB or RAM, and requires a bit more than 1GB for paging
structures.)
Cc: Maoming <maoming.maoming@huawei.com>
Cc: Huangpeng (Peter) <peter.huangpeng@huawei.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Brian J. Johnson <bjohnson@sgi.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Brian J. Johnson <bjohnson@sgi.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17719 6f19259b-4bc3-4df7-8a09-765794883524
This command was used to convert the file:
iconv -f UTF-16 -t UTF-8 \
-o OvmfPkg/PlatformDxe/Platform.uni \
OvmfPkg/PlatformDxe/Platform.uni
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Yingke Liu <yingke.d.liu@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17700 6f19259b-4bc3-4df7-8a09-765794883524
Qemu commit c5d4dac ("virtio-vga: add virtio gpu device with vga
compatibility") enables OVMF to drive the virtio-vga device:
The vga compatibility part of virtio-vga is identical to the qemu
standard vga, so supporting that is as easy as adding the PCI ID
to the list.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Jordan Justen <jordan.l.justen@intel.com>
[lersek@redhat.com: subject fixup and QEMU commit reference in commit msg]
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17690 6f19259b-4bc3-4df7-8a09-765794883524
Git commit 54753b60 (SVN r16870), "MdeModulePkg: Update SMBIOS revision to
3.0." changed PcdSmbiosVersion from 0x0208 to 0x0300. This controls the
version number of the SMBIOS entry point table (and other things) that
"MdeModulePkg/Universal/SmbiosDxe" installs.
Alas, this change breaks older Linux guests, like RHEL-6 (up to RHEL-6.7);
those are limited to 2.x (both in the guest kernel firmware driver, and in
the dmidecode utility). The SMBIOS 3.0 entry point has a different GUID --
defined in UEFI 2.5 -- pointing to it in the UEFI Configuration Table, and
guest kernels that lack upstream kernel commit e1ccbbc9d5 don't recognize
it.
The v2.1.0+ machine types of QEMU generate SMBIOS payload for the firmware
to install. The payload includes the entry point table ("anchor" table).
OvmfPkg/SmbiosPlatformDxe cannot install the anchor table (because that is
the jurisdiction of the generic "MdeModulePkg/Universal/SmbiosDxe"
driver); however, we can parse the entry point version from QEMU's anchor
table, and instruct "MdeModulePkg/Universal/SmbiosDxe" to adhere to that
version.
On machine types older than v2.1.0, the feature is not available, but
then, should anything in OVMF install SMBIOS tables, version 2.8 is simply
safer / more widely supported than 3.0 -- hence the default 2.8 value for
the dynamic PCD.
We set the PCD in PlatformPei (when not on the S3 resume path), because
that's an easy and certain way to set the PCD before a DXE driver reads
it. This follows the example of PcdEmuVariableNvStoreReserved (which is
read by EmuVariableFvbRuntimeDxe).
RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1232876
Cc: Gabriel Somlo <somlo@cmu.edu>
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>
Acked-by: Gabriel Somlo <somlo@cmu.edu>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17676 6f19259b-4bc3-4df7-8a09-765794883524
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
Make HostBridgeDevId global so MemMapInitialization() can also use it to
conditionally add RCRB MMIO address to HOB.
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@17600 6f19259b-4bc3-4df7-8a09-765794883524
SVN r15305 (git 5a217a06), "OvmfPkg: S3 Suspend: save boot script after
ACPI context", made this driver install gEfiDxeSmmReadyToLockProtocolGuid
in SaveS3BootScript() -- for valid reasons --, however in the INF file the
protocol was marked as "ALWAYS_CONSUMED". Fix 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@17437 6f19259b-4bc3-4df7-8a09-765794883524
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
All POWER_MGMT_REGISTER_PIIX4() macro invocations in OvmfPkg should use
the macros in "I440FxPiix4.h" as arguments.
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@17435 6f19259b-4bc3-4df7-8a09-765794883524
All POWER_MGMT_REGISTER_Q35() macro invocations in OvmfPkg should use the
macros in "Q35MchIch9.h" as arguments.
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@17434 6f19259b-4bc3-4df7-8a09-765794883524
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
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
When the Q35 machine type(s) of QEMU are used with libvirt, libvirt tends
to place some devices behind PCI bridges. This is then reflected in the
"bootorder" fw_cfg file. For example:
/pci@i0cf8/pci-bridge@1e/pci-bridge@1/scsi@5/disk@0,0
/pci@i0cf8/pci-bridge@1e/pci-bridge@1/scsi@3/channel@0/disk@0,0
As yet QemuBootOrderLib doesn't support such OFW device paths.
Add code that translates a sequence of pci-bridge nodes.
In practice libvirt seems to insert two such nodes (*), hence increment
EXAMINED_OFW_NODES with the same number.
(* Background, paraphrasing Laine Stump's words:
When the machine type is Q35, we create a dmi-to-pci bridge coming off of
the pcie root controller, and a pci-to-pci bridge coming off of that, then
attach most devices to the pci-to-pci bridge. This is done because you
can't hotplug into pcie-root, can't (or at least shouldn't) plug a
pci-to-pci bridge into pcie-root (so the next one has to be
dmi-to-pci-bridge), and can't hotplug into dmi-to-pci-bridge (so you need
to have a pci-to-pci bridge).)
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@17385 6f19259b-4bc3-4df7-8a09-765794883524
It is the responsibility of the SerialPortLib implementation
to deal with flow control if the underlying medium cannot keep
up with the inflow of data.
So in our SerialPortWrite () function, we should spin as long
as we need to in order to deliver all the data instead of giving
up and returning a smaller value than the number of bytes we were
given. Also, remove the 'if (Sent > 0)' condition on the signalling
of the event channel: if the buffer is full and we haven't been able
to add any more data, it makes perfect sense to signal the event
channel again, even if we have done so before when we did write
the data.
Also, this patch brings the implementation of XenSerialPortLib
in sync with the library class documentation.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
[lersek@redhat.com: replace DebugLib dependency with open-coded ASSERT()]
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17079 6f19259b-4bc3-4df7-8a09-765794883524
On PIIX4, function 3, the PMREGMISC register at offset 0x80, with
default value 0x00 has its bit 0 (PMIOSE) indicate whether the PM
IO space given in the PMBA register (offset 0x40) is enabled.
PMBA must be configured *before* setting this bit.
On Q35/ICH9+, function 0x1f, the equivalent role is fulfilled by
bit 7 (ACPI_EN) in the ACPI Control Register (ACPI_CNTL) at offset
0x44, also with a default value of 0x00.
Currently, OVMF hangs when Q35 reboots, because while PMBA is reset
by QEMU, the register at offset 0x80 (matching PMREGMISC on PIIX4)
is not reset, since it has a completely different meaning on LPC.
As such, the power management initialization logic in OVMF finds
the "PMIOSE" bit enabled after a reboot and decides to skip setting
PMBA. This causes the ACPI timer tick routine to read a constant
value from the wrong register, which in turn causes the ACPI delay
loop to hang indefinitely.
This patch modifies the Base[Rom]AcpiTimerLib constructors and the
PlatformPei ACPI PM init routines to use ACPI_CNTL:ACPI_EN instead
of PMREGMISC:PMIOSE when running on Q35.
Reported-by: Reza Jelveh <reza.jelveh@tuhh.de>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17076 6f19259b-4bc3-4df7-8a09-765794883524
QEMU commit aa685789 ("xhci: generate a Transfer Event for each Transfer
TRB with the IOC bit set") fixed an emulation problem in QEMU; we can now
drive that host controller with edk2's XhciDxe. Include it in OvmfPkg, as
XHCI emulation is reportedly more virtualization-friendly than EHCI,
consuming less CPU.
The driver can be tested with the following QEMU command line options:
-device nec-usb-xhci -device usb-kbd
This patch should not regress existing QEMU command lines (ie. trigger an
ASSERT() in XhciDxe that fails on pre-aa685789 QEMU) because QEMU's
"-device nec-usb-xhci" has never before resulted in USB devices that
worked with edk2 firmware builds, hence users have never had a reason to
add that option.
Now that they learn about XHCI support in OVMF by reading this commit
message, they (or their packagers) will also know to update qemu to
aa685789 or later (in practice that means the upcoming 2.3 release), at
least if they want to use '-device nec-usb-xhci' with edk2, for the first
time ever.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Alexander Graf <agraf@suse.de>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17055 6f19259b-4bc3-4df7-8a09-765794883524
XenHypercallLib has two clients at the moment: XenBusDxe and
XenConsoleSerialPortLib. Currently, when XenBusDxe starts on a non-Xen X86
platform (ie. as part of OVMF not running on Xen), the X86XenHypercallLib
instance built into it fails to initialize, which triggers an ASSERT() in
auto-generated code.
Instead, let's call XenHypercallIsAvailable() in the driver's entry point,
and exit cleanly when the driver is started on a non-Xen platform.
Modify the constructor of XenConsoleSerialPortLib similarly; we shouldn't
proceed if Xen is not available. In practice this check should never fail,
because XenConsoleSerialPortLib is only used on ARM, and
ArmXenHypercallLib is always available; but nonetheless we should be
pedantic.
Reported-by: Gabriel L. Somlo <gsomlo@gmail.com>
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@17001 6f19259b-4bc3-4df7-8a09-765794883524
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
In the next patch we'll add a simple query function to the XenHypercallLib
library class that is supposed to be called by initialization code in
modules. Among those, in constructors of dependent libraries too.
Library construction ordering is ensured only between libraries with
constructors, plus we shouldn't allow a dependent library with a
constructor to call into any XenHypercallLib instances (the simple query
function) before XenHypercallLib is constructed itself. For this reason,
introduce an (empty) constructor for ARM & AARCH64 too.
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@16999 6f19259b-4bc3-4df7-8a09-765794883524
Perform the following renames in order to stick with edk2 tradition more
closely:
XenHypercallLibArm, XenHypercallLibIntel -> XenHypercallLib
XenHypercallIntel -> X86XenHypercall
In addition, we unify the INF files.
This patch modifies ArmVirtualizationPkg and OvmfPkg at once, in order to
keep both bisectable (client code shouldn't break).
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@16998 6f19259b-4bc3-4df7-8a09-765794883524
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
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
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
This patch updates XenBusDxe to use the 16-bit compare and exchange
function that was introduced for this purpose to the
BaseSynchronizationLib. It also provides a new generic implementation
of TestAndClearBit () using the same 16-bit compare and exchange, making
this module fully architecture agnostic.
Contributed-under: TianoCore Contribution Agreement 1.0
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@16975 6f19259b-4bc3-4df7-8a09-765794883524
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
While Xen on Intel uses a virtual PCI device to communicate the
base address of the grant table, the ARM implementation uses a DT
node, which is fundamentally incompatible with the way XenBusDxe is
implemented, i.e., as a UEFI Driver Model implementation for a PCI
device.
Contributed-under: TianoCore Contribution Agreement 1.0
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@16973 6f19259b-4bc3-4df7-8a09-765794883524
Prepare for making XenBusDxe suitable for use with non-PCI devices
(such as the DT node exposed by Xen on ARM) by introducing a separate
DXE driver that binds to the Xen virtual PCI device and exposes the
abstract XENIO_PROTOCOL for XenBusDxe to bind against.
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@16972 6f19259b-4bc3-4df7-8a09-765794883524
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
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
This refactors the Xen hypercall implementation that is part of the
XenBusDxe driver, in preparation of splitting it off entirely into
a XenHypercallLib library. This involves:
- removing the dependency on XENBUS_DEVICE* pointers in the XenHypercall()
prototypes
- moving the discovered hyperpage address to a global variable
- moving XenGetSharedInfoPage() to its only user XenBusDxe.c (the shared info
page is not strictly part of the Xen hypercall interface, and is not used
by other expected users of XenHypercallLib such as the Xen console version
of SerialPortLib
- reimplement XenHypercall2() in C and move the indexing of the hyperpage
there; the existing asm implementations are renamed to __XenHypercall2() and
invoked from the new C implementation.
Contributed-under: TianoCore Contribution Agreement 1.0
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@16969 6f19259b-4bc3-4df7-8a09-765794883524
On ARM, xen_pfn_t is 64 bits but the size of a pointer is only
32 bits, so casting between them needs to go via (UINTN). Also
move the xen_pfn_t cast outside the shift so that we can avoid
shifting 64-bit quantities on 32-bit architectures, which may
require runtime library support.
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
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@16968 6f19259b-4bc3-4df7-8a09-765794883524
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
The only feature not portable to ArmVirtualizationQemu is the VBE shim;
make that dependent on Ia32 / X64.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Olivier Martin <Olivier.martin@arm.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16890 6f19259b-4bc3-4df7-8a09-765794883524
SVN r16411 delayed ACPI table installation until PCI enumeration was
complete, because on QEMU the ACPI-related fw_cfg files should have been
downloaded only after PCI enumeration. Said commit implemented the
dependency by tightening the module's depex.
This patch replaces the EFI_PCI_ENUMERATION_COMPLETE_PROTOCOL depex with a
matching protocol registration callback. The depex was static, and it
could not handle dynamically discovered situations when the dependency
would turn out invalid.
Namely:
- At the moment, the depex in "QemuFwCfgAcpiPlatformDxe.inf" assumes
that "ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationQemu.dsc"
lacks PCI support. However, PCI support is about to become run-time
discoverable on that platform. If PCI support is missing, then
ArmVirtualizationPkg will set PcdPciDisableBusEnumeration to TRUE.
Hence, when PcdPciDisableBusEnumeration is TRUE, we invalidate the
dependency by not registering the callback and installing the ACPI
tables right away.
- InitializeXen() in "OvmfPkg/PlatformPei/Xen.c" sets
PcdPciDisableBusEnumeration to TRUE. This causes
PciBusDriverBindingStart() in "MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.c"
to set gFullEnumeration to FALSE, which in turn makes PciEnumerator() in
"MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumerator.c" branch to
PciEnumeratorLight(). The installation of
EFI_PCI_ENUMERATION_COMPLETE_PROTOCOL at the end of PciEnumerator() is
not reached.
Which means that starting with SVN r16411, AcpiPlatformDxe is never
dispatched on Xen.
Hence, when PcdPciDisableBusEnumeration is TRUE, we invalidate the
dependency by not registering the callback and installing the ACPI
tables right away.
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: Removed PcdOvmfPciEnabled]
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16887 6f19259b-4bc3-4df7-8a09-765794883524
Currently the entry point functions of both driver builds
(AcpiPlatformDxe.inf and QemuFwCfgAcpiPlatformDxe.inf) directly contain
the logic that is different between the two builds.
Because we're going to restructure the entry point logic soon, we'd have
to duplicate the same new code between both entry point functions.
Push down the logic in which they differ to a new function:
- InstallAcpiTables() [AcpiPlatform.c]
- InstallAcpiTables() [QemuFwCfgAcpiPlatform.c]
and extract a common entry point function:
- AcpiPlatformEntryPoint() [EntryPoint.c]
which we can soon modify without code duplication.
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@16885 6f19259b-4bc3-4df7-8a09-765794883524
This name better aligns with InstallXenTables and InstallOvmfFvTables.
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@16884 6f19259b-4bc3-4df7-8a09-765794883524
Since this function also installs the tables, this is a better
name. It also aligns with the InstallXenTables name.
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@16883 6f19259b-4bc3-4df7-8a09-765794883524
Since the protocol is in the depex, there is no reason to expect we
might fail to locate the protocol.
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@16882 6f19259b-4bc3-4df7-8a09-765794883524
Having this entry point in QemuFwCfgAcpi.c should not cause a problem
for the other driver which supports Xen and older QEMU versions.
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@16880 6f19259b-4bc3-4df7-8a09-765794883524
Update OS Major number checking to future proof it, and default to
XCODE5 (clang + lldb).
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Andrew Fish <afish@apple.com>
Reviewed-by: Bruce Cran <bruce.cran@gmail.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16879 6f19259b-4bc3-4df7-8a09-765794883524
Before we launch the QEMU kernel, we should signal the ReadyToBoot
event.
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@16878 6f19259b-4bc3-4df7-8a09-765794883524
Insert a default, OVMF-specific Type 0 (BIOS Information) structure
into the SMBIOS table, unless the underlying guest VM supplies its
own, overriding instance.
As an example, QEMU, while allowing the user to specifically force
generation of a Type 0 structure, will not generate one by default,
considering that task to be the responsibility of the BIOS itself.
Based on an earlier out-of-tree patch by Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-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@16868 6f19259b-4bc3-4df7-8a09-765794883524
Implement new API DebugPrintLevelEnabled() to base on PCD PcdFixedDebugPrintErrorLevel.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16797 6f19259b-4bc3-4df7-8a09-765794883524
Use the example.com domain as recommended in RFC 2606.
NOTE: This does not modify the wording of the "TianoCore Contribution
Agreement 1.0" section
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Bruce Cran <bruce.cran@gmail.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16724 6f19259b-4bc3-4df7-8a09-765794883524
The code left behind in Qemu.c has some PCAT dependencies, and might
not be able to build on all platforms.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16696 6f19259b-4bc3-4df7-8a09-765794883524
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
Move libraries from ShellPkg into MdeModulePkg and MdePkg.
The following libraries are being migrated out of ShellPkg in order to make
their functionality more widely available.
• PathLib: Incorporate into MdePkg/Library/BaseLib
• FileHandleLib: MdePkg/Library/UefiFileHandleLib
• BaseSortLib: MdeModulePkg/Library/BaseSortLib
• UefiSortLib: MdeModulePkg/Library/UefiSortLib
Diffs showing file changes are in the attached file, LibMigration.patch.
A description of the changes follows:
• Move ShellPkg/Include/Library/FileHandleLib.h to MdePkg/Include/Library/FileHandleLib.h
• Move ShellPkg/Include/Library/SortLib.h to MdeModulePkg/Include/Library/SortLib.h
• Move ShellPkg/Library/BaseSortLib to MdeModulePkg/Library/BaseSortLib
• Move ShellPkg/Library/UefiSortLib to MdeModulePkg/Library/UefiSortLib
• Move ShellPkg/Library/BasePathLib/BasePathLib.c to MdePkg/Library/BaseLib/FilePaths.c
• Merge ShellPkg/Include/Library/PathLib.h into MdePkg/Include/Library/BaseLib.h
• Delete ShellPkg/Library/BasePathLib; Includes BasePathLib.c and BasePathLib.inf
• NetworkPkg/NetworkPkg.dsc
• PerformancePkg.dsc
• OvmfPkg/OvmfPkgX64.dsc
• OvmfPkg/OvmfPkgIa32X64.dsc
• OvmfPkg/OvmfPkgIa32.dsc
o Update SortLib and FileHandleLib library classes to point to the new library locations.
o Remove PathLib library class and make sure that BaseLib is described.
• MdeModulePkg/MdeModulePkg.dec
o Add SortLib library class
• MdePkg/MdePkg.dec
o Add FileHandleLib library class
o Add PcdUefiFileHandleLibPrintBufferSize PCD
• MdePkg/Library/BaseLib/BaseLib.inf
o Add FilePaths.c to [Sources]
• MdePkg/Include/Library/BaseLib.h
o Update file description to include "file path functions"
• ShellPkg/ShellPkg.dsc
o Change PACKAGE_GUID to { C1014BB7-4092-43D4-984F-0738EB424DBF }
o Update PACKAGE_VERSION to 1.0
o Update SortLib and FileHandleLib library classes to point to the new library locations.
o Remove PathLib library class and make sure that BaseLib is described.
o Remove ShellPkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf from [Components]
• ShellPkg/ShellPkg.dec
o Update PLATFORM_VERSION to 1.0
o Remove declarations of the FileHandleLib, SortLib, and PathLib Library Classes
o Update comment for the PcdShellPrintBufferSize PCD.
• ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib.inf
• ShellPkg/Application/Shell/Shell.inf
o Remove PathLib from [LibraryClasses]
• ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib.h
• ShellPkg/Application/Shell/Shell.h
o Remove #include <Library/PathLib.h>
• ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1CommandsLib.inf
o Add PathLib to [LibraryClasses]
• ShellPkg/Library/UefiShellLevel1CommandsLib/If.c
o Remove #include <Library/PathLib.h>
• ShellPkg/Application/ShellSortTestApp/ShellSortTestApp.inf
o Add MdeModulePkg/MdeModulePkg.dec to [Packages]
• MdeModulePkg/Library/BaseSortLib/BaseSortLib.inf
• MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf
o Replace ShellPkg.dec with MdeModulePkg.dec in [Packages]
• MdeModulePkg/Library/UefiSortLib/UefiSortLib.c
o Remove #include <ShellBase.h>
o Define USL_FREE_NON_NULL() to replace SHELL_FREE_NON_NULL()
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Daryl McDaniel <daryl.mcdaniel@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Erik Bjorge <erik.c.bjorge@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16601 6f19259b-4bc3-4df7-8a09-765794883524
The TranslateMmioOfwNodes() function recognizes the following OpenFirmware
device paths:
virtio-blk: /virtio-mmio@000000000a003c00/disk@0,0
virtio-scsi disk: /virtio-mmio@000000000a003a00/channel@0/disk@2,3
virtio-net NIC: /virtio-mmio@000000000a003e00/ethernet-phy@0
The new translation can be enabled with the
"PcdQemuBootOrderMmioTranslation" Feature PCD. This PCD also controls if
the "survival policy" covers unselected boot options that start with the
virtio-mmio VenHw() node.
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@16575 6f19259b-4bc3-4df7-8a09-765794883524
The OpenFirmware device path nodes that QEMU generates for virtio-mmio
transports contain 64-bit hexadecimal values (16 nibbles) -- the base
addresses of the register blocks. In order to parse them soon,
ParseUnitAddressHexList() must parse UINT64 values.
Call sites need to be adapted, as expected.
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@16574 6f19259b-4bc3-4df7-8a09-765794883524
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
In preparation for adding OpenFirmware-to-UEFI translation for "MMIO-like"
OFW device path fragments, let's turn the currently exclusive "PCI-like"
translation into "just one" of the possible translations.
- Rename TranslateOfwNodes() to TranslatePciOfwNodes(), because it is
tightly coupled to "PCI-like" translations.
- Rename REQUIRED_OFW_NODES to REQUIRED_PCI_OFW_NODES, because this macro
is specific to TranslatePciOfwNodes().
- Introduce a new wrapper function under the original TranslateOfwNodes()
name. This function is supposed to try translations in some order until
a specific translation returns a status different from
RETURN_UNSUPPORTED.
- Introduce a new Feature PCD that controls whether PCI translation is
attempted at all.
- The boot option "survival policy" in BootOrderComplete() must take into
account if the user was able to select PCI-like boot options. If the
user had no such possibility (because the Feature PCD was off for
PCI-like translation), then we ought to keep any such unselected boot
options.
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@16571 6f19259b-4bc3-4df7-8a09-765794883524
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
There are several network stack drivers in MdeModulePkg or NetworkPkg.
Currently, we only use the drivers from MdeModulePkg which only provides
the IPv4 support. This commit adds the IPv6 drivers in NetworkPkg into
OVMF.
Here is the table of drivers from Laszlo.
currently included related driver add or replace
from MdeModulePkg in NetworkPkg from NetworkPkg
------------------ -------------- ---------------
SnpDxe n/a n/a
DpcDxe n/a n/a
MnpDxe n/a n/a
VlanConfigDxe n/a n/a
ArpDxe n/a n/a
Dhcp4Dxe Dhcp6Dxe add
Ip4ConfigDxe Ip6Dxe add
Ip4Dxe Ip6Dxe add
Mtftp4Dxe Mtftp6Dxe add
Tcp4Dxe TcpDxe replace
Udp4Dxe Udp6Dxe add
UefiPxeBcDxe UefiPxeBcDxe replace
IScsiDxe IScsiDxe replace
Since the TcpDxe, UefiPxeBcDxe, and IScsiDxe drivers in NetworkPkg also
support IPv4, we replace the ones in MdeModulePkg.
To enable the IPv6 support, build OVMF with "-D NETWORK_IP6_ENABLE".
A special case is NetworkPkg/IScsiDxe. It requires openssl. For convenience,
NetworkPkg/IScsiDxe is enabled only if both IPv6 and SecureBoot are enabled.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gary Lin <glin@suse.com>
[lersek@redhat.com: typo fix in commit message; specil -> special]
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16543 6f19259b-4bc3-4df7-8a09-765794883524
SVN r16375 (git commit 72a11001, "OvmfPkg: CsmSupportLib: Set/use platform
specific legacy interrupt device") added the
gUefiOvmfPkgTokenSpaceGuid.PcdOvmfHostBridgePciDevId
PCD to CsmSupportLib. Since that "namespace" GUID is declared in
OvmfPkg/OvmfPkg.dec, and we've not used anything from OvmfPkg/OvmfPkg.dec
in CsmSupportLib.inf thus far, this is a new [Packages] dependency and
must be named.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16414 6f19259b-4bc3-4df7-8a09-765794883524
The ACPI payload that OVMF downloads from QEMU via fw_cfg depends on the
PCI enumaration and resource assignment performed by
MdeModulePkg/Bus/Pci/PciBusDxe.
Namely, although the ACPI payload is pre-generated in qemu during machine
initialization, in
main() [vl.c]
qemu_run_machine_init_done_notifiers()
pc_guest_info_machine_done() [hw/i386/pc.c]
acpi_setup() [hw/i386/acpi-build.c]
acpi_build()
acpi_add_rom_blob()
rom_add_blob(... acpi_build_update ...) [hw/core/loader.c]
fw_cfg_add_file_callback() [hw/nvram/fw_cfg.c]
the ACPI data is rebuilt at the first time any of the related fw_cfg files
are read, through the acpi_build_update() fw_cfg read-callback function:
fw_cfg_read() [hw/nvram/fw_cfg.c]
acpi_build_update() [hw/i386/acpi-build.c]
acpi_build()
(See qemu commit d87072ceeccf4f84a64d4bc59124bcd64286c070 and its
containing series.)
For this reason we must not dispatch AcpiPlatformDxe before PciBusDxe
completes the enumeration.
Luckily, the PI Specification 1.3 defines
EFI_PCI_ENUMERATION_COMPLETE_GUID in Volume 5, "10.9 End of PCI
Enumeration Overview", as an indicia to inform the platform when the PCI
enumeration process has completed. PciBusDxe installs this protocol at the
end of the PciEnumerator() function.
Let's add this GUID to the Depex section of AcpiPlatformDxe, in order to
state the dependency explicitly.
On Xen, and on older QEMU where the linker/loader fw_cfg interface is
unavailable, this introduces a harmless ordering constraint -- we'll
always include PciBusDxe in OVMF, so the dependency will always be
satisfied.
I tested this change as follows:
- I dumped the ACPI tables in a Fedora 20 guest, before and after the
change, and compared them. The only thing that actually changed was the
FACS address. (Which I promptly tested with S3 suspend/resume.) Plus, of
course, the FACP checksum changed, because the FACP links the FACS.
- Tested S3 in my Windows Server 2008 R2 and Windows Server 2012 R2 guests.
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@16411 6f19259b-4bc3-4df7-8a09-765794883524
Remove hard-coded list of PCI devices for which the Interrupt Line
register is initialized. Instead, provide a "visitor" function to
initialize the register only for present and applicable PCI devices.
At this time, we match the behavior of SeaBIOS (file src/fw/pciinit.c,
functions *_pci_slot_get_irq() and "map the interrupt" block from
pci_bios_init_device()).
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16398 6f19259b-4bc3-4df7-8a09-765794883524
The fix, having "lock" and the locked instruction on the same line in
the source.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Build-tested-by: Scott Duplichan <scott@notabs.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16394 6f19259b-4bc3-4df7-8a09-765794883524
This patch contain type casts and replace one * operation by a
MultU64x32() call.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Scott Duplichan <scott@notabs.org>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Build-tested-by: Scott Duplichan <scott@notabs.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16393 6f19259b-4bc3-4df7-8a09-765794883524
This patch contain only type cast.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Scott Duplichan <scott@notabs.org>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Build-tested-by: Scott Duplichan <scott@notabs.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16392 6f19259b-4bc3-4df7-8a09-765794883524
This patch replace some types in GrantTable and the argument Index of
XenHypercallHvmGetParam to what the types should be.
This avoid to have type cast in code.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Build-tested-by: Scott Duplichan <scott@notabs.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16391 6f19259b-4bc3-4df7-8a09-765794883524
Since a message to XenStore have a lenght of type UINT32, have
XenStore.c deal only with UINT32 instead of a mixmatch with UINTN.
This patch replaces the type of Len in WRITE_REQUEST and the type of the
argument Len of XenStoreWriteStore and XenStoreReadStore.
This patch should avoid to have type cast were it does not make sense to
have them.
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>
Build-tested-by: Scott Duplichan <scott@notabs.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16390 6f19259b-4bc3-4df7-8a09-765794883524
"Lun" has type UINT64 in this function. The result of the expression
(UINT8) ((Lun >> 8) | 0x40)
depends only on bits [15:8] of "Lun", therefore we can cast "Lun" to
UINT32 before shifting it.
This eliminates an intrinsic when building with VS2010 for Ia32 / NOOPT.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Scott Duplichan <scott@notabs.org>
[lersek@redhat.com: added commit message]
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Build-tested-by: Scott Duplichan <scott@notabs.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16386 6f19259b-4bc3-4df7-8a09-765794883524
The SegmentC local variable has type EFI_PHYSICAL_ADDRESS for (justified)
style reasons. However, the 64-bit bit-shifts that it undergoes result in
intrinsic calls when built with VS2010 for Ia32 / NOOPT.
The concrete value of SegmentC, 0xC0000, and the results of the bitops
that are based on it, are statically computeable. Cast SegmentC to UINT32
before subjecting it to bitwise operations; we can see in advance that
this won't lead to range loss.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Scott Duplichan <scott@notabs.org>
[lersek@redhat.com: dropped now superfluous outermost parens; commit msg]
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Build-tested-by: Scott Duplichan <scott@notabs.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16385 6f19259b-4bc3-4df7-8a09-765794883524
The current types of subexpressions used in QemuFlashPtr() are as follows.
(We also show the types of "larger" subexpressions, according to operator
binding.)
mFlashBase + (Lba * mFdBlockSize) + Offset
^ ^ ^ ^
| | | |
(UINT8*) EFI_LBA UINTN UINTN
(UINT64)
--------------------------------- ------
(UINT8*) UINTN
------------------------------------------
(UINT8*)
When building with VS2010 for Ia32 / NOOPT, the 64-by-32 bit
multiplication is translated to an intrinsic, which is not allowed in
edk2.
Recognize that "Lba" is always bounded by "mFdBlockCount" (an UINTN) here
-- all callers of QemuFlashPtr() ensure that. In addition, the flash chip
in question is always under 4GB, which is why we can address it at all on
Ia32. Narrow "Lba" to UINTN, without any loss of range.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Scott Duplichan <scott@notabs.org>
[commit message by lersek@redhat.com]
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Build-tested-by: Scott Duplichan <scott@notabs.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16384 6f19259b-4bc3-4df7-8a09-765794883524
In the InitializeVariableFvHeader() function, all three of "Offset",
"Start" and "BlockSize" have type UINTN. Therefore the (Offset /
BlockSize) and (Start / BlockSize) divisions can be compiled on all
platforms without intrinsics.
In the current expressions
(EFI_LBA) Offset / BlockSize
(EFI_LBA) Start / BlockSize
"Offset" and "Start" are cast to UINT64 (== EFI_LBA), which leads to
64-by-32 bit divisions on Ia32, breaking the VS2010 / NOOPT / Ia32 build.
The simplest way to fix them is to realize we don't need casts at all.
(The prototypes of QemuFlashEraseBlock() and QemuFlashWrite() are visible
via "QemuFlash.h", and they will easily take our UINTN quotients as
UINT64.)
Suggested-by: Scott Duplichan <scott@notabs.org>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Build-tested-by: Scott Duplichan <scott@notabs.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16383 6f19259b-4bc3-4df7-8a09-765794883524
The MarkMemoryRangeForRuntimeAccess() function passes the Length parameter
(of type UINT64) to the macro EFI_SIZE_TO_PAGES(). When building for the
Ia32 platform, this violates the interface contract of the macro:
[...] Passing in a parameter that is larger than UINTN may produce
unexpected results.
In addition, it trips up compilation by VS2010 for the Ia32 platform and
the NOOPT target -- it generates calls to intrinsics, which are not
allowed in edk2.
Fix both issues with the following steps:
(1) Demote the Length parameter of MarkMemoryRangeForRuntimeAccess() to
UINTN. Even a UINT32 value is plenty for representing the size of the
flash chip holding the variable store. Length parameter is used in the
following contexts:
- passed to gDS->RemoveMemorySpace() -- takes an UINT64
- passed to gDS->AddMemorySpace() -- ditto
- passed to EFI_SIZE_TO_PAGES() -- requires an UINTN. This also guarantees
that the return type of EFI_SIZE_TO_PAGES() will be UINTN, hence we can
drop the outer cast.
(2) The only caller of MarkMemoryRangeForRuntimeAccess() is
FvbInitialize(). The latter function populates the local Length variable
(passed to MarkMemoryRangeForRuntimeAccess()) from
PcdGet32(PcdOvmfFirmwareFdSize). Therefore we can simply demote the local
variable to UINTN in this function as well.
- There's only one other use of Length in FvbInitialize(): it is passed to
GetFvbInfo(). GetFvbInfo() takes an UINT64, so passing an UINTN is fine.
Suggested-by: Scott Duplichan <scott@notabs.org>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Build-tested-by: Scott Duplichan <scott@notabs.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16382 6f19259b-4bc3-4df7-8a09-765794883524
Merge PciInitialization() and AcpiInitialization() into a single
function, PciAcpiInitialization(), and use a PCD set during PEI to
detect the underlying platform type (PIIX4 or Q35/MCH) and therefore
the addresses of the registers to be initialized.
Add LNK[A-H] routing target initialization for the Q35 platform.
Additionally, initialize PCI_INTERRUPT_LINE registers for the typical
set of PCI devices included by QEMU with the Q35 machine type. The
corresponding PIIX4 initialization of PCI_INTERRUPT_LINE registers is
cleaned up and the list of PIIX4 PCI devices updated to the list
typically included with QEMU.
NOTE: The list of PCI devices for which we initialize PCI_INTERRUPT_LINE
is hard-coded, and, depending on how QEMU devices are configured on
the command line, may miss some devices, or (harmlessly) attempt to
initialize devices which are not present in the system. A subsequent
patch will replace this hard-coded list with a mechanism to correctly
initialize PCI_INTERRUPT_LINE for applicable present PCI devices only.
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>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16379 6f19259b-4bc3-4df7-8a09-765794883524
Link DXE_SMM_DRIVER, UEFI_DRIVER, UEFI_APPLICATION, and SMM_CORE against
a valid, non-asserting version of PcdLib, then switch them over to using
the "Dxe" instance of AcpiTimerLib (instead of the "Base" version).
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-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@16378 6f19259b-4bc3-4df7-8a09-765794883524
Since in OVMF both PEI_CORE and PEIM run from RAM, and thus may
utilize global variables, use the "Base" AcpiTimerLib instance
(instead of BaseRom) to take advantage of the improved efficiency
of storing the timer register IO address in a global variable.
This leaves only SEC using the BaseRomAcpiTimerLib instance.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-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@16377 6f19259b-4bc3-4df7-8a09-765794883524
Remove local power management register access macros in favor of
factored-out ones in OvmfPkg/Include/OvmfPlatforms.h
Next, AcpiTimerLib is split out into three instances, for use during
various stages:
- BaseRom: used during SEC, PEI_CORE, and PEIM;
- Dxe: used during DXE_DRIVER and DXE_RUNTIME_DRIVER;
- Base: used by default during all other stages.
Most of the code remains in AcpiTimerLib.c, to be shared by all
instances. The two platform-dependent methods (constructor and
InternalAcpiGetTimerTick) are provided separately by source files
specific to each instance, namely [BaseRom|Base|Dxe]AcpiTimerLib.c.
Since pre-DXE stages can't rely on storing data in global variables,
methods specific to the "BaseRom" instance will call platform
detection macros each time they're invoked.
The "Base" instance calls platform detection macros only from its
constructor, and caches the address required by InternalAcpiTimerTick
in a global variable.
The "Dxe" instance is very similar to "Base", except no platform
detection macros are called at all; instead, the platform type is
read via a dynamic PCD set from PlatformPei.
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>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16376 6f19259b-4bc3-4df7-8a09-765794883524
Use a PCD set from PEI to determine the legacy interrupt device
number appropriate for the underlying platform type during protocol
initialization.
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@16375 6f19259b-4bc3-4df7-8a09-765794883524
Set from PEI, this PCD allows subsequent stages (specifically
DXE_DRIVER and DXE_RUNTIME_DRIVER) to infer the underlying platform
type (e.g. PIIX4 or Q35/MCH) without the need to further query the
Host Bridge for its 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@16374 6f19259b-4bc3-4df7-8a09-765794883524
Set up ACPI power management using registers determined based on
the underlying (PIIX4 or Q35/MCH) platform type.
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@16373 6f19259b-4bc3-4df7-8a09-765794883524
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
EDK II code should not include system include files.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16341 6f19259b-4bc3-4df7-8a09-765794883524
The BaseTools/Scripts/ConvertMasmToNasm.py script was used to convert
X64/TestAndClearBit.asm to X64/TestAndClearBit.nasm
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@16319 6f19259b-4bc3-4df7-8a09-765794883524
The BaseTools/Scripts/ConvertMasmToNasm.py script was used to convert
X64/InterlockedCompareExchange16.asm to X64/InterlockedCompareExchange16.nasm
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@16318 6f19259b-4bc3-4df7-8a09-765794883524
The BaseTools/Scripts/ConvertMasmToNasm.py script was used to convert
X64/hypercall.asm to X64/hypercall.nasm
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@16317 6f19259b-4bc3-4df7-8a09-765794883524
The BaseTools/Scripts/ConvertMasmToNasm.py script was used to convert
Ia32/TestAndClearBit.asm to Ia32/TestAndClearBit.nasm
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@16316 6f19259b-4bc3-4df7-8a09-765794883524
The BaseTools/Scripts/ConvertMasmToNasm.py script was used to convert
Ia32/InterlockedCompareExchange16.asm to Ia32/InterlockedCompareExchange16.nasm
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@16315 6f19259b-4bc3-4df7-8a09-765794883524
The BaseTools/Scripts/ConvertMasmToNasm.py script was used to convert
Ia32/hypercall.asm to Ia32/hypercall.nasm
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@16314 6f19259b-4bc3-4df7-8a09-765794883524
On a physical screen such a low graphics resolution would lead to huge
glyphs (the text resolution is 80x25, centered, with 8x19 pixel glyphs).
But in a virtual machine it just saves screen real estate on the client,
by removing the black bands.
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@16311 6f19259b-4bc3-4df7-8a09-765794883524
PlatformBdsEnterFrontPage() already implements a keypress wait (for
entering the setup utility at boot) with a nice progress bar, only OVMF
has not been using it.
Removing our custom code and utilizing PlatformBdsEnterFrontPage()'s
builtin wait has the following benefits:
- It simplifies OVMF's BDS code.
- Because now we call PlatformBdsEnterFrontPage() unconditionally, it
actually has a chance to look at the EFI_OS_INDICATIONS_BOOT_TO_FW_UI
bit of the "OsIndications" variable, improving compliance with the UEFI
specification. References:
- https://bugzilla.redhat.com/show_bug.cgi?id=1153927
- http://thread.gmane.org/gmane.comp.bios.tianocore.devel/10487
- The progress bar looks nice. (And it keeps the earlier behavior intact,
when the user presses a key on the TianoCore splash screen.)
In any case, we set the timeout to 0 (which doesn't show the progress
bar and proceeds to the boot options immediately) in order to keep the
boot time down.
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@16310 6f19259b-4bc3-4df7-8a09-765794883524
This is again obviated by our earlier BdsLibConnectAll() call.
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@16309 6f19259b-4bc3-4df7-8a09-765794883524
The second parameter of said function is "ConnectAllHappened", and if set
to TRUE, the function sets "gConnectAllHappened" to TRUE.
This global variable in turn controls whether Intel BDS code *itself*
calls BdsLibConnectAllDriversToAllControllers() in various places -- if
the indicator is TRUE, then the "connect all" is assumed to have been
performed, and Intel BDS doesn't do it itself.
OVMF should pass TRUE as "ConnectAllHappened", because a few lines before
our call to PlatformBdsEnterFrontPage(), we already connect everything
with BdsLibConnectAll(), which includes the effects of
BdsLibConnectAllDriversToAllControllers():
PlatformBdsPolicyBehavior() [OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c]
BdsLibConnectAll() [IntelFrameworkModulePkg/Library/GenericBdsLib/BdsConnect.c]
BdsLibConnectAllDriversToAllControllers()
PlatformBdsEnterFrontPage() [IntelFrameworkModulePkg/Universal/BdsDxe/FrontPage.c]
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@16308 6f19259b-4bc3-4df7-8a09-765794883524
The PlatformBdsEnterFrontPage() function's first parameter,
"TimeoutDefault", determines the behavior of the setup utility:
- If (TimeoutDefault == 0), then the usual boot order is to be acted upon
immediately.
- If (TimeoutDefault == 0xFFFF), then the setup utility is entered
unconditionally.
- If (0 < TimeoutDefault && TimeoutDefault < 0xFFFF), then the
PlatformBdsEnterFrontPage() function displays a progress bar, waiting
for TimeoutDefault seconds. If the user presses a key, then the setup
utility is entered, otherwise the normal boot option processing takes
place.
The TimeoutDefault parameter is supposed to be set from
gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdPlatformBootTimeOut
which has the following (matching) documentation in
"IntelFrameworkModulePkg/IntelFrameworkModulePkg.dec":
The number of seconds that the firmware will wait before initiating the
original default boot selection.
A value of 0 indicates that the default boot selection is to be
initiated immediately on boot.
The value of 0xFFFF then firmware will wait for user input before
booting.
OVMF does this actually -- see the Timeout variable in
PlatformBdsPolicyBehavior() -- but right before calling
PlatformBdsEnterFrontPage(), OVMF hardwires TimeoutDefault to 0xFFFF.
This has been acceptable until now, because OVMF implements its own "wait
for keypress at the splash screen" logic in PlatformBdsPolicyBehavior(),
completely avoiding the progress bar mentioned above. OVMF only calls
PlatformBdsEnterFrontPage() when the user presses a key during its own
"splash screen wait", and *then* it indeed makes sense to enter the setup
utility unconditionally.
However, even that way, the
Timeout = 0xffff;
assignment is superfluous, because 0xFFFF is already the default value of
PcdPlatformBootTimeOut in "IntelFrameworkModulePkg.dec", and OvmfPkg
doesn't override it in its DSC 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@16307 6f19259b-4bc3-4df7-8a09-765794883524
This call has been dead since the conception of OvmfPkg (git commit
49ba9447 / SVN r8398), and only confuses readers -- let's remove 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@16305 6f19259b-4bc3-4df7-8a09-765794883524
Update to show what the patch looks like in email form.
NOTE: This does not modify the wording of the "TianoCore Contribution
Agreement 1.0" section
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16297 6f19259b-4bc3-4df7-8a09-765794883524
.. to avoid the use .member = value syntax as VS does not support it.
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@16296 6f19259b-4bc3-4df7-8a09-765794883524
.. to avoid the use .member = value syntax as VS does not support it.
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@16295 6f19259b-4bc3-4df7-8a09-765794883524
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
The BaseTools/Scripts/ConvertMasmToNasm.py script was used to convert
X64/IoLibExAsm.asm to X64/IoLibExAsm.nasm
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@16290 6f19259b-4bc3-4df7-8a09-765794883524
The BaseTools/Scripts/ConvertMasmToNasm.py script was used to convert
Ia32/IoLibExAsm.asm to Ia32/IoLibExAsm.nasm
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@16289 6f19259b-4bc3-4df7-8a09-765794883524
The BaseTools/Scripts/ConvertMasmToNasm.py script was used to convert
X64/JumpToKernel.asm to X64/JumpToKernel.nasm
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@16288 6f19259b-4bc3-4df7-8a09-765794883524
The BaseTools/Scripts/ConvertMasmToNasm.py script was used to convert
Ia32/JumpToKernel.asm to Ia32/JumpToKernel.nasm
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@16287 6f19259b-4bc3-4df7-8a09-765794883524
Implement the BlockIo protocol.
Change in V4:
- Replace the license by the commonly used file header text.
Change in V3:
- assert(Media->BlockSize % 512 == 0)
- Use Sector instead of Offset to issue IOs.
Change in V2:
- Remove blockIo2 headers.
- Fix few comment.
- file header, copyright
- Rewrite few comment and error messages
- No more callback
- Improving block read/write, increase to the max size in one request
(instead of only 8pages)
- Fix lastblock when it's a cdrom
- Do uninitialisation when fail to install fail
- few comment
- Licenses
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@16274 6f19259b-4bc3-4df7-8a09-765794883524
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
A ParaVirtualize block driver.
Change in V4:
- Replace the license by the commonly used file header text.
- Add brief description for the driver.
Change in V3:
- enable compilation for Ia32 and Ia32X64
- fix version (driver binding)
Change in V2:
- Add minimal support for controller name
- Remove stuff about BlockIo2
- Little cleanup
- Licenses and file headers
- Rename XenbusIo into XenBusIo
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@16272 6f19259b-4bc3-4df7-8a09-765794883524
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
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
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
.. because we need it in the patch titled:
"OvmfPkg/XenBusDxe: Introduce XenBus support itself."
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>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16268 6f19259b-4bc3-4df7-8a09-765794883524
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
This atomically test's and clear's a bit.
Change in V3:
- adding IA32 support. (not yet reviewed)
both XenBusDxe/Ia32/TestAndClearBit.{S,asm} are new
Change in V2:
- Adding .asm version
- Comment the function
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>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16266 6f19259b-4bc3-4df7-8a09-765794883524
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
There are used to grant access of pages to other Xen domains.
This code originaly comes from the Xen Project, and more precisely from
MiniOS.
Change in V4:
- Add license to GrantTable.h
Change in V3:
- Add a comment about the use of the BAR of the device.
Change in V2:
- Adding locks
- Redo the file header
- Add functions comment
- Add license
Signed-off-by: Steven Smith <sos22@cam.ac.uk>
Signed-off-by: Grzegorz Milos <gm281@cam.ac.uk>
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@16264 6f19259b-4bc3-4df7-8a09-765794883524
This patch is inspired by InterlockedCompareExchange32 from the
BaseSynchronizationLib.
The function will be used in the "OvmfPkg/XenBusDxe: Add Grant Table
functions" patch.
Change in V3:
- Implement both .S and .asm, to get rid of GCC specific asm.
- Implement 32bit part of the assembly
Change in V2:
- Add intel compilation code
MSFT code is not compied over because I don't know how it works.
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@16263 6f19259b-4bc3-4df7-8a09-765794883524
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
The PciIo interface will be used in "OvmfPkg/XenBusDxe: Add Grant Table
functions" to get the memory address of the BAR 1 and use the space to
map shared memory.
Change in V3:
- add a commit description.
Change in V2:
- Coding style
- Error handler
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@16261 6f19259b-4bc3-4df7-8a09-765794883524
The ExitBoot event is used to disconnect from the device before the
next operating system start using them.
Change in V3:
- use the variable mMyDevice to prevent the driver from
starting twice (if there is two different PCI devices).
- free(dev) on exit
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@16259 6f19259b-4bc3-4df7-8a09-765794883524
This includes Component Name and Driver Binding.
Change in V4:
- Replace the license by the commonly used file header text.
- Add brief description for the driver.
Change in V3:
- enable compilation for Ia32 and Ia32X64
- fix version (driver binding)
Change in V2:
- Simple support of controller name.
- Cleaning up comments, files header.
- Add Licenses
- Rename XenbusDxe to XenBusDxe.
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>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16258 6f19259b-4bc3-4df7-8a09-765794883524
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
The MIT license will be used for several source files that are necessary
for the Xen PV drivers. So this patch makes it explicit by adding the
license with a note about which directory will have source files under
this license.
Change in V3:
New patch
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@16256 6f19259b-4bc3-4df7-8a09-765794883524
In the previous patch we disabled its use; there are no more clients.
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: Gary Lin <glin@suse.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16192 6f19259b-4bc3-4df7-8a09-765794883524
OvmfPkg forked SecureBootConfigDxe from SecurityPkg in SVN r13635 (git
commit 8c71ec8f). Since then, the original (in
"SecurityPkg/VariableAuthenticated/SecureBootConfigDxe") has diverged
significantly.
The initial diff between the original and the fork, when the fork was made
(ie. at SVN r13635), reads as follows:
> diff -ur SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfig.vfr OvmfPkg/SecureBootConfigDxe/SecureBootConfig.vfr
> --- SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfig.vfr 2014-09-30 23:35:28.598067147 +0200
> +++ OvmfPkg/SecureBootConfigDxe/SecureBootConfig.vfr 2014-08-09 02:40:35.824851626 +0200
> @@ -51,7 +51,7 @@
> questionid = KEY_SECURE_BOOT_ENABLE,
> prompt = STRING_TOKEN(STR_SECURE_BOOT_PROMPT),
> help = STRING_TOKEN(STR_SECURE_BOOT_HELP),
> - flags = INTERACTIVE | RESET_REQUIRED,
> + flags = INTERACTIVE,
> endcheckbox;
> endif;
>
> @@ -158,7 +158,7 @@
> questionid = KEY_SECURE_BOOT_DELETE_PK,
> prompt = STRING_TOKEN(STR_DELETE_PK),
> help = STRING_TOKEN(STR_DELETE_PK_HELP),
> - flags = INTERACTIVE | RESET_REQUIRED,
> + flags = INTERACTIVE,
> endcheckbox;
> endif;
> endform;
> diff -ur SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf OvmfPkg/SecureBootConfigDxe/SecureBootConfigDxe.inf
> --- SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf 2014-09-30 23:35:28.598067147 +0200
> +++ OvmfPkg/SecureBootConfigDxe/SecureBootConfigDxe.inf 2014-09-30 23:35:28.577067027 +0200
> @@ -1,5 +1,8 @@
> ## @file
> -# Component name for SecureBoot configuration module.
> +# Component name for SecureBoot configuration module for OVMF.
> +#
> +# Need custom SecureBootConfigDxe for OVMF that does not force
> +# resets after PK changes since OVMF doesn't have persistent variables
> #
> # Copyright (c) 2011 - 2012, Intel Corporation. All rights reserved.<BR>
> # This program and the accompanying materials
> diff -ur SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.c OvmfPkg/SecureBootConfigDxe/SecureBootConfigImpl.c
> --- SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.c 2014-09-30 23:35:28.599067153 +0200
> +++ OvmfPkg/SecureBootConfigDxe/SecureBootConfigImpl.c 2014-09-30 23:35:28.578067033 +0200
> @@ -2559,7 +2559,7 @@
> NULL
> );
> } else {
> - *ActionRequest = EFI_BROWSER_ACTION_REQUEST_RESET;
> + *ActionRequest = EFI_BROWSER_ACTION_REQUEST_SUBMIT;
> }
> break;
The commit message is not overly verbose:
OvmfPkg: Add custom SecureBootConfigDxe that doesn't reset
We don't force a platform reset for OVMF when PK is changed in custom
mode setup.
But the INF file hunk is telling:
Need custom SecureBootConfigDxe for OVMF that does not force resets
after PK changes since OVMF doesn't have persistent variables
We do have persistent variables now. Let's disable the (now obsolete)
OvmfPkg fork, and revert to the (well maintained) SecurityPkg-provided
config driver.
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: Gary Lin <glin@suse.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16191 6f19259b-4bc3-4df7-8a09-765794883524
Recent changes in the QEMU ACPI table generator have shown that our
limited client for that interface is insufficient and/or brittle.
Implement the full interface utilizing OrderedCollectionLib for addressing
fw_cfg blobs by name.
In order to stay compatible with EFI_ACPI_TABLE_PROTOCOL, we don't try to
identify QEMU's RSD PTR and link it into the UEFI system configuration
table. Instead, once all linker/loader commands have been processed, we
process the AddPointer commands for a second time.
In the second pass, we look at the targets of these pointer commands. The
key idea (by Michael Tsirkin) is that any ACPI interpreter will only be
able to locate ACPI tables by following absolute pointers, hence QEMU's
set of AddPointer commands will cover all of the ACPI tables (and more,
see below).
Some of QEMU's AddPointer commands (ie. some fields in ACPI tables) may
point to areas in fw_cfg blobs that are not ACPI tables themselves.
Examples are the BGRT.ImageAddress field, and the TCPA.LASA field. We tell
these apart from ACPI tables by performing the following checks on pointer
target "candidates":
- length check against minimum ACPI table size, and remaining blob size
- checksum verification.
If a target area looks like an ACPI table, and is different from RSDT and
DSDT (which EFI_ACPI_TABLE_PROTOCOL handles internally), we install the
table (at which point EFI_ACPI_TABLE_PROTOCOL creates a deep copy of the
relevant segment of the pointed-to fw_cfg blob).
Simultaneously, we keep account if each fw_cfg blob has ever been
referenced as the target of an AddPointer command without that AddPointer
command actually identifying an ACPI table. In this case the containing
fw_cfg file (of AcpiNVS memory type) must remain around forever, because
we never install that area with EFI_ACPI_TABLE_PROTOCOL, but some field in
some ACPI table that we *do* install still references it, by the absolute
address that we've established during the first pass.
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@16158 6f19259b-4bc3-4df7-8a09-765794883524
In the next patch we rewrite the client code for QEMU's fw_cfg ACPI table
loader interface. In order to avoid randomly intermixed hunks in that
patch, first remove the old code cleanly.
We remove the InstallQemuLinkedTables() function and empty the
InstallAllQemuLinkedTables() function. We also remove CheckRsdp().
InstallAllQemuLinkedTables() will return constant EFI_NOT_FOUND to
AcpiPlatformEntryPoint(), causing the latter to proceed to OVMF's builtin
tables.
This way the history remains bisectable and the new client gets a clean
start in the next 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@16157 6f19259b-4bc3-4df7-8a09-765794883524
We used to state in this header file that we only cared about the Allocate
command. This is no longer the case; update the comments accordingly.
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@16156 6f19259b-4bc3-4df7-8a09-765794883524
The "complete" QEMU fw_cfg ACPI loader will need to look up downloaded
blobs by name, in order to implement the AddPointer and AddChecksum
commands. Introduce OrderedCollectionLib to support such indexing.
BaseOrderedCollectionRedBlackTreeLib is a BASE module, hence add the
OrderedCollectionLib resolution to the main [LibraryClasses] section.
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@16155 6f19259b-4bc3-4df7-8a09-765794883524
SVN r16092 ('ShellPkg: Add a new library for "bcfg" command') introduced a
new library class (and an instance for it) called BcfgCommandLib.
SVN r16093 ('ShellPkg: Use the new library for "bcfg" command') rebased
ShellPkg to the new library, introducing a new [LibraryClasses]
dependency.
Library classes must be resolved to library instances in client platform
descriptions (DSC's). Since OVMF is a client platform, import the same
library resolution as seen in "ShellPkg/ShellPkg.dsc" (added in SVN
r16092).
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16095 6f19259b-4bc3-4df7-8a09-765794883524
Pick the appropriate bus:dev.fn for accessing ACPI power management
registers (00:01.3 on PIIX4 vs. 00:1f.0 on Q35) based on the device
ID of the host bridge (assumed always present at 00:00.0).
With this patch, OVMF can boot QEMU's "-machine q35" x86 machine type.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gabriel Somlo <somlo@cmu.edu>
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@16066 6f19259b-4bc3-4df7-8a09-765794883524
When setting up the list of GOP modes offered on QEMU's stdvga ("VGA") and
QXL ("qxl-vga") video devices, QemuVideoBochsModeSetup() filters those
modes against the available framebuffer size. (Refer to SVN r15288 / git
commit ec88061e.)
The VBE_DISPI_INDEX_VIDEO_MEMORY_64K register of both stdvga and QXL is
supposed to report the size of the drawable, VGA-compatibility
framebuffer. Instead, up to and including qemu-2.1, this register actually
reports the full video RAM (PCI BAR 0) size.
In case of stdvga, this happens to be correct, because on that card the
full PCI BAR 0 is usable for drawing; there is no difference between
"drawable framebuffer size" and "video RAM (PCI BAR 0) size".
However, on the QXL card, only an initial portion of the video RAM is
suitable for drawing, as compatibility framebuffer; and the value
currently reported by VBE_DISPI_INDEX_VIDEO_MEMORY_64K overshoots the
valid size. Beyond the drawable range, the video RAM contains buffers and
structures for the QXL guest-host protocol.
Luckily, the size of the drawable QXL framebuffer can also be read from a
register in the QXL ROM BAR (PCI BAR 2), so let's retrieve it from there.
Without this fix, OVMF offers too large resolutions on the QXL card (up to
the full size of the video RAM). If a GOP client selects such a resolution
and draws into the video RAM past the compatibility segment, then the
guest corrupts its communication structures (which is invalid guest
behavior).
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15978 6f19259b-4bc3-4df7-8a09-765794883524
We strongly prefer that contribtions be offered using the same license
as the project/module. But, we should document other acceptable
licenses for contributions.
This will allow package owners to more easily know if they can accept
a contribution under a different source license.
NOTE: This does not modify the wording of the "TianoCore Contribution
Agreement 1.0" section
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Mark Doran <mark.doran@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15892 6f19259b-4bc3-4df7-8a09-765794883524
Jiaxin Wu
Ruiyu Ni
Bruce Cran
Jordan Justen
Laszlo Ersek
Star Zeng
Gerd Hoffmann
Paulo Alcantara
Ard Biesheuvel
Gabriel Somlo
Andrew Fish
Liming Gao
Daryl McDaniel
Gary Lin
Scott Duplichan
Anthony PERARD
Samuel Thibault
Steven Smith