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
Using NASM we build OVMF's ResetVector as part of the EDK II build
process.
v2:
* Use EDK II extension of .nasmb rather than .nasmbin
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15823 6f19259b-4bc3-4df7-8a09-765794883524
OVMF_VARS.fd and OVMF_CODE.fd split the variable store and the firmware
code in separate files.
The PCDs' values continue to depend only on FD_SIZE_1MB vs. FD_SIZE_2MB.
With the split files, it must be ensured on the QEMU command line that
OVMF_VARS.fd and OVMF_CODE.fd be contiguously mapped so that they end
exactly at 4GB. See QEMU commit 637a5acb (first released in v2.0.0).
In this patch we must take care to assign each PCD only once.
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@15670 6f19259b-4bc3-4df7-8a09-765794883524
This saves code duplication between the Ia32, Ia32X64, and X64 flavors,
and enables the next patch to include the varstore in new FD files by
reference.
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@15669 6f19259b-4bc3-4df7-8a09-765794883524
Lack of these braces causes build errors when -Wno-missing-braces is
absent. Spelling out more braces also helps understanding the code.
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@15586 6f19259b-4bc3-4df7-8a09-765794883524
The fw_cfg file "etc/acpi/tables" is not a stable guest interface -- QEMU
could rename it in the future, and/or introduce additional fw_cfg files
with ACPI payload. Only the higher-level "etc/table-loader" file is
considered stable, which contains a sequence of commands to assist
firmware with reading QEMU ACPI tables from the FwCfg interface.
Because edk2 provides publishing support for ACPI tables, OVMF only uses
the Allocate command to find the names of FwCfg files to read and publish
as ACPI tables.
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@15574 6f19259b-4bc3-4df7-8a09-765794883524
In one of the next patches we'll start scanning all fw_cfg files that QEMU
advertises as carrying ACPI tables, not just "etc/acpi/tables".
The RSD PTR table is known to occur in the "etc/acpi/rsdp" fw_cfg file.
Since edk2 handles RSD PTR automatically, similarly to RSDT and XSDT,
let's exclude RSD PTR too from the manually installed tables.
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@15573 6f19259b-4bc3-4df7-8a09-765794883524
Split InstallQemuLinkedTables() in two:
- the function now takes the name of the fw_cfg file (from which ACPI
tables are to be extracted) as a parameter,
- the new function InstallAllQemuLinkedTables() calls the former with
fw_cfg file names, and cumulatively tracks the ACPI tables installed by
all invocations of the former.
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@15572 6f19259b-4bc3-4df7-8a09-765794883524
Names of firmware configuration files always take 56 bytes (including at
least one terminating NUL byte). Expose this constant to all consumers of
QemuFwCfgLib because further interfaces may depend on it.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15571 6f19259b-4bc3-4df7-8a09-765794883524
Locate QEMU SMBIOS data in fw_cfg and install it via the
SMBIOS protocol.
Starting with qemu-2.1, on pc/x86 machines of type >= 2.1, full
SMBIOS tables are generated and inserted into fw_cfg (i.e., no
per-field patching of locally generated structures is required).
Aside from new code to extract a SMBIOS blob from fw_cfg, this
patch utilizes the pre-existing infrastructure (already used by
Xen) to handle final SMBIOS table creation.
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@15542 6f19259b-4bc3-4df7-8a09-765794883524
The SMBIOS specification requires some structure types to
contain reference fields to other structures' handles. When
InstallAllStructures() rebuilds the SMBIOS tables by traversing
an existing source table, the use of SMBIOS_HANDLE_PI_RESERVED
causes automatically generated, arbitrary handle numbers to be
assigned to each cloned structure. This causes all reference
handle fields to become invalid.
This patch modifies InstallAllStructures() to reuse the original
handle numbers supplied by the underlying VM, preserving the
correctness of any included handle references.
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: Anthony PERARD <anthony.perard@citrix.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15541 6f19259b-4bc3-4df7-8a09-765794883524
The Windows 2008 R2 SP1 (and Windows 7) UEFI guest's default video driver
dereferences the real mode Int10h vector, loads the pointed-to handler
code, and executes what it thinks to be VGA BIOS services in an internal
real-mode emulator. Consequently, video mode switching doesn't work in
Windows 2008 R2 SP1 when it runs on the pure UEFI build of OVMF, making
the guest uninstallable.
This patch adds a VGABIOS "shim" to QemuVideoDxe. For the first stdvga or
QXL card bound, an extremely stripped down VGABIOS imitation is installed
in the C segment. It provides a real implementation for the few services
that are in fact necessary for the win2k8r2sp1 UEFI guest, plus some fakes
that the guest invokes but whose effect is not important.
The C segment is not present in the UEFI memory map prepared by OVMF. We
never add memory space that would cover it (either in PEI, in the form of
memory resource descriptor HOBs, or in DXE, via gDS->AddMemorySpace()).
This way the handler body is invisible to all non-buggy UEFI guests, and
the rest of edk2.
The Int10h real-mode IVT entry is covered with a Boot Services Code page,
making that too unaccessible to the rest of edk2. (Thus UEFI guest OSes
different from the Windows 2008 family can reclaim the page. The Windows
2008 family accesses the page at zero regardless of the allocation type.)
The patch is the result of collaboration:
Initial proof of concept IVT entry installation and handler skeleton (in
NASM) by Jordan Justen.
Service tracing and implementation, data collection/analysis, and C coding
by yours truly.
Last minute changes by Gerd Hoffmann:
- Use OEM mode number (0xf1) instead of standard 800x600 mode (0x143). The
resolution of the OEM mode (0xf1) is not standardized; the guest can't
expect anything from it in advance.
- Use 1024x768 rather than 800x600 for more convenience in the Windows
2008 R2 SP1 guest during OS installation, and after normal boot until
the QXL XDDM guest driver is installed.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15540 6f19259b-4bc3-4df7-8a09-765794883524
OVMF's SecMain is unique in the sense that it links against the following
two libraries *in combination*:
- IntelFrameworkModulePkg/Library/LzmaCustomDecompressLib/
LzmaCustomDecompressLib.inf
- MdePkg/Library/BaseExtractGuidedSectionLib/
BaseExtractGuidedSectionLib.inf
The ExtractGuidedSectionLib library class allows decompressor modules to
register themselves (keyed by GUID) with it, and it allows clients to
decompress file sections with a registered decompressor module that
matches the section's GUID.
BaseExtractGuidedSectionLib is a library instance (of type BASE) for this
library class. It has no constructor function.
LzmaCustomDecompressLib is a compatible decompressor module (of type
BASE). Its section type GUID is
gLzmaCustomDecompressGuid == EE4E5898-3914-4259-9D6E-DC7BD79403CF
When OVMF's SecMain module starts, the LzmaCustomDecompressLib constructor
function is executed, which registers its LZMA decompressor with the above
GUID, by calling into BaseExtractGuidedSectionLib:
LzmaDecompressLibConstructor() [GuidedSectionExtraction.c]
ExtractGuidedSectionRegisterHandlers() [BaseExtractGuidedSectionLib.c]
GetExtractGuidedSectionHandlerInfo()
PcdGet64 (PcdGuidedExtractHandlerTableAddress) -- NOTE THIS
Later, during a normal (non-S3) boot, SecMain utilizes this decompressor
to get information about, and to decompress, sections of the OVMF firmware
image:
SecCoreStartupWithStack() [OvmfPkg/Sec/SecMain.c]
SecStartupPhase2()
FindAndReportEntryPoints()
FindPeiCoreImageBase()
DecompressMemFvs()
ExtractGuidedSectionGetInfo() [BaseExtractGuidedSectionLib.c]
ExtractGuidedSectionDecode() [BaseExtractGuidedSectionLib.c]
Notably, only the extraction depends on full-config-boot; the registration
of LzmaCustomDecompressLib occurs unconditionally in the SecMain EFI
binary, triggered by the library constructor function.
This is where the bug happens. BaseExtractGuidedSectionLib maintains the
table of GUIDed decompressors (section handlers) at a fixed memory
location; selected by PcdGuidedExtractHandlerTableAddress (declared in
MdePkg.dec). The default value of this PCD is 0x1000000 (16 MB).
This causes SecMain to corrupt guest OS memory during S3, leading to
random crashes. Compare the following two memory dumps, the first taken
right before suspending, the second taken right after resuming a RHEL-7
guest:
crash> rd -8 -p 1000000 0x50
1000000: c0 00 08 00 02 00 00 00 00 00 00 00 00 00 00 00 ................
1000010: d0 33 0c 00 00 c9 ff ff c0 10 00 01 00 88 ff ff .3..............
1000020: 0a 6d 57 32 0f 00 00 00 38 00 00 01 00 88 ff ff .mW2....8.......
1000030: 00 00 00 00 00 00 00 00 73 69 67 6e 61 6c 6d 6f ........signalmo
1000040: 64 75 6c 65 2e 73 6f 00 00 00 00 00 00 00 00 00 dule.so.........
vs.
crash> rd -8 -p 1000000 0x50
1000000: 45 47 53 49 01 00 00 00 20 00 00 01 00 00 00 00 EGSI.... .......
1000010: 20 01 00 01 00 00 00 00 a0 01 00 01 00 00 00 00 ...............
1000020: 98 58 4e ee 14 39 59 42 9d 6e dc 7b d7 94 03 cf .XN..9YB.n.{....
1000030: 00 00 00 00 00 00 00 00 73 69 67 6e 61 6c 6d 6f ........signalmo
1000040: 64 75 6c 65 2e 73 6f 00 00 00 00 00 00 00 00 00 dule.so.........
The "EGSI" signature corresponds to EXTRACT_HANDLER_INFO_SIGNATURE
declared in
MdePkg/Library/BaseExtractGuidedSectionLib/BaseExtractGuidedSectionLib.c.
Additionally, the gLzmaCustomDecompressGuid (quoted above) is visible at
guest-phys offset 0x1000020.
Fix the problem as follows:
- Carve out 4KB from the 36KB gap that we currently have between
PcdOvmfLockBoxStorageBase + PcdOvmfLockBoxStorageSize == 8220 KB
and
PcdOvmfSecPeiTempRamBase == 8256 KB.
- Point PcdGuidedExtractHandlerTableAddress to 8220 KB (0x00807000).
- Cover the area with an EfiACPIMemoryNVS type memalloc HOB, if S3 is
supported and we're not currently resuming.
The 4KB size that we pick is an upper estimate for
BaseExtractGuidedSectionLib's internal storage size. The latter is
calculated as follows (see GetExtractGuidedSectionHandlerInfo()):
sizeof(EXTRACT_GUIDED_SECTION_HANDLER_INFO) + // 32
PcdMaximumGuidedExtractHandler * (
sizeof(GUID) + // 16
sizeof(EXTRACT_GUIDED_SECTION_DECODE_HANDLER) + // 8
sizeof(EXTRACT_GUIDED_SECTION_GET_INFO_HANDLER) // 8
)
OVMF sets PcdMaximumGuidedExtractHandler to 16 decimal (which is the
MdePkg default too), yielding 32 + 16 * (16 + 8 + 8) == 544 bytes.
Regarding the lifecycle of the new area:
(a) when and how it is initialized after first boot of the VM
The library linked into SecMain finds that the area lacks the signature.
It initializes the signature, plus the rest of the structure. This is
independent of S3 support.
Consumption of the area is also limited to SEC (but consumption does
depend on full-config-boot).
(b) how it is protected from memory allocations during DXE
It is not, in the general case; and we don't need to. Nothing else links
against BaseExtractGuidedSectionLib; it's OK if DXE overwrites the area.
(c) how it is protected from the OS
When S3 is enabled, we cover it with AcpiNVS in InitializeRamRegions().
When S3 is not supported, the range is not protected.
(d) how it is accessed on the S3 resume path
Examined by the library linked into SecMain. Registrations update the
table in-place (based on GUID matches).
(e) how it is accessed on the warm reset path
If S3 is enabled, then the OS won't damage the table (due to (c)), hence
see (d).
If S3 is unsupported, then the OS may or may not overwrite the
signature. (It likely will.) This is identical to the pre-patch status.
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@15433 6f19259b-4bc3-4df7-8a09-765794883524
In many cases, the second node in /pci@i0cf8/XYZ@DD,FF node is enough
to match a UEFI device path; a typical cases is a NIC that is assigned
from the host to the guest. Add a catch-all case for PCI devices, and
reuse it for NICs since it works well for those too.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15422 6f19259b-4bc3-4df7-8a09-765794883524
VideoDxe is a UEFI_DRIVER, so it has by default a null instance
of PcdLib. It accesses two PCDs that are now dynamic
(gEfiMdeModulePkgTokenSpaceGuid.PcdVideoHorizontalResolution
and gEfiMdeModulePkgTokenSpaceGuid.PcdVideoVerticalResolution).
Similar to r15362 (OvmfPkg: non-null PcdLib instance for
GraphicsConsoleDxe, 2014-03-22), we need to specify a non-null
instance of PcdLib.
This patch unbreaks the CSM VideoDxe module for OvmfPkg.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Paolo Bonzini <pbonzini@redhat.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@15421 6f19259b-4bc3-4df7-8a09-765794883524
Recent qemu versions compose all ACPI tables on the host side, according
to the target hardware configuration, and make the tables available to any
guest firmware over fw_cfg.
See version compatibility information below.
The feature moves the burden of keeping ACPI tables up-to-date from boot
firmware to qemu (which is the source of hardware configuration anyway).
This patch adds client code for this feature. Benefits of the
qemu-provided ACPI tables include PCI hotplug for example.
Qemu provides the following three fw_cfg files:
- etc/acpi/rsdp
- etc/acpi/tables
- etc/table-loader
"etc/acpi/rsdp" and "etc/acpi/tables" are similar, they are only kept
separate because they have different allocation requirements in SeaBIOS.
Both of these fw_cfg files contain preformatted ACPI payload.
"etc/acpi/rsdp" contains only the RSDP table, while "etc/acpi/tables"
contains all other tables, concatenated.
The tables in these two fw_cfg files are filled in by qemu, but two kinds
of fields are left incomplete in each table: pointers to other tables, and
checksums (which depend on the pointers).
Qemu initializes each pointer with a relative offset into the fw_cfg file
that contains the pointed-to ACPI table. The final pointer values depend
on where the fw_cfg files, holding the pointed-to ACPI tables, will be
placed in memory by the guest. That is, the pointer fields need to be
"relocated" (incremented) by the base addresses of where "/etc/acpi/rsdp"
and "/etc/acpi/tables" will be placed in guest memory.
This is where the third file, "/etc/table-loader" comes in the picture. It
is a linker/loader script that has several command types:
One command type instructs the guest to download the other two files.
Another command type instructs the guest to increment ("absolutize") a
pointer field (having a relative initial value) in the pointing ACPI
table, present in some fw_cfg file, with the dynamic base address of the
same (or another) fw_cfg file, holding the pointed-to ACPI table.
The third command type instructs the guest to compute checksums over
ranges and to store them.
In edk2, EFI_ACPI_TABLE_PROTOCOL knows about table relationships -- it
handles linkage automatically when a table is installed. The protocol
takes care of checksumming too. RSDP is installed automatically. Hence we
only need to care about the "etc/acpi/tables" fw_cfg file, determining the
boundaries of each ACPI table inside it, and installing those tables.
Qemu compatibility information:
--------------+---------------------+-------------------------------------
qemu version | qemu machine type | effects of the patch
--------------+---------------------+-------------------------------------
up to 1.6.x | any pc-i440fx | None. OVMF's built-in ACPI tables
| | are used.
--------------+---------------------+-------------------------------------
any | up to pc-i440fx-1.6 | None. OVMF's built-in ACPI tables
| | are used.
--------------+---------------------+-------------------------------------
1.7.0 | pc-i440fx-1.7 | Potential guest OS crash, dependent
| (default for 1.7.0) | on guest RAM size.
| |
| | DO NOT RUN OVMF on the (1.7.0,
| | pc-i440fx-1.7) qemu / machine type
| | combination.
--------------+---------------------+-------------------------------------
1.7.1 | pc-i440fx-1.7 | OVMF downloads valid ACPI tables
| (default for 1.7.1) | from qemu and passes them to the
| | guest OS.
--------------+---------------------+-------------------------------------
2.0.0-rc0 | pc-i440fx-1.7 or | OVMF downloads valid ACPI tables
| later | from qemu and passes them to the
| | guest OS.
-------------+---------------------+-------------------------------------
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@15420 6f19259b-4bc3-4df7-8a09-765794883524
The previous patch ensures that the LockBox is protected during DXE (but
the OS can still drop it) if S3 is unsupported or disabled. However, S3
related drivers not only save data in the lockbox, they allocate objects
with Reserved and AcpiNVS memory types too, which the OS can't (must not)
release. This is a waste when S3 is unsupported or disabled.
In OVMF a good "choke point" for these drivers is the entry point of
AcpiS3SaveDxe. The messages of the following commits are relevant to the
data and control flow:
- SVN r15290 (git commit 8f5ca05b)
- SVN r15305 (git commit 5a217a06)
- SVN r15306 (git commit d4ba06df)
Prevent AcpiS3SaveDxe from loading when S3 is unsupported or disabled.
This should keep away (most of the) dependent drivers too.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Matt Fleming <matt.fleming@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15419 6f19259b-4bc3-4df7-8a09-765794883524
If (mBootMode == BOOT_ON_S3_RESUME) -- that is, we are resuming --, then
the patch has no observable effect.
If (mBootMode != BOOT_ON_S3_RESUME && mS3Supported) -- that is, we are
booting or rebooting, and S3 is supported), then the patch has no
observable effect either.
If (mBootMode != BOOT_ON_S3_RESUME && !mS3Supported) -- that is, we are
booting or rebooting, and S3 is unsupported), then the patch effects the
following two fixes:
- The LockBox storage is reserved from DXE (but not the OS). Drivers in
DXE may save data in the LockBox regardless of S3 support, potentially
corrupting any overlapping allocations. Make sure there's no overlap.
- The LockBox storage is cleared. A LockBox inherited across a non-resume
reboot, populated with well-known GUIDs, breaks drivers that want to
save entries with those GUIDs.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Matt Fleming <matt.fleming@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15418 6f19259b-4bc3-4df7-8a09-765794883524
Establish the full stack of conversions when modifying the platform
configuration:
ConfigResp -- form engine / HII communication
|
[ConfigToBlock]
|
v
MAIN_FORM_STATE -- binary representation of form/widget state
|
[FormStateToPlatformConfig]
|
v
PLATFORM_CONFIG -- accessible to DXE and UEFI drivers
|
[PlatformConfigSave]
|
v
UEFI non-volatile variable -- accessible to external utilities
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@15375 6f19259b-4bc3-4df7-8a09-765794883524
Establish the full stack of conversions in retrieving the platform
configuration:
MultiConfigAltResp -- form engine / HII communication
^
|
[BlockToConfig]
|
MAIN_FORM_STATE -- binary representation of form/widget state
^
|
[PlatformConfigToFormState]
|
PLATFORM_CONFIG -- accessible to DXE and UEFI drivers
^
|
[PlatformConfigLoad]
|
UEFI non-volatile variable -- accessible to external utilities
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@15374 6f19259b-4bc3-4df7-8a09-765794883524
The RouteConfig() function is also called now as expected.
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@15373 6f19259b-4bc3-4df7-8a09-765794883524
Generate the options for the drop-down list from the GOP resolutions.
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@15372 6f19259b-4bc3-4df7-8a09-765794883524
If Start() succeeds, the callback is only executed when the setup is
complete (on the stack of RestoreTPL()), rather than on the stack of
InstallMultipleProtocolInterfaces(), when the driver setup may yet be
theoretically incomplete.
If Start() fails, the protocol interface will have been uninstalled
(rolled back) by the time the callback runs (again, on the stack of
RestoreTPL()). Since protocol notification callbacks begin with locating
the protocol interface in question, such attempts to locate will fail
immediately and save some work in the callback.
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@15371 6f19259b-4bc3-4df7-8a09-765794883524
In this patch we populate the form with the two widgets related to video
resolution:
- A read-only string field displaying the preference for the next boot.
- A drop-down list offering choices for changing the setting. This list is
implemented with dynamically generated IFR opcodes.
(In general, the current preference may be missing, or it may be invalid
for the available video RAM size. The list of possible new settings is
filtered with the video RAM size.)
Because the form now becomes able to receive input, we must also implement
ExtractConfig(). This function tells the HII engine about the state of the
widgets.
For now we set up both widgets with static data only:
- The current preference always says "Unset". The driver code is still
isolated from the backend (the UEFI variable store).
- The list of possible resolutions offers 800x600 only. We don't
interrogate the GOP yet.
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@15369 6f19259b-4bc3-4df7-8a09-765794883524
We'll need a C language (ie. structure) representation for the state of
the visual elements on the form. We choose the Buffer Storage kind (see
29.2.5.6 "Storage" in UEFI 2.4A), because it's easy to work with.
Note that the structure added in this patch has nothing to do with UEFI
non-volatile variables.
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@15368 6f19259b-4bc3-4df7-8a09-765794883524
The GraphicsConsoleDxe driver (in MdeModulePkg/Universal/Console)
determines the preferred video resolution from the dynamic PCDs
- gEfiMdeModulePkgTokenSpaceGuid.PcdVideoHorizontalResolution
- gEfiMdeModulePkgTokenSpaceGuid.PcdVideoVerticalResolution
Setting the graphics resolution during boot is useful when the guest OS
(for lack of a dedicated display driver) continues to work with the
original GOP resolution and framebuffer.
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@15366 6f19259b-4bc3-4df7-8a09-765794883524
The two functions introduced here allow the saving and loading of platform
configuration to/from the non-volatile variable store.
The PLATFORM_CONFIG structure and the two functions that take it / return
it are generally meant for any DXE or UEFI driver that needs to access
platform configuration. For now we keep this small "library" internal to
PlatformDxe.
The PLATFORM_CONFIG wire format is intended only to grow over time (as
long as the variable GUID remains unchanged). At the introduction of new
fields, new feature flags must be added, and recognized in
PlatformConfigLoad().
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@15365 6f19259b-4bc3-4df7-8a09-765794883524
This DXE driver will load/save persistent values for OVMF's config knobs,
plus expose those knobs via HII.
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@15364 6f19259b-4bc3-4df7-8a09-765794883524
This GUID should become a new "namespace" for UEFI variables that are
specific to OVMF configuration (as opposed to standard UEFI global
variables). We'll also use it as the GUID of the related HII form-set (ie.
the interactive user interface).
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15363 6f19259b-4bc3-4df7-8a09-765794883524
GraphicsConsoleDxe (a UEFI_DRIVER under MdeModulePkg/Universal/Console)
determines the preferred video resolution from the dynamic PCDs
- gEfiMdeModulePkgTokenSpaceGuid.PcdVideoHorizontalResolution
- gEfiMdeModulePkgTokenSpaceGuid.PcdVideoVerticalResolution
In one of the next patches, we'd like to change these PCDs. In order for
GraphicsConsoleDxe to retrieve the new values dynamically,
- it must be linked with the non-null instance of PcdLib,
- OvmfPkg must provide dynamic defaults.
We keep MdeModulePkg's 800x600 default resolution. (The UEFI specification
requires video drivers to support 800x600.)
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@15362 6f19259b-4bc3-4df7-8a09-765794883524
The Boot#### variables that have become unreferenced in the new BootOrder
variable won't ever be automatically reused for booting. They are
"unreachable" resources that take up room in the variable store. Make an
effort to remove them.
This should plug the leak which, given sufficient reboots, exhausts the
variable store with stale Boot#### variables and renders the VM
unbootable.
Reported-by: Michael Chang <mchang@suse.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>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15327 6f19259b-4bc3-4df7-8a09-765794883524
When PI can distinguish the "full config" boot mode from "assume no
changes", then the following BDS logic is correct:
if BootMode == BOOT_WITH_FULL_CONFIGURATION:
//
// connect all devices
// create & append each default boot option that's missing
//
BdsLibConnectAll
BdsLibEnumerateAllBootOption
else if BootMode == BOOT_ASSUMING_NO_CONFIGURATION_CHANGES:
//
// just stick with current BootOrder and the Boot#### variables
// referenced by it
//
In theory, the first branch is intended to run infrequently, and the
"assume no changes" branch should run most of the time.
However, some platforms can't tell these two boot modes apart. The
following substitute had been introduced:
//
// Technically, always assume "full config", but the BootMode HOB is
// actually meaningless wrt. to "full config" or "assume no changes".
//
ASSERT (BootMode == BOOT_WITH_FULL_CONFIGURATION);
//
// Key off the existence of BootOrder. Try to prepare an in-memory list
// of boot options, based on BootOrder and the referenced Boot####
// variables.
//
Status = BdsLibBuildOptionFromVar()
//
// If that succeeded, we'll treat it as "assume no changes". If it
// failed (*only* if it failed), we'll build default boot options,
// calling it "full config":
//
if EFI_ERROR(Status):
BdsLibConnectAll()
BdsLibEnumerateAllBootOption(BootOptionList)
What we have now in OVMF is a mixture of the hack, and the behavior that's
theoretically correct for "full config":
- We assert "full config" -- this is OK.
- We call "connect all" and "enumerate all" deliberately -- this is OK
too. It matches "full config" which we assert.
- However, we also have the hack in place, which had been meant as an
alternative.
In order to clean this up, we either need to restore the hack to its
original form (ie. comment out the unconditional calls again), or we ought
to remove the hack altogether.
The unconditional "connect all" + "enumerate all" calls are the correct
approach for OVMF, because we want, in fact, to start with "full config".
The QEMU boot order specification and the set of emulated devices might
change "out of band", which excludes "assume no changes".
In other words, removing the hack corresponds to the "real production"
case that the comment hints at.
Because SetBootOrderFromQemu() may change the BootOrder NvVar, we must
preserve the BdsLibBuildOptionFromVar() function call, in order to
refresh the in-memory list with the new boot priorities.
(The last step of BdsLibEnumerateAllBootOption() is such a call 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>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15326 6f19259b-4bc3-4df7-8a09-765794883524
This driver (from
"MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/BootScriptExecutorDxe.inf")
is first loaded normally during DXE. When the
EFI_DXE_SMM_READY_TO_LOCK_PROTOCOL is installed by any DXE driver (purely
as a form of notification), the driver reloads itself to reserved memory.
During S3 Resume / PEI, the driver image is executed from there. In order
to access the boot script saved during S3 Suspend, LockBox access is
needed.
The boot script is transferred internal to PiDxeS3BootScriptLib:
Both S3SaveStateDxe and BootScriptExecutorDxe are statically linked
against PiDxeS3BootScriptLib. Whichever is loaded first (during normal
boot, in the DXE phase), allocates the root storage for the script. The
address is then passed between the PiDxeS3BootScriptLib instances living
in the two separate drivers thru the dynamic
PcdS3BootScriptTablePrivateDataPtr PCD.
Dependencies:
BootScriptExecutorDxe
gEfiLockBoxProtocolGuid [OvmfPkg/AcpiS3SaveDxe]
S3BootScriptLib [PiDxeS3BootScriptLib]
SmbusLib [BaseSmbusLibNull]
LockBoxLib [OvmfPkg/Library/LockBoxLib]
LockBoxLib [OvmfPkg/Library/LockBoxLib]
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@15307 6f19259b-4bc3-4df7-8a09-765794883524
BootScriptExecutorDxe, to be pulled in in the next patch, was written with
the SMM implementation of LockBox in mind. That implementation is split in
the following three parts:
- client side (DXE/PEI) library,
- SMM driver producing gEfiLockBoxProtocolGuid,
- driver side (SMM) library.
BootScriptExecutorDxe includes the client side LockBoxLib. So that the
library can communicate with the SMM LockBox driver, BootScriptExecutorDxe
has a Depex on gEfiLockBoxProtocolGuid, normally installed by the SMM
LockBox driver. This is actually not a hard dependency, it just ensures
correct load order between BootScriptExecutorDxe and
MdeModulePkg/Universal/LockBox/SmmLockBox.
The (client side) LockBox library instance in OVMF doesn't depend on a
separate driver that produces gEfiLockBoxProtocolGuid. Nothing produces
that GUID right now in OVMF. This prevents BootScriptExecutorDxe from
loading.
Install gEfiLockBoxProtocolGuid in our only S3-specific, custom DXE
driver, in order to enable loading of BootScriptExecutorDxe.
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@15306 6f19259b-4bc3-4df7-8a09-765794883524
The trigger to actually save the boot script is the installation of
EFI_DXE_SMM_READY_TO_LOCK_PROTOCOL, to be performed by any DXE driver.
Installation of the protocol also locks down SMM (as its name indicates)
and (in theory) prevents further LockBox access.
We cannot install this protocol before BdsLibBootViaBootOption() is called
(eg. in OVMF's PlatformBdsPolicyBehavior()), because
BdsLibBootViaBootOption() calls EFI_ACPI_S3_SAVE_PROTOCOL.S3Save(), which
needs LockBox access.
We also can't install the protocol after BdsLibBootViaBootOption()
returns, simply because control is never returned to us.
Therefore modify our EFI_ACPI_S3_SAVE_PROTOCOL implementation so that the
boot script is prepared and installed internally to S3Save().
(The boot script must contain at least one opcode, otherwise
S3BootScriptLib runs into an assertion failure. We add a harmless (no-op)
"information" opcode.)
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@15305 6f19259b-4bc3-4df7-8a09-765794883524
"MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveStateDxe.inf" produces
the EFI_S3_SAVE_STATE_PROTOCOL which allows creation and saving of an S3
Boot Script, to be replayed in PEI during S3 Resume. The script contains
opcodes and opcode arguments to configure CPU, PCI and IO resources.
S3SaveStateDxe relies on the S3BootScriptLib library. The Null
implementation is not useful for actually saving the boot script, we need
the PiDxeS3BootScriptLib instance.
The PiDxeS3BootScriptLib library instance depends on LockBoxLib,
implemented for OVMF in one of the previous patches.
PiDxeS3BootScriptLib also depends on SmbusLib. For now we opt for the Null
instance of the latter. It means that SMBus commands in the boot script
will have no effect when interpreted during S3 Resume. This should be fine
for OvmfPkg and QEMU.
EFI_S3_SAVE_STATE_PROTOCOL [S3SaveStateDxe]
S3BootScriptLib [PiDxeS3BootScriptLib]
SmbusLib [BaseSmbusLibNull]
LockBoxLib [OvmfPkg/Library/LockBoxLib]
When the EFI_DXE_SMM_READY_TO_LOCK_PROTOCOL is installed by any DXE driver
(purely as a form of notification), the S3SaveStateDxe driver saves the
boot script to EfiACPIMemoryNVS, and links it into the LockBox.
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@15304 6f19259b-4bc3-4df7-8a09-765794883524
"OvmfPkg/AcpiS3SaveDxe/AcpiS3SaveDxe.inf" (originally:
"IntelFrameworkModulePkg/Universal/Acpi/AcpiS3SaveDxe/AcpiS3SaveDxe.inf")
produces the EFI_ACPI_S3_SAVE_PROTOCOL.
When found, this protocol is automatically invoked by
BdsLibBootViaBootOption(), in file
"IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c", right before
booting a boot option, to save ACPI S3 context.
At that point during BDS, our AcpiPlatformDxe driver will have installed
the FACS table (which AcpiS3SaveDxe has a use-time dependency upon).
With regard to dependencies: AcpiS3SaveDxe implements
EFI_ACPI_S3_SAVE_PROTOCOL by relying on LockBoxLib.
BdsLibBootViaBootOption()
EFI_ACPI_S3_SAVE_PROTOCOL [AcpiS3SaveDxe]
LockBoxLib [OvmfPkg/Library/LockBoxLib]
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: Remove EmuNvramLib]
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@15303 6f19259b-4bc3-4df7-8a09-765794883524
"IntelFrameworkModulePkg/Universal/Acpi/AcpiS3SaveDxe/AcpiS3SaveDxe.inf"
currently specifies a DepEx on gEfiMpServiceProtocolGuid (MP Services).
The justification is the following code sequence:
InstallAcpiS3Save()
if PcdFrameworkCompatibilitySupport is set:
InstallAcpiS3SaveThunk()
if EFI_MP_SERVICES_PROTOCOL is available:
GetVariable(ACPI_GLOBAL_VARIABLE)
In English, the AcpiS3SaveDxe driver insists on the presence of MP
Services *unconditionally* because,
- if PcdFrameworkCompatibilitySupport is set (the default is false),
- and MP Services are available (which is constant true under the above
condition),
then the AcpiS3SaveDxe driver would like to get the ACPI_GLOBAL_VARIABLE
variable from the MP Services driver, rather than setting it itself.
The DepEx prevents AcpiS3SaveDxe from loading under OvmfPkg, since we
provide no MP Services implementation. This is particularly broken since
the default PcdFrameworkCompatibilitySupport value is FALSE, making the
entire code that would look at EFI_MP_SERVICES_PROTOCOL dead.
Copy AcpiS3SaveDxe to OvmfPkg, substitute PcdFrameworkCompatibilitySupport
with constant FALSE, and remove all code that becomes dead, including the
DepEx.
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@15302 6f19259b-4bc3-4df7-8a09-765794883524
The S3 suspend/resume infrastructure depends on the LockBox library class.
The edk2 tree currently contains Null and SMM instances. The Null instance
is useless, and the SMM instance would require SMM emulation by including
the SMM core and adding several new drivers, which is deemed too complex.
Hence add a simple LockBoxLib instance for OVMF.
jordan.l.justen@intel.com:
* use PCDs instead of EmuNvramLib
- clear memory in PlatformPei on non S3 boots
* allocate NVS memory and store a pointer to that memory
- reduces memory use at fixed locations
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
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@15301 6f19259b-4bc3-4df7-8a09-765794883524
"UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf" produces the
EFI_PEI_S3_RESUME2 PEIM-to-PEIM Interface.
When the platform-specific initialization code (in PEI) sets the Boot Mode
to BOOT_ON_S3_RESUME, the DXE IPL (which is the last step in PEI) skips
the DXE phase entirely, and executes the S3 Resume PEIM through the
EFI_PEI_S3_RESUME2 interface instead. (See DxeLoadCore() in
"MdeModulePkg/Core/DxeIplPeim/DxeLoad.c".)
S3Resume2Pei depends on LockBoxLib.
EFI_PEI_S3_RESUME2 [S3Resume2Pei]
LockBoxLib [OvmfPkg/Library/LockBoxLib]
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@15300 6f19259b-4bc3-4df7-8a09-765794883524
On S3 resume, we skip decompression of the PEI FV, and expect
to jump directly into it. For this to work, we need the OS to
leave the memory range untouched.
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@15299 6f19259b-4bc3-4df7-8a09-765794883524
On X64, the reset vector code in
"OvmfPkg/ResetVector/Ia32/PageTables64.asm" identity maps the first 4GB of
RAM for PEI, consuming six frames starting at 8MB.
This range is declared by the PcdOvmfSecPageTablesBase/Size PCDs.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
[jordan.l.justen@intel.com: Move to MemDetect.c; use PCDs]
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@15298 6f19259b-4bc3-4df7-8a09-765794883524
Since we marked the FV at PcdOvmfPeiMemFvBase as ACPI NVS memory,
we can use it on S3 resume.
The FV at PcdOvmfDxeMemFvBase may have been overwritten by the OS,
but we do not use it's contents on S3 resume.
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@15296 6f19259b-4bc3-4df7-8a09-765794883524
We will not be running DXE on S3 resume, so we don't
need to do these initialization items:
* Reserve EMU Variable memory range
* Declare Firmware volumes
* Add memory HOBs
v5:
* Move MiscInitialization back to running on S3 resume
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@15295 6f19259b-4bc3-4df7-8a09-765794883524
This 32k section of RAM will be declared to the PEI Core on
S3 resume to allow memory allocations during S3 resume PEI.
If the boot mode is BOOT_ON_S3_RESUME, then we publish
the pre-reserved PcdS3AcpiReservedMemory range to PEI.
If the boot mode is not BOOT_ON_S3_RESUME, then we reserve
this range as ACPI NVS so the OS will not use it.
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@15294 6f19259b-4bc3-4df7-8a09-765794883524
QEMU indicates whether S3 is supported or not in the
fw-cfg interface.
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@15293 6f19259b-4bc3-4df7-8a09-765794883524
Such a packaged query function will come in handy in the following
patches.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
[jordan.l.justen@intel.com: check for enabled rather than disabled]
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15292 6f19259b-4bc3-4df7-8a09-765794883524
This brings the list of BOCHS video modes to par with the QEMU QXL
implementation.
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@15289 6f19259b-4bc3-4df7-8a09-765794883524
In the next patch we'll add many new BOCHS modes, some of which require
large frame buffers.
The size of the QXL VGA compatibility framebuffer can be changed with the
-global qxl-vga.vgamem_mb=$NUM_MB
QEMU option.
If $NUM_MB would exceed 32, then the following two QEMU options are
necessary instead:
-global qxl-vga.vgamem_mb=$NUM_MB \
-global qxl-vga.ram_size_mb=$((NUM_MB*2))
because the compatibility framebuffer can't cover more than half of PCI
BAR #0. The latter defaults to 64MB in size, and is controlled by
"ram_size_mb".
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@15288 6f19259b-4bc3-4df7-8a09-765794883524
The field name "ModeNumber" in QEMU_VIDEO_MODE_DATA is misleading -- it is
not immediately obvious whether this field carries a client-visible mode
number, in the GOP sense, or an internal, card type specific mode index.
After checking all references, rename the field to "InternalModeIndex".
Also, when filling in the card type independent QEMU_VIDEO_MODE_DATA array
from the card type specific mode array, distinguish the GOP mode number
from the internal mode index in the debug message.
This patch effects no functional changes.
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@15287 6f19259b-4bc3-4df7-8a09-765794883524
Currently, QemuVideoGraphicsOutputQueryMode() reports EFI_NOT_STARTED when
this boolean field is set.
However, QemuVideoGraphicsOutputQueryMode() is only available to callers
after the GOP interface has been installed. That in turn implies that the
following partial call tree has succeeded without errors:
QemuVideoControllerDriverStart()
QemuVideoGraphicsOutputConstructor()
QemuVideoGraphicsOutputSetMode(... 0 ...)
HardwareNeedsStarting = FALSE
InstallMultipleProtocolInterfaces(... GOP ...)
That is, when QemuVideoGraphicsOutputQueryMode() is reached,
HardwareNeedsStarting is always FALSE.
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@15286 6f19259b-4bc3-4df7-8a09-765794883524
A bus driver needs to pay attention whether its Stop() function is being
called on the "main" controller handle (NumberOfChildren == 0) or on the
child handles (NumberOfChildren > 0).
In QemuVideoDxe, all our resources are associated with the one child
handle (and the Private data structure) *except* the top-level PciIo
protocol reference. Be conscious of which mode Stop() is being called for.
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@15284 6f19259b-4bc3-4df7-8a09-765794883524
A bus driver is allowed to ignore the actual value of RemainingDevicePath
in Supported() and Start(), and to produce all child handles at once.
This in effect means the following invariants for QemuVideoDxe:
- (RemainingDevicePath == NULL), and
- (Private->GopDevicePath != NULL)
Simplify Supported() and Start() by substituting constant TRUE and FALSE
(as appropriate) in expressions that check RemainingDevicePath and/or
Private->GopDevicePath.
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@15283 6f19259b-4bc3-4df7-8a09-765794883524
In QemuVideoControllerDriverStart():
- remove redundant zero-initialization of:
- Private->Handle (2 locations)
- Private->GopDevicePath (when at devpath end)
- remove fields used for error handling only:
- PciAttributesSaved
- tigthen scope of temporaries:
- MmioDesc
- AcpiDeviceNode
- supplement missing error checks:
- AppendDevicePathNode() can fail with out-of-memory (2 locations)
- when installing GopDevicePath
- retval of QemuVideoGraphicsOutputConstructor() (can justifiedly fail
with out-of-resources)
- plug leaks on error:
- free GopDevicePath (AppendDevicePathNode() allocates dynamically)
- uninstall GopDevicePath
- free Private->ModeData
- call QemuVideoGraphicsOutputDestructor()
- uninstall GOP
In QemuVideoGraphicsOutputConstructor(), called by Start():
- supplement missing error checks:
- QemuVideoGraphicsOutputSetMode() retval (it can fail with
out-of-resources)
- plug leaks on error:
- free Mode->Info
- free Mode
In QemuVideoCirrusModeSetup() and QemuVideoBochsModeSetup(), both called
by Start():
- supplement missing error checks:
- AllocatePool() can fail in both
In QemuVideoGraphicsOutputDestructor(), called by Start() on the error
path:
- plug leaks:
- free Private->LineBuffer, which is allocated in
Start() -> Constructor() -> SetMode()
In QemuVideoGraphicsOutputSetMode(), called by Start() indirectly:
- remove redundant zero-assignment to:
- Private->LineBuffer
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@15282 6f19259b-4bc3-4df7-8a09-765794883524
The BOOLEAN IsFinal variable initialization isn't properly seen by
MSVC. To make it compile OVMF the variable needs to be initialized.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Mauro Faccenda <faccenda@gmail.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@15214 6f19259b-4bc3-4df7-8a09-765794883524
This duplicate message was intended to be removed from r15207
before it was committed. (It was pointed out by Wei Liu.)
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@15213 6f19259b-4bc3-4df7-8a09-765794883524
In the next commit we will update the Xen boot path
to also use this function.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15206 6f19259b-4bc3-4df7-8a09-765794883524
This will be called from a unified MemDetect function.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Wei Liu <wei.liu2@citrix.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15203 6f19259b-4bc3-4df7-8a09-765794883524
Once we support ACPI S3, then we can restore this to
being allocated as ACPI NVS memory.
At that time we should also have a way to disable
S3 support in QEMU. When we detect that S3 is
disabled in QEMU, then we can allocate this as regular
Boot Services Data memory.
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: Bill Paul <wpaul@windriver.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15198 6f19259b-4bc3-4df7-8a09-765794883524
When this option is passed to qemu, it appends the word HALT to the
"bootorder" fw_cfg file, as last entry. For example,
/pci@i0cf8/ethernet@3/ethernet-phy@0
/pci@i0cf8/scsi@4/disk@0,0
HALT
The option's purpose is to prevent SeaBIOS from booting from devices that
have not been specified explicitly (with bootindex=N device properties nor
-boot options). When SeaBIOS sees HALT, it doesn't proceed to boot from
default locations (after boot fails from all of the listed locations).
The HALT string currently causes OVMF to reject the entire "bootorder"
fw_cfg contents, with "parse error". This is not good, because since a
recent libvirt commit, libvirt unconditionally passes "-boot strict=on" to
qemu. Consequently, the boot order logic in QemuBootOrder.c has stopped
working for libvirt users.
OVMF's SetBootOrderFromQemu() function actually implements the idea behind
"-boot strict=on": it drops all boot options not in the fw_cfg list. (*)
Therefore, let's recognize HALT, and just do what we've been doing all
along.
(*) Except the UEFI shell, according to the survival policy in
BootOrderComplete(), but the memory mapped UEFI shell is not expressible
via fw_cfg anyway, and its preservation has been requested on edk2-devel.
Hence it's a good boot option to keep in any case.
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@15197 6f19259b-4bc3-4df7-8a09-765794883524
This will be needed to update the boot flow for S3 resume.
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@15196 6f19259b-4bc3-4df7-8a09-765794883524
The Xen and QEMU/KVM paths were calling this at nearly
the same time in the boot flow anyhow, so just make
the call in one spot.
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@15195 6f19259b-4bc3-4df7-8a09-765794883524
By splitting the PEI and DXE phases into separate FVs,
we can only reserve the PEI FV for ACPI S3 support.
This should save about 7MB.
Unfortunately, this all has to happen in a single commit.
DEC:
* Remove PcdOvmfMemFv(Base|Size)
* Add PcdOvmfPeiMemFv(Base|Size)
* Add PcdOvmfDxeMemFv(Base|Size)
FDF:
* Add new PEIFV. Move PEI modules here.
* Remove MAINFV
* Add PEIFV and DXEFV into FVMAIN_COMPACT
- They are added as 2 sections of a file, and compressed
together so they should retain good compression
* PcdOvmf(Pei|Dxe)MemFv(Base|Size) are set
SEC:
* Find both the PEI and DXE FVs after decompression.
- Copy them separately to their memory locations.
Platform PEI driver:
* Fv.c: Publish both FVs as appropriate
* MemDetect.c: PcdOvmfMemFv(Base|Size) =>
PcdOvmfDxeMemFv(Base|Size)
OVMF.fd before:
Non-volatile data storage
FVMAIN_COMPACT uncompressed
FV FFS file LZMA compressed
MAINFV uncompressed
individual PEI modules uncompressed
FV FFS file compressed with PI_NONE
DXEFV uncompressed
individual DXE modules uncompressed
SECFV uncompressed
OVMF.fd after:
Non-volatile data storage
FVMAIN_COMPACT uncompressed
FV FFS file LZMA compressed
PEIFV uncompressed
individual PEI modules uncompressed
DXEFV uncompressed
individual DXE modules uncompressed
SECFV uncompressed
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@15151 6f19259b-4bc3-4df7-8a09-765794883524
This allow you to search for an 'instance' of a section
within a series of FFS sections.
For example, we will split the MAINFV into a PEI and DXE
FV, and then compress those two FV's together within a
FFS FV file. The DXE FV will appear as the second section
of the file, and therefore we will search for it using
an Instance=1 value.
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@15150 6f19259b-4bc3-4df7-8a09-765794883524
These are all internal functions that don't interface with
assembly code or other drivers. Therefore EFIAPI is not
required.
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@15149 6f19259b-4bc3-4df7-8a09-765794883524
Note: The Temporary RAM memory size is being reduced from
64KB to 32KB. This still appears to be more than
adequate for OVMF's early PEI phase. We will be adding
another 32KB range of RAM just above this range for
use on S3 resume.
The range is declared as part of MEMFD, so it is easier
to identify the memory range.
We also now assign PCDs to the memory range.
The PCDs are used to set the initial SEC/PEI stack in
SEC's assembly code.
The PCDs are also used in the SEC C code to setup
the Temporary RAM PPI.
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@15147 6f19259b-4bc3-4df7-8a09-765794883524
To help consolidate OVMF fixed memory uses, we declare this
range in MEMFD and thereby move it to 8MB.
We also now declare the table range in the FDF to set
PCDs. This allows us to ASSERT that CR3 is set as expected
in OVMF SEC.
OvmfPkgIa32.fdf and OvmfPkgIa32X64.fdf are updated simply
for consistency.
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@15146 6f19259b-4bc3-4df7-8a09-765794883524
The Linux persistent store (pstore) feature serves, among other things,
for saving the trailing portion of the dmesg in case of a kernel oops. One
backend for the pstore facility is "efivars", ie. non-volatile UEFI
variables.
Linux splits the tail of the dmesg that is to be dumped in 1KB chunks, and
tries to save each chunk as a specially (and differently) named
non-volatile variable. The 1KB chunk size accounts for the variable data
only; Linux expects this size to be available per variable *without*
accounting for the variable name or any firmware-internal overhead.
For non-authenticated (ie. non-secure-boot) variables, OvmfPkg currently
sets the per-variable limit to 0x400 (1KB) through PcdMaxVariableSize.
However this PCD determines the size *before* subtracting the internal
overhead (which is sizeof(VARIABLE_HEADER) == 0x20 bytes for
non-authenticated variables, see
"MdeModulePkg/Include/Guid/VariableFormat.h"), and also before subtracting
the given variable's UCS-2 encoded name (including the trailing 0x0000).
Linux maximizes these special variable names in DUMP_NAME_LEN==52 code
points (including the trailing NUL). Hence we must provide at least
0x020 == sizeof(VARIABLE_HEADER), for the internal overhead
0x068 == 2 * 52, for the UCS-2 encoded name, including trailing 0x0000
0x400 for the variable body
-----
0x488 == 1160
bytes in PcdMaxVariableSize, so that Linux's efivars-backed pstore can
work even on non-secure-boot builds of OVMF.
However, as PcdMaxVariableSize=0x2000 has proven reasonable when secure
boot is enabled, it should also be okay when secure boot is disabled; so
for simplicity's sake set PcdMaxVariableSize to 0x2000 unconditionally.
Tested-by: Seiji Aguchi <seiji.aguchi@hds.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>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15142 6f19259b-4bc3-4df7-8a09-765794883524
If GCC 4.8 or 4.9 is detected, then use the GCC48 toolchain.
Previously we would use the GCC47 toolchain, but GCC48
was recently added to the main edk2 BaseTools/Conf.
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@15141 6f19259b-4bc3-4df7-8a09-765794883524
The QemuFwCfgSecLib library instance
- is stateless,
- has no library constructor,
- is available to SEC client code,
- must be queried with QemuFwCfgIsAvailable() before use,
- is restricted to SEC in order to limit the explicit querying
requirement. (There is no current user.)
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@15046 6f19259b-4bc3-4df7-8a09-765794883524
The current implementation of QemuFwCfgLib is:
- stateful
- implicitly initialized in the library constructor.
OVMF's SEC runs from read-only memory/flash. When the library is linked
into a SEC binary (which currently never happens), the
"mQemuFwCfgSupported" global variable becomes read-only, making the
library non-functional.
Extract the stateful, implicitly initialized library implementation into a
separate file, making room for a stateless, explicitly queried
implementation that's usable in SEC. Restrict the stateful implementation
to the current, non-SEC 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>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15045 6f19259b-4bc3-4df7-8a09-765794883524
This internal function allows separation of library-internal and
for-clients external availability of fw_cfg.
The interface contract of QemuFwCfgIsAvailable() is changed so that now it
may modify fw_cfg state. All current users are compliant with the new
contract.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15044 6f19259b-4bc3-4df7-8a09-765794883524
Rather than embedding the License information in this script,
we now read the License.txt files from MdePkg & FatBinPkg.
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@15043 6f19259b-4bc3-4df7-8a09-765794883524
Previously we would run 'git svn info' if a .svn directory
wasn't found. This would fail if the current local commit
was not from git-svn.
Now we look for the svn info in the output from git log.
If the svn version is not in a git-svn-id tag from
git log, then we use the git commit hash.
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@15042 6f19259b-4bc3-4df7-8a09-765794883524
The source control revision is still the produced filename.
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@15040 6f19259b-4bc3-4df7-8a09-765794883524
Remove 'Alpha' status tag. Let's just refer to the OVMF
releases by their revision control version.
Remove 'stabilize UEFI Linux' to-do item.
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@15039 6f19259b-4bc3-4df7-8a09-765794883524
Although SVN r14944 ("OvmfPkg: introduce PublishPeiMemory") copied a big
chunk of code from MemDetect(), calling the new PublishPeiMemory()
function in MemDetect() could not have replaced the original code in the
latter. However, with the help of the previous patch, we can do it now.
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@15023 6f19259b-4bc3-4df7-8a09-765794883524
UEFI spec virtio spec
======================================= =================================
LowestAlignedLba EFI_LBA (UINT64) alignment_offset u8
+-------------------------------------- +--------------------------------
| first LBA that is aligned to a | offset of first aligned
| physical block boundary (SCSI | logical block
| definition)
LogicalBlocksPerPhysicalBlock UINT32 physical_block_exp u8
+-------------------------------------- +--------------------------------
| number of logical blocks per | # of logical blocks per
| physical block [...] does not contain | physical block (log2)
| an exponential value
OptimalTransferLengthGranularity UINT32 opt_io_size le32
+-------------------------------------- +--------------------------------
| optimal transfer length granularity | optimal (suggested maximum) I/O
| as a number of logical blocks [...] A | size in blocks
| value of 0 means there is no reported
| optimal transfer length granularity
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@15004 6f19259b-4bc3-4df7-8a09-765794883524
Lines should be no longer than 79 characters.
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@15003 6f19259b-4bc3-4df7-8a09-765794883524
We're going to introduce a new macro and a new VIRTIO_BLK_CONFIG member
that need realignment of existing definitions and comments. Separate out
the whitespace changes in this patch.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15001 6f19259b-4bc3-4df7-8a09-765794883524
When QemuFlashWrite() is asked to write a range that includes the last
byte of the LBA, then the byte that the function uses to switch the flash
device back to read mode (ROMD mode in KVM speak) actually falls out of
the LBA.
Normally this doesn't cause visible problems. However, if the variable
store and the firmware code are backed by separate flash devices, as
implemented by
[Qemu-devel] [PATCH v2] hw/i386/pc_sysfw: support two flash drives
http://thread.gmane.org/gmane.comp.emulators.qemu/243678
plus
[edk2] [edk2 PATCH] OvmfPkg: split the variable store to a separate file
http://thread.gmane.org/gmane.comp.bios.tianocore.devel/5045/focus=5046
then the READ_ARRAY_CMD not only reaches a different LBA, it reaches a
different qemu device. This results in a guest reboot soon after.
Fix this by ensuring that we always stay within the LBA just written when
issuing READ_ARRAY_CMD.
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@14996 6f19259b-4bc3-4df7-8a09-765794883524
The QemuVideoDxe driver creates child controller handles, so it is acting
as a hybrid bus driver. The child handles should open the parent's bus
protocol BY_CHILD_CONTROLLER to properly maintain the protocol usage count.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Chris Ruffin <chris.ruffin@intel.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@14987 6f19259b-4bc3-4df7-8a09-765794883524
These functions did not provide much more than the new protocol functions
VIRTIO_DEVICE_PROTOCOL.ReadDevice() / VIRTIO_DEVICE_PROTOCOL.WriteDevice().
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Olivier Martin <olivier.martin@arm.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14968 6f19259b-4bc3-4df7-8a09-765794883524
This definition is specific to VirtIo over PCI.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Olivier Martin <olivier.martin@arm.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14967 6f19259b-4bc3-4df7-8a09-765794883524
This change replaces the accesses to the PCI bus from the Block, Scsi and Net drivers by
the use of the new VIRTIO_DEVICE_PROTOCOL protocol that abstracts the transport layer.
It means these drivers can be used on PCI and MMIO transport layer.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Olivier Martin <olivier.martin@arm.com>
v5:
- VirtioFlush(): update comment block in VirtioLib.[hc]; error code is
propagated from VirtIo->SetQueueNotify().
- VirtioBlkInit(): jump to Failed label if SetPageSize() fails
- VirtioBlkInit(): fixup comment, and add error handling, near
SetQueueNum() call
- VirtioBlkDriverBindingStart(): remove redundant (always false) check for
a subsystem device ID different from VIRTIO_SUBSYSTEM_BLOCK_DEVICE;
VirtioBlkDriverBindingSupported() handles it already
- VirtioNetGetFeatures(): update stale comment block
- VirtioNetGetFeatures(): retrieve MAC address byte for byte (open-coded
loop)
- VirtioNetDriverBindingStart(): remove redundant (always false) check for
a subsystem device ID different from VIRTIO_SUBSYSTEM_NETWORK_CARD;
VirtioNetDriverBindingSupported() handles it already
- VirtioNetInitRing(): call SetQueueNum() and SetQueueAlign() for proper
MMIO operation
- VirtioNetInitialize(): fix destination error label for when
SetPageSize() fails
- VirtioScsi.c: fix comment block of VIRTIO_CFG_WRITE()/VIRTIO_CFG_READ()
- VirtioScsiInit(): fix destination error label for when SetPageSize()
fails
- VirtioScsiInit(): call SetQueueNum() and SetQueueAlign() for proper MMIO
operation
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@14966 6f19259b-4bc3-4df7-8a09-765794883524
Why is the virtio-mmio implementation of the protocol a library,
instead of a driver binary?
The UEFI driver model would encourage to create a virtio-mmio driver
instead of a library. But the reasons why I created a library are:
- A virtio-mmio driver would imply an additional protocol that would
probably have a single attribute field:
typedef struct {
PHYSICAL_ADDRESS BaseAddress;
} VIRTIO_MMIO_DEVICE_PROTOCOL;
- There is no (easy) way to scan the available VirtIo devices on a
platform. So, the UEFI firmware for this platform would need a driver
to produce instances for every virtio devices it wants to expose in
UEFI. A single call to a helper library (ie: VirtioMmioDeviceLib)
make the porting easier.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Olivier Martin <olivier.martin@arm.com>
v5:
- typo fix in VirtioMmioInstallDevice() comment block
- plug MmioDevice leak in VirtioMmioUninstallDevice()
- return EFI_INVALID_PARAMETER in VirtioMmioGetQueueAddress() if
QueueAddress is NULL
- VirtioMmioSetQueueSize(): fix return value (it's a status code)
- VirtioMmioSetPageSize(): check against EFI_PAGE_SIZE with "if" plus
EFI_UNSUPPORTED, rather than ASSERT()
- VirtioMmioDeviceWrite(), VirtioMmioDeviceRead(): remove redundant
(FieldSize > 8) checks
- VirtioMmioDeviceLib.inf: drop UefiDriverEntryPoint library dependency
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@14965 6f19259b-4bc3-4df7-8a09-765794883524
This change implements the VIRTIO_DEVICE_PROTOCOL for the PCI transport
layer.
The VirtIo device drivers will interact with the PCI-based VirtIo devices
through this protocol implementation.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Olivier Martin <olivier.martin@arm.com>
v5:
- updated comment block on VirtioPciDeviceRead()
- return EFI_UNSUPPORTED instead of failed ASSERT() in
VirtioPciSetPageSize()
- VirtioPciIoRead(): restore the original requirement that FieldSize equal
BufferSize exactly (not only divide it). The looping added in v4 did not
match the comment block, and the only place that used it in v4 (ie.
VirtioNetGetFeatures()) needs an open-coded loop anyway (will be done in
a later part of v5).
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@14964 6f19259b-4bc3-4df7-8a09-765794883524
This protocol introduces an abstraction to access the VirtIo
Configuration and Device spaces.
The registers in these spaces are located at a different offset and have
a different width whether the transport layer is either PCI or MMIO. This
protocol would also allow to support VirtIo PCI devices with MSI-X
capability in a transparent way (Device space is at a different offset
when a PCIe device has MSI-X capability).
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Olivier Martin <olivier.martin@arm.com>
v5:
- add disclaimer (two instances) about the protocol being work in progress
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@14963 6f19259b-4bc3-4df7-8a09-765794883524
This patch sets PcdPciDisableBusEnumeration to true then makes use of
PublishPeiMemory and XenMemMapInitialization to construct memory map for
Xen guest.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14946 6f19259b-4bc3-4df7-8a09-765794883524
MemDetect actully does too many things, the underlying platform might
want to have more control over memory layout.
Extract the functionality of publishing PEI memory to a dedicated
function.
Also fixed wrong comment while I was there.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14944 6f19259b-4bc3-4df7-8a09-765794883524
This is useful for initializing memory map.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14943 6f19259b-4bc3-4df7-8a09-765794883524
EFI_XEN_OVMF_INFO is defined to accept configurations from hvmloader. It
must match the definition on Xen side.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14942 6f19259b-4bc3-4df7-8a09-765794883524
QemuFlashFvbServicesRuntimeDxe provides actual persistent storage for
non-volatile variables. When it is active, any on-disk NvVars file counts
as a stale source of variables -- hence don't load these files in BDS.
This also allows Secure Boot settings (eg. enrolled keys) to survive cold
VM reboots.
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@14844 6f19259b-4bc3-4df7-8a09-765794883524
PcdFlashNvStorageVariableBase64 is used to arbitrate between
QemuFlashFvbServicesRuntimeDxe and EmuVariableFvbRuntimeDxe, but even the
latter driver sets it if we fall back to it.
Allow code running later than the startup of these drivers to know about
the availability of flash variables, through a dedicated PCD.
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@14843 6f19259b-4bc3-4df7-8a09-765794883524
If the QEMU version is found to be >= 1.6, then automatically
enable flash (using the QEMU pflash command line parameter).
QEMU supports flash since 1.2, but only if KVM is disabled.
As of QEMU 1.6, flash support should also be enabled when
KVM is used. Therefore it is safest to only enable flash for
QEMU 1.6 and newer.
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@14842 6f19259b-4bc3-4df7-8a09-765794883524
If this argument is used, then when QEMU is run, the -pflash
parameter will be used with QEMU to enable QEMU's flash
mode.
It should be used before the 'qemu' argument, since it is
not a QEMU parameter, but instead it updates how build.sh
runs QEMU.
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@14841 6f19259b-4bc3-4df7-8a09-765794883524
This driver will support a flash FVB implementation if QEMU flash
is detected.
The driver is added to the apriori list to make sure it runs
before the EmuVariableFvbRuntimeDxe driver. If this driver detects
flash support, then it will disable the EmuVariableFvbRuntimeDxe
driver by setting PcdFlashNvStorageVariableBase64.
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@14840 6f19259b-4bc3-4df7-8a09-765794883524
If QEMU flash is detected, this module will install
FirmwareVolumeBlock support for the QEMU flash device.
It will also set PCDs with the results that:
1. OvmfPkg/EmuVariableFvbRuntimeDxe will be disabled
2. MdeModulePkg variable services will read/write flash directly
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14839 6f19259b-4bc3-4df7-8a09-765794883524
If QEMU flash is supported, then the PcdFlashNvStorageVariableBase64
will be set by the flash FVB driver. If it is set to a non-zero value,
then we disable memory based variables.
In future patches we will add the flash FVB driver and
force it to run before this driver. Therefore, if QEMU flash
writing is supported, then this driver will be disabled.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14838 6f19259b-4bc3-4df7-8a09-765794883524
In a later patch we will want to mark the flash memory as a
runtime services data memory range. This will allow a new runtime
services firmware block driver to read & write flash memory when
the OS has set up virtual memory protection.
Since this memory range will appear as runtime services data, we
need to adjust the limit when scanning for PCI window 32 down to
just below the flash device. If we don't adjust the limit, then
the algorithm in PopulateFwData will fail because it will see a
EfiGcdMemoryTypeSystemMemory memory range just below 4GB.
v2:
* This patch replaces the v1 patch:
"OvmfPkg/AcpiPlatformDxe/Qemu: Allow high runtime memory regions"
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@14837 6f19259b-4bc3-4df7-8a09-765794883524
This is to prepare for QEMU flash support which will allow
non-volatile variables to be saved in the flash image.
Note two size changes:
* NV Varstore size increased from 0xc000 to 0xe000
* FTW work size decreased from 0x2000 to 0x1000
The reason for this change is that the fault-tolerant write
support requires that the work area fit within the block
just before the fault-tolerant write spare storage blocks.
Since QEMU flash blocks have a size of 0x1000, this means
that the maximum FTW work size is 0x1000.
v2:
* Update commit message and PcdVariableStoreSize
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@14835 6f19259b-4bc3-4df7-8a09-765794883524
The 1MB image with full debug and the shell included is too
large to implement flash based non-volatile variable.
After this change, building with -D FD_SIZE_1MB will
force the smaller flash size.
The default size for RELEASE build remains at 1MB, so using
-b RELEASE on the build command line will result in a
1MB flash size. For RELEASE builds -D FD_SIZE_2MB can be
used to produce a 2MB flash image.
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@14833 6f19259b-4bc3-4df7-8a09-765794883524
If the user has set the QEMU_COMMAND environment variable,
then use it when running QEMU. This can be useful for running
OVMF with development builds of QEMU.
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@14825 6f19259b-4bc3-4df7-8a09-765794883524
Offsets are different between the PCI and MMIO transport layer.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Olivier Martin <olivier.martin@arm.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@14808 6f19259b-4bc3-4df7-8a09-765794883524
The Device Specific Configuration region is located at different locations
for the VirtIo devices over PCI, PCI with MSI-X capability, MMIO.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Olivier Martin <olivier.martin@arm.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@14807 6f19259b-4bc3-4df7-8a09-765794883524
SVN r14770 ("OvmfPkg/PlatformPei: correctly align emulated NV storage")
made sure the emulated NV storage was allocated with correct alignment.
However, the AllocateRuntimePool() -> AllocateAlignedPages() change
flipped the memory type from EfiRuntimeServicesData to
EfiBootServicesData. This causes variable services to access freed storage
at runtime. It crashes Windows 2008 R2 early at boot, for example.
Keep the alignment, but restore the memory type to EfiRuntimeServicesData,
by calling AllocateAlignedRuntimePages().
These helper functions are implemeted and documented in
"MdePkg/Library/PeiMemoryAllocationLib/MemoryAllocationLib.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@14806 6f19259b-4bc3-4df7-8a09-765794883524
Per 2c4b18e ("MdeModulePkg: Add the alignment check for FTW spare area
address and length, and add the check for PcdFlashNvStorageVariableSize
<= PcdFlashNvStorageFtwSpareSize."), FTWDxe refuses to initialize if
spare space base address or size is not aligned to block size.
Depending on configuration, memory for FTWDxe might be dynamically
allocated in PlatformPei. This patch makes sure that the allocated
memory region is aligned.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14770 6f19259b-4bc3-4df7-8a09-765794883524
LoadLinux() is looking at the wrong field for the kernel's EFI handover
protocol flags. It's not currently possible for JumpToUefiKernel() to
ever be called (even accidentally) because BIT2 and BIT3 of
Bp->hdr.load_flags are never set in modern kernels, which means that
control is always transferred to the kernel via the legacy entry point.
Look at the correct field so that the EFI handover protocol is used
whenever it's available.
Contributed-under: TianoCore Contribution Agreement 1.0
Cc: David Woodhouse <David.Woodhouse@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Borislav Petkov <bp@suse.de>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14721 6f19259b-4bc3-4df7-8a09-765794883524
Since we no longer building page tables in SEC C code, we no
longer need this file.
This reverts commit r14493.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-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@14720 6f19259b-4bc3-4df7-8a09-765794883524
Now for X64 we use a VTF0 ResetVector which puts the page
tables in RAM. Therefore SEC no longer needs to do this.
This reverts commit r14494.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-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@14719 6f19259b-4bc3-4df7-8a09-765794883524
Since we no longer require flash tables to be stored uncompressed
in the flash image, we can now give extra space to the main/compressed
storage area.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-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@14718 6f19259b-4bc3-4df7-8a09-765794883524
This reset vector code will build page tables in RAM at address
0x80000, rather than relying on page tables to be present within
the flash image.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-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@14717 6f19259b-4bc3-4df7-8a09-765794883524
In UEFI X64 we use other mechanisms to disable caching.
(CD/NW in CR0 and MTRRs.)
This fixes a slow boot issue with SVM.
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@14716 6f19259b-4bc3-4df7-8a09-765794883524
KVM has a bug that prevents using page tables in the ROM if the ROM
region utilizes the KVM READONLY memory feature. Therefore, we
avoid using page tables stored in the ROM.
Since OVMF doesn't require memory initialization, we just build
page table entries in RAM at 0x80000 very early in the OVMF boot
process. This address is just after the 'temp RAM' which is set
up by the SEC module.
Currently we only set up 4GB of page tables for OVMF's PEI,
but DxeIpl will build identity mapped page tables that cover all
of the available processor physical address space.
Reported-by: Gary Ching-Pang Lin <glin@suse.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-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@14715 6f19259b-4bc3-4df7-8a09-765794883524
(1) OVMF depends on
MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
unconditionally.
(2) When OVMF is built with -D SECURE_BOOT_ENABLE, then
SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.inf
is injected into SecurityStubDxe above.
(3) SVN r14687 ("Add TPM2 implementation.") has made
DxeImageVerificationLib dependent on TpmMeasurementLib.
Currently the last link of the
OVMF -> SecurityStubDxe -> DxeImageVerificationLib -> TpmMeasurementLib
dependency chain is unresolved:
build.py...
/.../OvmfPkg/OvmfPkgX64.dsc(...): error 4000: Instance of library class [TpmMeasurementLib] is not found
in [/.../SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.inf] [X64]
consumed by module [/.../MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf]
Let's provide a library instance for TpmMeasurementLib the same way as
"SecurityPkg/SecurityPkg.dsc" does (SVN r13964.)
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@14690 6f19259b-4bc3-4df7-8a09-765794883524
Some of the active boot options that have not been selected over fw_cfg
should be preserved at the end of the boot order. For now we're adding
back everything that starts with neither PciRoot() nor HD(). This includes
the UEFI shell, memory-mapped from the firmware image.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Michael Chang <mchang@suse.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14668 6f19259b-4bc3-4df7-8a09-765794883524
This will allow us to identify those UEFI boot options (while keeping
their relative order) that have *not* been selected by fw_cfg.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Michael Chang <mchang@suse.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14667 6f19259b-4bc3-4df7-8a09-765794883524
In preparation for the next patch, collect active UEFI boot options in
advance into a new array. Rebase the current inner loop (the matching
loop) to this array.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Michael Chang <mchang@suse.com>
[jordan.l.justen@intel.com: initialize *ActiveOption for GCC IA32 warning]
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@14666 6f19259b-4bc3-4df7-8a09-765794883524
The prefix matching logic in Match()
[OvmfPkg/Library/PlatformBdsLib/QemuBootOrder.c] expects UEFI boot options
to specify full (absolute) device paths. However, partial (relative)
device paths starting with a HD() node are valid for booting. By not
recognizing them, QemuBootOrder.c misses (and deletes) valid boot options
that would otherwise match the user's preference.
Just like BdsLibBootViaBootOption() expands such paths with the
BdsExpandPartitionPartialDevicePathToFull() function for booting, do the
same in QemuBootOrder.c for prefix matching.
This moves the very first call to
BdsExpandPartitionPartialDevicePathToFull() to an earlier point. The
following call tree explains it:
BdsEntry() [IntelFrameworkModulePkg/Universal/BdsDxe/BdsEntry.c]
PlatformBdsPolicyBehavior() [OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c]
SetBootOrderFromQemu() [OvmfPkg/Library/PlatformBdsLib/QemuBootOrder.c]
Match() [OvmfPkg/Library/PlatformBdsLib/QemuBootOrder.c]
BdsExpandPartitionPartialDevicePathToFull() [IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c]
BdsBootDeviceSelect() [IntelFrameworkModulePkg/Universal/BdsDxe/BdsEntry.c]
BdsLibBootViaBootOption() [IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c]
BdsExpandPartitionPartialDevicePathToFull() [IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c]
This should be fine, for two reasons:
- the new, earlier call is still under BdsEntry(),
- BdsExpandPartitionPartialDevicePathToFull() expects to be called
repeatedly, even with the same set of HD() device paths. This function
implements its own caching for device paths, likely for performance
reasons.
That fits this patch well because whatever device paths we expand under
PlatformBdsPolicyBehavior() can be quickly looked up in
BdsBootDeviceSelect(), so no work (ie.
BdsLibConnectAllDriversToAllControllers()) should be wasted.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Michael Chang <mchang@suse.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14665 6f19259b-4bc3-4df7-8a09-765794883524
The volatile 'NvVars' variable indicates that the variables do
not need to be loaded from the file again. After we write the
variables out to the file, there is clearly no need to load
them back from the file.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Michael Chang <mchang@suse.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14613 6f19259b-4bc3-4df7-8a09-765794883524
2. ASSERT if PCD value is set to 5 (QUERY_USER_ON_SECURITY_VIOLATION).
3. Update override PCD setting from 5 to 4 in platform DSC file.
Signed-off-by: Fu Siyuan <siyuan.fu@intel.com>
Reviewed-by: Ni Ruiyu <ruiyu.ni@intel.com>
Reviewed-by: Ye Ting <ting.ye@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14607 6f19259b-4bc3-4df7-8a09-765794883524
Enforce in-order execution of these steps even on not sequentially
consistent architectures, as discussed in [1]. These changes should be
unnecessary on x86 (the only architecture OVMF currently supports), but
they align the OVMF virtio code with the virtio specification and could be
necessary for future OVMF ports.
[1] http://lists.linuxfoundation.org/pipermail/virtualization/2013-June/024547.html
Suggested-by: Stefan Hajnoczi <stefanha@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14601 6f19259b-4bc3-4df7-8a09-765794883524
Previously OVMF included the older EFI shell binary when building.
Now we will build and use the UEFI shell (ShellPkg) instead.
v2:
* Don't bother building UEFI shell when USE_OLD_SHELL is defined
* Fix errors in OvmfPkgIa32X64.fdf
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@14600 6f19259b-4bc3-4df7-8a09-765794883524
When enrolling the certificate from a file, the suffix check function
check the last 4 characters to filter out non-DER files. However,
if the length of the file name is less than 4, the address prior to
the file name will be accessed while it shouldn't. This commit checks
the length of the file name to avoid illegal access.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gary Ching-Pang Lin <glin@suse.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Guo Dong <guo.dong@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14556 6f19259b-4bc3-4df7-8a09-765794883524
In Linux, efi_memblock_x86_reserve_range() and efi_reserve_boot_services()
expect that whoever allocates the EFI memmap allocates it in Loader Data
type memory. Linux's own exit_boot()-->low_alloc() complies, but
SetupLinuxMemmap() in LoadLinuxLib doesn't.
The memory type discrepancy leads to efi_memblock_x86_reserve_range() and
efi_reserve_boot_services() both trying to reserve the range backing the
memmap, resulting in memmap entry truncation in
efi_reserve_boot_services().
This fix also makes this allocation consistent with all other persistent
allocations in "OvmfPkg/Library/LoadLinuxLib/Linux.c".
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reported-and-tested-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14555 6f19259b-4bc3-4df7-8a09-765794883524
This is based on MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c.
Previously we would run using page tables built into the
firmware device.
If a flash memory is available, it is unsafe for the page
tables to be stored in memory since the processor may try
to write to the page table data structures.
Additionally, when KVM ROM support is enabled for the
firmware device, then PEI fails to boot when the page
tables are in the firmware device.
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@14494 6f19259b-4bc3-4df7-8a09-765794883524
When the PM base address was moved from 0x400 to 0xb000, this
code was missed. This prevented shutdown's via the UEFI system
call from working. (For example, at the EFI shell prompt: reset -s)
We now use gUefiOvmfPkgTokenSpaceGuid.PcdAcpiPmBaseAddress
which is currently set at 0xb000.
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@14492 6f19259b-4bc3-4df7-8a09-765794883524
r14252 causes OVMF to crash if SECURE_BOOT_ENABLE is set,
because PcdMaxVariableSize is set to a larger value than
required. In other platforms, 0x2000 seems to be sufficient.
Reported-by: Gary Ching-Pang Lin <glin@suse.com>
Signed-off-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@14423 6f19259b-4bc3-4df7-8a09-765794883524
Also summarize the resultant NIC driver options in the README file.
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: Stefan Hajnoczi <stefanha@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14421 6f19259b-4bc3-4df7-8a09-765794883524
These changes were needed in addition to the silence.patch
that Laszlo posted on May 28.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14420 6f19259b-4bc3-4df7-8a09-765794883524
These were found with the gcc-4.4 option "-Wconversion" after Jordan
reported the build failure under Visual Studio. The patch was originally
posted to edk2-devel as "silence.patch":
http://thread.gmane.org/gmane.comp.bios.tianocore.devel/2804/focus=2972
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: Stefan Hajnoczi <stefanha@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14419 6f19259b-4bc3-4df7-8a09-765794883524
Steven Smith
Anthony PERARD
Laszlo Ersek
Jordan Justen
Gabriel Somlo
Ruiyu Ni
Gao, Liming
Paolo Bonzini
Mauro Faccenda
Chris Ruffin
Olivier Martin
Wei Liu
Jeff Fan
Matt Fleming
Fu Siyuan
Gary Ching-Pang Lin
Eric Dong
Star Zeng