In the DXE fw_cfg instance:
- QemuFwCfgS3Enabled() queries S3 enablement via fw_cfg. This behavior is
shared with the PEI fw_cfg instance, and the DXE fw_cfg instance already
pulls in the function from "QemuFwCfgS3PeiDxe.c".
- If QemuFwCfgS3Enabled() returns TRUE, the client module is permitted to
call QemuFwCfgS3CallWhenBootScriptReady().
We provide a fully functional implementation for
QemuFwCfgS3CallWhenBootScriptReady(). A protocol notify is installed at
TPL_CALLBACK for EFI_S3_SAVE_STATE_PROTOCOL. If / once the protocol is
available, the client module's Callback() function is called, which is
expected to produce ACPI S3 Boot Script opcodes using the helper
functions listed below. In QemuFwCfgS3CallWhenBootScriptReady(), we also
allocate a reserved memory buffer, sized & typed by the client module,
for the opcodes and (internally) the fw_cfg DMA operations to work upon,
during S3 resume.
This behavior is unique to the DXE fw_cfg instance. Thus, add the
function to "QemuFwCfgS3Dxe.c".
- The QemuFwCfgS3ScriptWriteBytes(), QemuFwCfgS3ScriptReadBytes(),
QemuFwCfgS3ScriptSkipBytes(), and QemuFwCfgS3ScriptCheckValue()
functions are also implemented usefully, since the client module's
Callback() function is expected to invoke them.
Each of the first three functions produces MEM_WRITE, IO_WRITE, and
MEM_POLL opcodes, to set up the DMA command in reserved memory, to start
the DMA transfer, and to check the DMA result, respectively.
The QemuFwCfgS3ScriptCheckValue() function produces a MEM_POLL opcode to
validate an unsigned integer field in data that was read via
QemuFwCfgS3ScriptReadBytes().
This behavior is again unique to the DXE fw_cfg instance, so add the
functions to "QemuFwCfgS3Dxe.c".
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=394
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
In the PEI fw_cfg instance:
- QemuFwCfgS3Enabled() queries S3 enablement via fw_cfg. This behavior is
shared with the DXE fw_cfg instance, and the PEI fw_cfg instance already
pulls in the function from "QemuFwCfgS3PeiDxe.c".
- If QemuFwCfgS3Enabled() returns TRUE, the client module is permitted to
call QemuFwCfgS3CallWhenBootScriptReady(). However, in the PEI phase we
have no support for capturing ACPI S3 Boot Script opcodes, hence we
return RETURN_UNSUPPORTED unconditionally. This behavior is unique to
the PEI fw_cfg instance, so add the function to "QemuFwCfgS3Pei.c".
- Consequently, the QemuFwCfgS3ScriptWriteBytes(),
QemuFwCfgS3ScriptReadBytes(), QemuFwCfgS3ScriptSkipBytes(), and
QemuFwCfgS3ScriptCheckValue() functions must never be called. (They
could only be called from the client module's callback, but
QemuFwCfgS3CallWhenBootScriptReady() will never install such callback in
the PEI fw_cfg instance -- see above.)
This behavior is not unique to the PEI fw_cfg instance (it is shared
with the Base Null instance), so pull in these functions from
"QemuFwCfgS3BasePei.c".
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=394
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
In the Base Null instance:
- QemuFwCfgS3Enabled() returns constant FALSE. This is unique to the Base
Null instance, and the function is already present in
"QemuFwCfgS3Base.c".
- The QemuFwCfgS3CallWhenBootScriptReady() function must never be called
(according to the documentation, given the above). This is also unique
to the Base Null instance, so implement the function in
"QemuFwCfgS3Base.c".
- Consequently, the QemuFwCfgS3ScriptWriteBytes(),
QemuFwCfgS3ScriptReadBytes(), QemuFwCfgS3ScriptSkipBytes(), and
QemuFwCfgS3ScriptCheckValue() functions must never be called either.
This behavior is not unique to the Base Null instance (it will be shared
with the PEI fw_cfg instance), so add these functions to
"QemuFwCfgS3BasePei.c".
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=394
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Introduce the following APIs:
- QemuFwCfgS3CallWhenBootScriptReady(): central function that registers a
callback function, with a context parameter, for when ACPI S3 Boot
Script opcodes can be produced. This function also allocates reserved
memory for the opcodes to operate upon.
The client module is supposed to produce the boot script fragment in the
callback function.
- QemuFwCfgS3ScriptWriteBytes(), QemuFwCfgS3ScriptReadBytes(),
QemuFwCfgS3ScriptSkipBytes(), QemuFwCfgS3ScriptCheckValue(): helper
functions, available only to the above callback function, for composing
the boot script fragment. QemuFwCfgS3ScriptSkipBytes() can double as a
plain "select" whenever necessary.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=394
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
At this point we're ready to retire QemuFwCfgS3Enabled() from the
QemuFwCfgLib class, together with its implementations in:
- ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c
- OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c
Extend all modules that call the function with a new QemuFwCfgS3Lib class
dependency. Thanks to the previously added library class, instances, and
class resolutions, we can do this switch now as tightly as possible.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=394
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
QemuFwCfgS3Enabled() in "OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c"
queries the "etc/system-states" fw_cfg file.
The same implementation is now available factored-out in
"OvmfPkg/Library/QemuFwCfgS3Lib/QemuFwCfgS3PeiDxe.c". It is available to
PEIMs through the PeiQemuFwCfgS3LibFwCfg instance, and to DXE_DRIVER and
DXE_RUNTIME_DRIVER modules through the DxeQemuFwCfgS3LibFwCfg instance.
Resolve QemuFwCfgS3Lib accordingly.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=394
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
This patch introduces PeiQemuFwCfgS3LibFwCfg, a limited functionality
QemuFwCfgS3Lib instance, for PEI phase modules.
The patch also introduces DxeQemuFwCfgS3LibFwCfg, a full functionality
QemuFwCfgS3Lib instance, for DXE_DRIVER and DXE_RUNTIME_DRIVER modules.
These library instances share the QemuFwCfgS3Enabled() function. The
function actually uses fw_cfg; the implementation is copied from
"OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c".
The library instances will diverge in the following patches.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=394
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
This library instance returns constant FALSE from QemuFwCfgS3Enabled(),
and all other library functions trigger assertion failures. It is suitable
for QEMU targets and machine types that never enable S3.
The QemuFwCfgS3Enabled() implementation is copied from
"ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c". Stubs for further
QemuFwCfgS3Lib APIs (with assertion failures, see above) will be added
later.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=394
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
This library class will enable driver modules (a) to query whether S3
support was enabled on the QEMU command line, (b) to produce fw_cfg DMA
operations that are to be replayed at S3 resume time.
Declare the library class in OvmfPkg/OvmfPkg.dec, and add the library
class header under OvmfPkg/Include/Library/. At the moment, the only API
we expose is QemuFwCfgS3Enabled(), which we'll first migrate from
QemuFwCfgLib. Further interfaces will be added in later patches.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=394
Suggested-by: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
The OpensslLibCrypto library instance (which does not contain libssl
functions) is sufficient for the Secure Boot feature.
Ease security analysis by excluding libssl functionality from the
OpensslLib instance we use with TLS_ENABLE=FALSE.
Cc: Gary Lin <glin@suse.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Tomas Hoger <thoger@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Gary Lin <glin@suse.com>
... because this function use VA_COPY.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Introduce the FW_CFG_IO_DMA_ADDRESS macro for IO Ports 0x514 and 0x518
(most significant and least significant halves of the DMA Address
Register, respectively), and update all references in OvmfPkg.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Suggested-by: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Introduce the FW_CFG_IO_DATA macro for IO Port 0x511 (the Data Register),
and update all references in OvmfPkg.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Suggested-by: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Introduce the FW_CFG_IO_SELECTOR macro for IO Port 0x510 (the Selector
Register), and update all references in OvmfPkg.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Suggested-by: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Commit df73df138d ("OvmfPkg/AcpiPlatformDxe: replay
QEMU_LOADER_WRITE_POINTER commands at S3", 2017-02-09) added
"BootScript.c" with such comments on the PointerValue field of
CONDENSED_WRITE_POINTER, and on the corresponding PointerValue parameter
of SaveCondensedWritePointerToS3Context(), that did not consider the
then-latest update of the QEMU_LOADER_WRITE_POINTER structure. (Namely,
the introduction of the PointeeOffset field.)
The code is fine as-is -- ProcessCmdWritePointer() already calls
SaveCondensedWritePointerToS3Context() correctly, and "BootScript.c"
itself is indifferent to the exact values --, but the comments in
"BootScript.c" should match reality too. Update them.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
The Count parameter of RShiftU64() must be strictly smaller than 64.
ProcessCmdAddPointer() and ProcessCmdWritePointer() currently ensure this
by "cleverly" breaking the last bit of a potentially 8-byte right shift
out to a separate operation.
Instead, exclude the Count==64 case explicitly (in which case the
preexistent outer RShiftU64() would return 0), and keep only the inner
RShiftU64(), with the direct Count however.
This is not a functional change, just style improvement.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Suggested-by: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Ultimately, each QEMU_LOADER_WRITE_POINTER command creates a guest memory
reference in some QEMU device. When the virtual machine is reset, the
device willfully forgets the guest address, since the guest memory is
wholly invalidated during platform reset.
... Unless the reset is part of S3 resume. Then the guest memory is
preserved intact, and the firmware must reprogram those devices with the
original guest memory allocation addresses.
This patch accumulates the fw_cfg select, skip and write operations of
ProcessCmdWritePointer() in a validated / condensed form, and turns them
into an ACPI S3 Boot Script fragment at the very end of
InstallQemuFwCfgTables().
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=359
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
The QEMU_LOADER_WRITE_POINTER command instructs the firmware to write the
address of a field within a previously allocated/downloaded fw_cfg blob
into another (writeable) fw_cfg file at a specific offset.
Put differently, QEMU_LOADER_WRITE_POINTER propagates, to QEMU, the
address that QEMU_LOADER_ALLOCATE placed the designated fw_cfg blob at, as
adjusted for the given field inside the allocated blob.
The implementation is similar to that of QEMU_LOADER_ADD_POINTER. Since
here we "patch" a pointer object in "fw_cfg file space", not guest memory
space, we utilize the QemuFwCfgSkipBytes() and QemuFwCfgWriteBytes() APIs
completed in commit range 465663e9f128..7fcb73541299.
An interesting aspect is that QEMU_LOADER_WRITE_POINTER creates a
host-level reference to a guest memory location. Therefore, if we fail to
process the linker/loader script for any reason, we have to clear out
those references first, before we release the guest memory allocations in
response to the error.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=359
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
The longest line is currently 84 characters long.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=359
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
No functional changes in this patch, just prepare the grounds with some
reformatting (trailing comma after the last enumeration constant,
horizontal whitespace insertion) so that the next patch can be cleaner.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=359
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
When writing to IO port 0xB2 (ICH9_APM_CNT), QEMU by default injects an
SMI only on the VCPU that is writing the port. This has exposed corner
cases and strange behavior with edk2 code, which generally expects a
software SMI to affect all CPUs at once. We've experienced instability
despite the fact that OVMF sets PcdCpuSmmApSyncTimeout and
PcdCpuSmmSyncMode differently from the UefiCpuPkg defaults, such that they
match QEMU's unicast SMIs better. (Refer to edk2 commits 9b1e378811 and
bb0f18b0bce6.)
Using the new fw_cfg-based SMI feature negotiation in QEMU (see commits
50de920b372b "hw/isa/lpc_ich9: add SMI feature negotiation via fw_cfg" and
5ce45c7a2b15 "hw/isa/lpc_ich9: add broadcast SMI feature"), we can ask
QEMU to broadcast SMIs. Extensive testing from earlier proves that
broadcast SMIs are only reliable if we use the UefiCpuPkg defaults for the
above PCDs. With those settings however, the broadcast is very reliable --
the most reliable configuration encountered thus far.
Therefore negotiate broadcast SMIs with QEMU, and if the negotiation is
successful, dynamically revert the PCDs to the UefiCpuPkg defaults.
Setting the PCDs in this module is safe:
- only PiSmmCpuDxeSmm consumes them,
- PiSmmCpuDxeSmm is a DXE_SMM_DRIVER, launched by the SMM_CORE
(MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf),
- the SMM_CORE is launched by the SMM IPL runtime DXE driver
(MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf),
- the SMM IPL has a DEPEX on EFI_SMM_CONTROL2_PROTOCOL,
- OvmfPkg/SmmControl2Dxe produces that protocol.
The end result is that PiSmmCpuDxeSmm cannot be dispatched before
SmmControl2Dxe installs EFI_SMM_CONTROL2_PROTOCOL and returns from its
entry point. Hence we can set the PCD's consumed by PiSmmCpuDxeSmm in
SmmControl2Dxe.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=230
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Move the platform-specific default values for these PCDs from the
[PcdsFixedAtBuild] / [PcdsFixedAtBuild.X64] sections to the
[PcdsDynamicDefault] section.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=230
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Introduce the new public API QemuFwCfgSkipBytes(), for advancing over
bytes in the selected firmware configuration item without transferring
data between the item and the caller.
When the DMA interface is available (the common case), the operation is
instantaneous. As a fallback, provide a loop of chunked reads into a small
stack-allocated scratch buffer.
This patch enables OvmfPkg/QemuFwCfgLib to overwrite part of a writeable
fw_cfg file, which will be particularly useful for the upcoming
QEMU_LOADER_WRITE_POINTER command in OvmfPkg/AcpiPlatformDxe.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=359
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
The fw_cfg DMA interface provides a simple method to skip over bytes in an
fw_cfg blob before reading or writing more bytes.
InternalQemuFwCfgDmaBytes() can support it easily, we just have to expose
the Control parameter more flexibly than the current "Write" BOOLEAN.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=359
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=339
The patch removes the assumption in QemuVideoDxe driver that it
wrongly assumes the frame buffer configure size is the same in
different video modes.
The assumption is true in old FrameBufferBltLib but is false in
new implementation.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
v2
* Move the setting above the "!ifndef $(USE_OLD_SHELL)" part.
* Un-indent the setting to column zero.
(Comments from Laszlo)
Overwrite the value of PcdAllowHttpConnections to allow HTTP
connections if HTTP Boot enabled (-D HTTP_BOOT_ENABLE).
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Justen Jordan L <jordan.l.justen@intel.com>
Cc: Ye Ting <ting.ye@intel.com>
Cc: Fu Siyuan <siyuan.fu@intel.com>
Cc: Kinney Michael D <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin <jiaxin.wu@intel.com>
Reviewed-by: Ye Ting <ting.ye@intel.com>
Reviewed-by: Fu Siyuan <siyuan.fu@intel.com>
Reviewed-by: Gary Lin <glin@suse.com>
Tested-by: Gary Lin <glin@suse.com>
If the code eventually returns "Status" anyway, it does not make
sense to explicitely return "Status" in case of an error, too.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
This commit introduces a new build option, TLS_ENABLE, to pull in the
TLS-related modules. If HTTP_BOOT_ENABLE and TLS_ENABLE are enabled at
the same time, the HTTP driver locates the TLS protocols automatically
and thus HTTPS is enabled.
To build OVMF with HTTP Boot:
$ ./build.sh -D HTTP_BOOT_ENABLE
To build OVMF with HTTPS Boot:
$ ./build.sh -D HTTP_BOOT_ENABLE -D TLS_ENABLE
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Justen Jordan L <jordan.l.justen@intel.com>
Cc: Wu Jiaxin <jiaxin.wu@intel.com>
Cc: Long Qin <qin.long@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Wu Jiaxin <jiaxin.wu@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Always use IScsiDxe from NetworkPkg when IPv6 is enabled since it provides
the complete ISCSI support.
NOTE: This makes OpenSSL a hard requirement when NETWORK_IP6_ENABLE is
true.
(Based on Jiaxin's suggestion)
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Justen Jordan L <jordan.l.justen@intel.com>
Cc: Wu Jiaxin <jiaxin.wu@intel.com>
Cc: Long Qin <qin.long@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Wu Jiaxin <jiaxin.wu@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
[lersek@redhat.com: update subject line]
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
This commit provides unconditional library resolutions for the OpenSslLib,
IntrinsicLib and BaseCryptLib classes, regardless of whether those classes
are actually used by any module.
Although those libraries depends on OpenSSL, they won't be built unless
a module really uses them. Thus, missing OpenSSL from the tree won't
cause any build failure as long as SECURE_BOOT_ENABLE is false.
(Based on Jiaxin's patch and Laszlo's suggestion)
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Justen Jordan L <jordan.l.justen@intel.com>
Cc: Wu Jiaxin <jiaxin.wu@intel.com>
Cc: Long Qin <qin.long@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Wu Jiaxin <jiaxin.wu@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
The Fifo routines from the QuemuFwCfgLib library have been ported
to the new BaseIoLibIntrinsic (IoLib class) library.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Signed-off-by: Leo Duran <leo.duran@amd.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
The Debug Agent in the SourceLevelDebugPkg can multiplex
both source level debug messages and console messages on
the same UART. When this is done, the Debug Agent owns
the UART device and an additional device handle with a
Serial I/O Protocol is produced with a VenHw device path
node.
In order for a platform to provide a UART based console
when the Debug Agent is using the same UART device, the
PlatformBootManagerLib must consider the SerialI/O
Protocol produces by the Debug Agent as one of the
supported consoles.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Jeff Fan <jeff.fan@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney <michael.d.kinney@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
EFI_BOOT_SCRIPT_PCI_CONFIG_READ_WRITE_OPCODE expects the PCI address to
access in UEFI encoding, not in edk2/PciLib encoding.
Introduce the POWER_MGMT_REGISTER_Q35_EFI_PCI_ADDRESS() macro, and with
it, store the ICH9_GEN_PMCON_1 register's address to the boot script in
UEFI representation.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
While debugging OS for ACPI BGRT support (especially on VMs),
it is very useful to have the EFI firmware (OVMF in most cases
which use Tianocore) to export the ACPI BGRT table.
This patch tries to add this support in OvmfPkg.
Tested this patch in the following environments:
1. On both RHEL7.3 and Fedora-25 VM guests running on a Fedora-24 Host:
- Ensured that the BGRT logo is properly prepared and
can be viewed with user-space tools (like 'Gwenview' on KDE,
for example):
$ file /sys/firmware/acpi/bgrt/image
/sys/firmware/acpi/bgrt/image: PC bitmap, Windows 3.x format, 193 x
58 x 24
2. On a Windows-10 VM Guest running on a Fedora-24 Host:
- Ensured that the BGRT ACPI table is properly prepared and can be
read with freeware tool like FirmwareTablesView:
==================================================
Signature : BGRT
Firmware Provider : ACPI
Length : 56
Revision : 1
Checksum : 129
OEM ID : INTEL
OEM Table ID : EDK2
OEM Revision : 0x00000002
Creator ID : 0x20202020
Creator Revision : 0x01000013
Description :
==================================================
Note from Laszlo Ersek <lersek@redhat.com>: without the BGRT ACPI table,
Windows 8 and Windows 10 first clear the screen, then display a blue,
slanted Windows picture above the rotating white boot animation. With the
BGRT ACPI table, Windows 8 and Windows 10 don't clear the screen, the blue
Windows image is not displayed, and the rotating white boot animation is
shown between the firmware's original TianoCore boot splash and (optional)
"Start boot option" progress bar.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
[lersek@redhat.com: cover effect on Windows 8/10 boot anim. in commit msg]
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
The goal of the patch is to avoid using -flto with GCC 6.0 to 6.2.
This is to workaround a GCC bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70955
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
Because EFIAPI is necessary for functions declared in library class header
files.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Build-tested-by: Laszlo Ersek <lersek@redhat.com>
The benefits of the DMA-like access method are (a) speed, (b) write
support in QEMU 2.9+.
(IOPort-based write support was discontinued in QEMU 2.4, and the
DMA-based one is being added to QEMU 2.9. Write support needs no separate
feature detection because writeability is governed on the level of
individual fw_cfg files -- if a file meant to be written by the firmware
exists in the directory, then it is writeable with the DMA method.)
We don't enable this feature for the SEC library instance, because:
- the SEC instance remains without clients (I've checked that it builds
though),
- in SEC, any possible fw_cfg use is expected to be small and read-only.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
The last patch consists purely of code movement; going forward, we should
use a few more symbolic constants.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
InternalQemuFwCfgIsAvailable() is an API that is incorrectly exposed by
the "OvmfPkg/Include/Library/QemuFwCfgLib.h" library class header; the API
is meant to be used internally to library instances (if it's needed at
all).
In OvmfPkg, we have two lib instances (for SEC and PEI/DXE); they provide
different implementations of InternalQemuFwCfgIsAvailable(), for the
shared file "OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c". Move the API
declaration to a new internal header called "QemuFwCfgLibInternal.h", and
drop EFIAPI in the process.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
LzmaCustomDecompressLib and PeiDxeDebugLibReportStatusCode were copied
from IntelFrameworkModulePkg to MdeModulePkg, but the originals were
kept for compatibility.
Since the libraries are identical, move OvmfPkg to use the MdeModulePkg
versions instead.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
These settings will allow CpuMpPei and CpuDxe to wait for the initial AP
check-ins exactly as long as necessary.
It is safe to set PcdCpuMaxLogicalProcessorNumber and
PcdCpuApInitTimeOutInMicroSeconds in OvmfPkg/PlatformPei.
OvmfPkg/PlatformPei installs the permanent PEI RAM, producing
gEfiPeiMemoryDiscoveredPpiGuid, and UefiCpuPkg/CpuMpPei has a depex on
gEfiPeiMemoryDiscoveredPpiGuid.
It is safe to read the fw_cfg item QemuFwCfgItemSmpCpuCount (0x0005). It
was added to QEMU in 2008 as key FW_CFG_NB_CPUS, in commit 905fdcb5264c
("Add common keys to firmware configuration"). Even if the key is
unavailable (or if fw_cfg is entirely unavailable, for example on Xen),
QemuFwCfgRead16() will return 0, and then we stick with the current
behavior.
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Jeff Fan <jeff.fan@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Currently, the value of the page tables' address is hard-coded in the
ResetVector. This patch replaces these values with a PCD dependency.
A check for the size has been added to alert the developer to rewrite
the ASM according to the new size, if it has been changed.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marvin Haeuser <Marvin.Haeuser@outlook.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Remove the ResetVector.asm file as it is no longer referenced since
the switch to ResetVector.nasmb.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marvin Haeuser <Marvin.Haeuser@outlook.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Convert the remaining pieces to make the code shorter and more readable.
Cc: Justen Jordan <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
[lersek@redhat.com: tweak subject line]
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Rely on the central macro definition from "MdePkg/Include/Base.h" instead.
Cc: Gary Lin <glin@suse.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Gary Lin <glin@suse.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Rely on the central macro definition from "MdePkg/Include/Base.h" instead.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
In one of the next patches, we'll introduce ARRAY_SIZE in
"MdePkg/Include/Base.h". In order to proceed in small steps, make the
module-local definition of ARRAY_SIZE conditional. This way the
introduction of the macro under MdePkg will silently switch this module
over (after which we can remove the module-local definition completely).
Cc: Gary Lin <glin@suse.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Gary Lin <glin@suse.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
In one of the next patches, we'll introduce ARRAY_SIZE in
"MdePkg/Include/Base.h". In order to proceed in small steps, make the
module-local definition of ARRAY_SIZE conditional. This way the
introduction of the macro under MdePkg will silently switch this module
over (after which we can remove the module-local definition completely).
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
XenConsoleSerialPortLib is a BASE type library instance, without being
restricted to UEFI client modules. (For example, the
"ArmVirtPkg/ArmVirtXen.dsc" platform builds this library instance into
"ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf", which is a SEC type
module.) For such library instances, including <Uefi/UefiBaseType.h> is
not right.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
These are deprecated / disabled under the
DISABLE_NEW_DEPRECATED_INTERFACES feature test macro.
Introduce a variable called PcdStatus, and use it to assert the success of
these operations (there is no reason for them to fail here).
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=166
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
These are deprecated / disabled under the
DISABLE_NEW_DEPRECATED_INTERFACES feature test macro.
Introduce a variable called PcdStatus, and use it to assert the success of
these operations (there is no reason for them to fail here).
Cc: Anthony PERARD <anthony.perard@citrix.com>
Cc: Gary Lin <glin@suse.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=166
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Gary Lin <glin@suse.com>
Tested-by: Gary Lin <glin@suse.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
These are deprecated / disabled under the
DISABLE_NEW_DEPRECATED_INTERFACES feature test macro.
Introduce a variable called PcdStatus, and use it to assert the success of
these operations (there is no reason for them to fail here).
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=166
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> # RVCT
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
These are deprecated / disabled under the
DISABLE_NEW_DEPRECATED_INTERFACES feature test macro.
Introduce a variable called PcdStatus, and use it to assert the success of
these operations (there is no reason for them to fail here).
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=166
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> # RVCT
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
These are deprecated / disabled under the
DISABLE_NEW_DEPRECATED_INTERFACES feature test macro.
Introduce a variable called PcdStatus, and use it to assert the success of
these operations (there is no reason for them to fail here).
Cc: Anthony PERARD <anthony.perard@citrix.com>
Cc: Gary Lin <glin@suse.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=166
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Gary Lin <glin@suse.com>
Tested-by: Gary Lin <glin@suse.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
These are deprecated / disabled under the
DISABLE_NEW_DEPRECATED_INTERFACES feature test macro.
Introduce a variable called PcdStatus, and use it to assert the success of
these operations (there is no reason for them to fail here).
Cc: Anthony PERARD <anthony.perard@citrix.com>
Cc: Gary Lin <glin@suse.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=166
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Gary Lin <glin@suse.com>
Tested-by: Gary Lin <glin@suse.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
AsciiStrCat() is deprecated / disabled under the
DISABLE_NEW_DEPRECATED_INTERFACES feature test macro.
Replace AsciiStrCat() with AsciiSPrint(). Spell out the (already existent)
PrintLib dependency in the INF file. Add an explicit ASSERT() to document
that XenStoreJoin() assumes that the pool allocation always succeeds.
Cc: Anthony PERARD <anthony.perard@citrix.com>
Cc: Gary Lin <glin@suse.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=166
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Gary Lin <glin@suse.com>
Tested-by: Gary Lin <glin@suse.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
AsciiStrCpy() is deprecated / disabled under the
DISABLE_NEW_DEPRECATED_INTERFACES feature test macro.
Cc: Anthony PERARD <anthony.perard@citrix.com>
Cc: Gary Lin <glin@suse.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=166
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Gary Lin <glin@suse.com>
Tested-by: Gary Lin <glin@suse.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
In commit 5b2291f956 ("OvmfPkg: QemuVideoDxe uses
MdeModulePkg/FrameBufferLib"), QemuVideoDxe was rebased to
FrameBufferBltLib.
The FrameBufferBltLib instance added in commit b1ca386074
("MdeModulePkg: Add FrameBufferBltLib library instance") logs many
messages on the VERBOSE level; for example, a normal boot with OVMF can
produce 500+ "VideoFill" messages, dependent on the progress bar, when the
VERBOSE bit is set in PcdDebugPrintErrorLevel. While FrameBufferBltLib is
certainly allowed to log such messages on the VERBOSE level, we should
separate those frequent messages from the (infrequent) ones produced by
QemuVideoDxe itself.
QemuVideoDxe logs VERBOSE messages in three locations (in two functions)
at the moment. All of them are infrequent: both QemuVideoBochsModeSetup()
and InstallVbeShim() are called from QemuVideoControllerDriverStart(),
that is, when a device is bound. Upgrade these messages to INFO level, so
that VERBOSE can be disabled in PcdDebugPrintErrorLevel -- perhaps
selectively for OvmfPkg/QemuVideoDxe -- without hiding these infrequent
messages.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
This field is (re)allocated in QemuVideoGraphicsOutputSetMode(), released
in QemuVideoGraphicsOutputDestructor(), and used for nothing else. Remove
it.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
This field is never used.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Thanks to the previous patch, this field is also unnecessary now. Remove
it.
The patch is best reviewed with "git show --word-diff".
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
This field is never used beyond assignment and debug-logging. Remove it.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
One of the following patches will change QemuVideoDxe driver
to use the new FrameBufferLib.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Laszlo Ersek <lersek at redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Prototype of BootLogoEnableLogo will change in following patches, so
do not call BootLogoEnableLogo to avoid build failure.
Contributed-under: TianoCore Contribution Agreement 1.0
Cc: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Correct some typos in the header files of the OvmfPkg
(which have been discovered with the codespell utility).
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Correct some typos (discovered with the codespell utility)
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Thomas Huth <thuth@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Run "unix2dos" on the affected files. "git show -b" produces no diff for
this patch.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Thomas Huth <thuth@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
The header file includes the UTF-8 encoding (0xE2 0x80 0x99) of the U+2019
(RIGHT SINGLE QUOTATION MARK) code point. Replace it with a simple
apostrophe (U+0027, ASCII 0x27).
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Thomas Huth <thuth@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Translating QEMU's virtio-block OpenFirmware device path to a UEFI device
path prefix was one of the earliest case handled in QemuBootOrderLib. At
that time, I terminated the translation output (the UEFI devpath prefix)
with a "/HD(" suffix.
The intent was for the translation to prefix-match only boot options with
HD() device path nodes in them, that is, no auto-generated "device level"
boot options. This was motivated by prioritizing specific boot options
created by OS installers over auto-generated "device level" options.
However, practice has shown that:
- OS installers place their installed boot options first in the boot order
anyway,
- other device types (SATA disks, virtio-scsi disks), where "/HD(" is not
appended, work just fine,
- requiring "/HD(" actually causes problems: after the OS-installed
specific boot option has been lost (or purposely removed), the
auto-generated "device level" boot option does the right thing (see the
Default Boot Behavior under
<http://blog.uncooperative.org/blog/2014/02/06/the-efi-system-partition/>).
The "/HD(" requirement causes such boot options to be dropped, which
prevents "fallback.efi" from running.
Relax the matching by removing the "/HD(" suffix from the translated
prefix.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Fixes: e06a4cd134
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1373812
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
In this patch we replace our "dummy" Graphics Output Protocol interface
with the real one. We exploit that EFI_GRAPHICS_OUTPUT_BLT_PIXEL and
VirtioGpuFormatB8G8R8X8Unorm have identical representations; this lets us
forego any pixel format conversions in the guest. For messaging the VirtIo
GPU device, we use the primitives introduced in the previous patch.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://tianocore.acgmultimedia.com/show_bug.cgi?id=66
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
In this patch we add a "workhorse" function called VirtioGpuSendCommand(),
and implement seven simple RPCs atop, for the command types listed in
"OvmfPkg/Include/IndustryStandard/VirtioGpu.h".
These functions will be called by our EFI_GRAPHICS_OUTPUT_PROTOCOL
implementation.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://tianocore.acgmultimedia.com/show_bug.cgi?id=66
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
This patch implements the steps listed in section "3.1.1 Driver
Requirements: Device Initialization" of the Virtio V1.0 Committee Spec 04.
The VirtIo GPU is brought up in VirtioGpuDriverBindingStart(), and down in
VirtioGpuDriverBindingStop().
We also add an ExitBootServices() callback that resets the device. This
ensures that the device model abandons any guest memory areas when we
transfer control to the guest OS.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://tianocore.acgmultimedia.com/show_bug.cgi?id=66
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
At this stage, the driver builds, and suffices for testing binding and
unbinding.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://tianocore.acgmultimedia.com/show_bug.cgi?id=66
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
This patch adds the skeleton of the driver: it implements the Component
Name 2 Protocol and the Driver Binding Protocol, in accordance with the
generic and GOP-specific requirements set forth in the UEFI spec and the
Driver Writers' Guide.
The basic idea is that VGPU_DEV abstracts the virtio GPU device, while the
single VGPU_GOP that we intend to support at this point stands for "head"
(aka "scanout") #0.
For now, the Virtio Device Protocol is only used for driver binding; no
actual virtio operations are done yet. Similarly, we use a "dummy" GOP
GUID and protocol structure (a plain UINT8 object) for now, so that
GOP-consuming drivers don't look at what we produce just yet.
The driver is a bit different from the other virtio device drivers written
thus far:
- It implements the GetControllerName() member of the Component Name 2
Protocol. (Formatting helpful names is recommended by UEFI.) As a "best
effort", we format the PCI BDF into the name (a PCI backend is not
guaranteed by VIRTIO_DEVICE_PROTOCOL). It should provide a more friendly
experience in the shell and elsewhere.
- This driver seeks to support all RemainingDevicePath cases:
- NULL: produce all (= one) child handles (= VGPU_GOP heads) at once,
- End of Device Path Node: produce no child handles,
- specific ACPI ADR Node: check if it's supportable, and produce it
(only one specific child controller is supported).
This is one of the reasons for separating VGPU_GOP from VGPU_DEV.
The driver is a hybrid driver: it produces both child handles (one, to be
exact), but also installs a structure (VGPU_DEV) directly on the VirtIo
controller handle, using gEfiCallerIdGuid as protocol GUID. This is a
trick I've seen elsewhere in edk2 (for example, TerminalDxe), and it is
necessary for the following reason:
In EFI_COMPONENT_NAME2_PROTOCOL.GetControllerName(), we must be able to
"cast down" a VirtIo ControllerHandle to our own private data structure
(VGPU_DEV). That's only possible if we install the structure directly on
the VirtIo ControllerHandle (thereby rendering the driver a hybrid
driver), because a child controller with our GOP implementation on it may
not exist / be passed in there.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://tianocore.acgmultimedia.com/show_bug.cgi?id=66
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
The GPU additions to VirtIo 1.0 are a work in progress. Mark the relevant
URLs in the source code. Incorporate the absolute minimum from the WIP
spec that is necessary for implementing a GOP driver.
Add the VIRTIO_SUBSYSTEM_GPU_DEVICE macro to
"IndustryStandard/Virtio10.h", since all other such macros (dating back to
VirtIo 0.9.5) are part of "IndustryStandard/Virtio095.h".
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://tianocore.acgmultimedia.com/show_bug.cgi?id=66
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
This will add virtio-gpu-pci devices to ConOut automatically.
For further benefit, the change also allows OVMF to use the legacy-free /
secondary VGA adapter (added in QEMU commit 63e3e24d, "vga: add secondary
stdvga variant") as console.
ArmVirtPkg's PlatformBootManagerLib already filters with IS_PCI_DISPLAY();
see IsPciDisplay().
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://tianocore.acgmultimedia.com/show_bug.cgi?id=66
Originally-suggested-by: Gerd Hoffmann <kraxel@redhat.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>
Commit 9399f68ae3 ("OvmfPkg: Virtio10Dxe: non-transitional driver for
virtio-1.0 PCI devices") created a "competition" between Virtio10Dxe and
QemuVideoDxe for virtio-vga devices. The binding order between these
drivers is unspecified, and the wrong order effectively breaks commit
94210dc95e ("OvmfPkg: QemuVideoDxe: add virtio-vga support").
Thus, never bind virtio-vga in Virtio10Dxe; QemuVideoDxe provides better
compatibility for guest OSes that insist on inheriting a linear
framebuffer. Users who prefer the VirtIo GPU interface at boot time should
specify virtio-gpu-pci, which is exactly virtio-vga, minus the VGA
compatibility (such as the framebuffer).
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://tianocore.acgmultimedia.com/show_bug.cgi?id=66
Fixes: 9399f68ae3
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
The PCI (Vendor ID, Device ID) pair (0x1af4, 0x1050) stands for both the
virtio-vga and the virtio-gpu-pci device models of QEMU. They differ in
two things:
- the former has a VGA-compatibility linear framebuffer on top of the
latter,
- the former has PCI_CLASS_DISPLAY_VGA device class, while the latter has
PCI_CLASS_DISPLAY_OTHER.
In commit 94210dc95e ("OvmfPkg: QemuVideoDxe: add virtio-vga support"),
we enabled QemuVideoDxe to drive virtio-vga simply by adding its (Vendor
ID, Device ID) pair to gQemuVideoCardList. This change inadvertently
allowed QemuVideoDxe to bind virtio-gpu-pci, which it cannot drive though.
Restrict QemuVideoDxe to PCI_CLASS_DISPLAY_VGA, in order to exclude
virtio-gpu-pci. For the other cards that QemuVideoDxe drives, this makes
no difference. (Note that OvmfPkg's PlatformBootManagerLib instance has
always only added PCI_CLASS_DISPLAY_VGA devices to ConOut; see
DetectAndPreparePlatformPciDevicePath().)
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://tianocore.acgmultimedia.com/show_bug.cgi?id=66
Fixes: 94210dc95e
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
In the Platform Init v1.4a spec,
- Volume 1 "4.7 Status Code Service" defines the
EFI_PEI_SERVICES.ReportStatusCode() service,
- Volume 1 "6.3.5 Status Code PPI (Optional)" defines the
EFI_PEI_PROGRESS_CODE_PPI (equivalent to the above),
- Volume 2 "14.2 Status Code Runtime Protocol" defines the
EFI_STATUS_CODE_PROTOCOL.
These allow PEIMs and DXE (and later) modules to report status codes.
Currently OvmfPkg uses modules from under
"IntelFrameworkModulePkg/Universal/StatusCode/", which produce the above
abstractions (PPI and PROTOCOL) directly, and write the status codes, as
they are reported, to the serial port or to a memory buffer. This is
called "handling" the status codes.
In the Platform Init v1.4a spec,
- Volume 3 "7.2.2 Report Status Code Handler PPI" defines
EFI_PEI_RSC_HANDLER_PPI,
- Volume 3 "7.2.1 Report Status Code Handler Protocol" defines
EFI_RSC_HANDLER_PROTOCOL.
These allow several PEIMs and runtime DXE drivers to register callbacks
for status code handling.
MdeModulePkg offers a PEIM under
"MdeModulePkg/Universal/ReportStatusCodeRouter/Pei" that produces both
EFI_PEI_PROGRESS_CODE_PPI and EFI_PEI_RSC_HANDLER_PPI, and a runtime DXE
driver under "MdeModulePkg/Universal/ReportStatusCodeRouter/RuntimeDxe"
that produces both EFI_STATUS_CODE_PROTOCOL and EFI_RSC_HANDLER_PROTOCOL.
MdeModulePkg also offers status code handler modules under
MdeModulePkg/Universal/StatusCodeHandler/ that depend on
EFI_PEI_RSC_HANDLER_PPI and EFI_RSC_HANDLER_PROTOCOL, respectively.
The StatusCodeHandler modules register themselves with
ReportStatusCodeRouter through EFI_PEI_RSC_HANDLER_PPI /
EFI_RSC_HANDLER_PROTOCOL. When another module reports a status code
through EFI_PEI_PROGRESS_CODE_PPI / EFI_STATUS_CODE_PROTOCOL, it reaches
the phase-matching ReportStatusCodeRouter module first, which in turn
passes the status code to the pre-registered, phase-matching
StatusCodeHandler module.
The status code handling in the StatusCodeHandler modules is identical to
the one currently provided by the IntelFrameworkModulePkg modules. Replace
the IntelFrameworkModulePkg modules with the MdeModulePkg ones, so we can
decrease our dependency on IntelFrameworkModulePkg.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Cinnamon Shia <cinnamon.shia@hpe.com>
Suggested-by: Liming Gao <liming.gao@intel.com>
Fixes: https://tianocore.acgmultimedia.com/show_bug.cgi?id=63
[jordan.l.justen@intel.com: point out IntelFareworkModulePkg typos]
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
[lersek@redhat.com: rewrap to 74 cols; fix IntelFareworkModulePkg typos]
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
Support down-stream projects that require large DXEFV sizes greater
than 16MB by handling SECTION2 common headers. These are already
created by the build tools when necessary.
Use IS_SECTION2 and SECTION2_SIZE macros to calculate accurate image
sizes when appropriate.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Thomas Palmer <thomas.palmer@hpe.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
[lersek@redhat.com: fix NB->MB typo in commit message]
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Drop superfluous casts. There is no change in behavior because
EFI_FIRMWARE_VOLUME_IMAGE_SECTION is just a typedef of
EFI_COMMON_SECTION_HEADER.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Thomas Palmer <thomas.palmer@hpe.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
VS2015x86 reports the following warning for
"OvmfPkg/PlatformPei/MemDetect.c":
> MemDetect.c(357): error C2220: warning treated as error - no 'object'
> file generated
> MemDetect.c(357): warning C4244: '=': conversion from 'UINT64' to
> 'UINT32', possible loss of data
LowerMemorySize is first assigned from GetSystemMemorySizeBelow4gb(),
which returns UINT32. Change the type of LowerMemorySize accordingly.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
When compiling "OvmfPkg\Library\PciHostBridgeLib\XenSupport.c" for IA32,
the VS2015x86 compiler emits the following:
> XenSupport.c(41): error C2220: warning treated as error - no 'object'
> file generated
> XenSupport.c(41): warning C4244: 'function': conversion from 'UINT64' to
> 'UINTN', possible loss of data
> XenSupport.c(48): warning C4244: 'function': conversion from 'UINT64' to
> 'UINTN', possible loss of data
> XenSupport.c(49): warning C4244: 'function': conversion from 'UINT64' to
> 'UINTN', possible loss of data
> XenSupport.c(50): warning C4244: 'function': conversion from 'UINT64' to
> 'UINTN', possible loss of data
> XenSupport.c(222): warning C4244: 'function': conversion from 'UINT64'
> to 'UINTN', possible loss of data
> XenSupport.c(241): warning C4244: 'function': conversion from 'UINT64'
> to 'UINTN', possible loss of data
PciLib functions take UINTN addresses that were encoded with the
PCI_LIB_ADDRESS() macro. We carry addresses from the macro invocations to
the function calls in two UINT64 variables however. This loses no data,
but it alerts VS2015x86. Change the variable types to UINTN.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Under certain circumstances, QEMU exposes the "etc/msr_feature_control"
fw_cfg file, with a 64-bit little endian value. The firmware is supposed
to write this value to MSR_IA32_FEATURE_CONTROL (0x3a), on all processors,
on the normal and the S3 resume boot paths.
Utilize EFI_PEI_MPSERVICES_PPI to implement this feature.
Cc: Jeff Fan <jeff.fan@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Fixes: https://github.com/tianocore/edk2/issues/97
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
In the next patch we're going to put EFI_PEI_MP_SERVICES_PPI to use.
CpuMpPei uses the following PCDs from gUefiCpuPkgTokenSpaceGuid, beyond
those already used by CpuDxe:
- PcdCpuMicrocodePatchAddress and PcdCpuMicrocodePatchRegionSize: these
control whether CpuMpPei performs microcode update. If the region size
is zero, then the microcode update is skipped. UefiCpuPkg.dec sets the
region size to zero by default, which is appropriate for OVMF.
- PcdCpuApLoopMode and PcdCpuApTargetCstate: the former controls how
CpuMpPei puts the APs to sleep: 1 -- HLT, 2 -- MWAIT, 3 -- busy wait
(with PAUSE). The latter PCD is only relevant if the former PCD is 2
(MWAIT). In order to be consistent with SeaBIOS and with CpuDxe itself,
we choose HLT. That's the default set by UefiCpuPkg.dec.
Furthermore, although CpuMpPei could consume SecPeiCpuExceptionHandlerLib
technically, it is supposed to consume PeiCpuExceptionHandlerLib. See:
- http://thread.gmane.org/gmane.comp.bios.edk2.devel/12703
- git commit a81abf1616 ("UefiCpuPkg/ExceptionLib: Import
PeiCpuExceptionHandlerLib module"), part of the series linked above.
Jeff recommended to resolve CpuExceptionHandlerLib to
PeiCpuExceptionHandlerLib for all PEIMs:
- http://thread.gmane.org/gmane.comp.bios.edk2.devel/14471/focus=14477
Since at the moment we have no resolution in place that would cover this
for PEIMs (from either [LibraryClasses] or [LibraryClasses.common.PEIM]),
it's easy to do.
Cc: Jeff Fan <jeff.fan@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
No module in OvmfPkg uses these PCDs any longer.
The first PCD mentioned is declared by OvmfPkg, so we can remove even the
declaration.
The second PCD comes from IntelFrameworkModulePkg. The module that
consumes PcdS3AcpiReservedMemorySize is called
"IntelFrameworkModulePkg/Universal/Acpi/AcpiS3SaveDxe", and it is built
into OVMF. However, AcpiS3SaveDxe consumes the PCD only conditionally: it
depends on the feature PCD called PcdFrameworkCompatibilitySupport, which
we never enable in OVMF.
The 32KB gap that used to be the S3 permanent PEI memory is left unused in
MEMFD for now; it never hurts to have a few KB available there, for future
features.
Cc: Jeff Fan <jeff.fan@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Move the permanent PEI memory for the S3 resume boot path to the top of
the low RAM (just below TSEG if the SMM driver stack is included in the
build). The new size is derived from CpuMpPei's approximate memory demand.
Save the base address and the size in new global variables, regardless of
the boot path. On the normal boot path, use these variables for covering
the area with EfiACPIMemoryNVS type memory.
PcdS3AcpiReservedMemoryBase and PcdS3AcpiReservedMemorySize become unused
in PlatformPei; remove them.
Cc: Jeff Fan <jeff.fan@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
CpuMpPei will have to place the AP startup vector in memory under 1MB. For
this, CpuMpPei borrows memory under 1MB, but it needs a memory resource
descriptor HOB to exist there even on the S3 resume path (see the
GetWakeupBuffer() function). Produce such a HOB as an exception on the S3
resume path.
CpuMpPei is going be dispatched no earlier than PlatformPei, because
CpuMpPei has a depex on gEfiPeiMemoryDiscoveredPpiGuid, and PlatformPei
calls PublishSystemMemory().
Cc: Jeff Fan <jeff.fan@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
The E820EntriesCount variable in XenPublishRamRegions() may be
referenced without being initialized on RELEASE builds, since the
ASSERT that fires if the call to XenGetE820Map() fails is compiled
out in that case. So initialize it to 0.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
After IncompatiblePciDeviceSupportDxe, this is another small driver /
protocol implementation that tweaks the behavior of the PCI bus driver in
edk2.
The protocol is specified in the Platform Init Spec v1.4a, Volume 5,
Chapter 12.6 "PCI Hot Plug PCI Initialization Protocol". This
implementation steers the PCI bus driver to reserve the following
resources ("padding") for each PCI bus, in addition to the BARs of the
devices on that PCI bus:
- 2MB of 64-bit non-prefetchable MMIO aperture,
- 512B of IO port space.
The goal is to reserve room for devices hot-plugged at runtime even if the
bridge receiving the device is empty at boot time.
The 2MB MMIO size is inspired by SeaBIOS. The 512B IO port size is
actually only 1/8th of the PCI spec mandated reservation, but the
specified size of 4096 has proved wasteful (given the limited size of our
IO port space -- see commit bba734ab4c). Especially on Q35, where every
PCIe root port and downstream port qualifies as a separate bridge (capable
of accepting a single device).
Test results for this patch:
- regardless of our request for 64-bit MMIO reservation, it is downgraded
to 32-bit,
- although we request 512B alignment for the IO port space reservation,
the next upstream bridge rounds it up to 4096B.
Cc: "Johnson, Brian J." <bjohnson@sgi.com>
Cc: Alex Williamson <alex.williamson@redhat.com>
Cc: Andrew Fish <afish@apple.com>
Cc: Feng Tian <feng.tian@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Marcel Apfelbaum <marcel@redhat.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Suggested-by: Andrew Fish <afish@apple.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Ruiyu Ni <Ruiyu.ni@intel.com>
Removes any boot options that point to binaries built into the firmware
and have become stale due to any of the following:
- DXEFV's base address or size changed (historical),
- DXEFV's FvNameGuid changed,
- the FILE_GUID of the pointed-to binary changed,
- the referenced binary is no longer built into the firmware.
For example, multiple such "EFI Internal Shell" boot options can coexist.
They technically differ from each other, but may not describe any built-in
shell binary exactly. Such options can accumulate in a varstore over time,
and while they remain generally bootable (thanks to the efforts of
BmGetFileBufferByFvFilePath()), they look bad.
Filter out any stale options.
This functionality is not added to QemuBootOrderLib, because it is
independent from QEMU and fw_cfg.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Gary Lin <glin@suse.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
The FDF spec mentions the FvNameGuid statement for [FV.xxxx] sections, but
the detailed description can be found in Volume 3 of the Platform Init
spec (which is at 1.4a currently).
Adding an FvNameGuid statement to [FV.xxx] has the following effects
(implemented by "BaseTools/Source/C/GenFv/GenFvInternalLib.c"):
- The EFI_FIRMWARE_VOLUME_HEADER.ExtHeaderOffset field is set to a nonzero
value, pointing after EFI_FIRMWARE_VOLUME_HEADER itself (although not
directly, see below).
- An EFI_FIRMWARE_VOLUME_EXT_HEADER object is created at the pointed-to
address. This object is not followed by any
EFI_FIRMWARE_VOLUME_EXT_ENTRY (= extension) entries, so it only
specifies the Name GUID for the firmware volume.
The EFI_FIRMWARE_VOLUME_EXT_HEADER for each firmware volume can be found
in the Build directory as a separate file (20 bytes in size):
Build/Ovmf*/*_GCC*/FV/*.ext
- The new data consume 48 bytes in the following volumes: SECFV,
FVMAIN_COMPACT, DXEFV. They comprise:
- 16 padding bytes,
- EFI_FFS_FILE_HEADER2 (8 bytes in total: no Name and ExtendedSize
fields, and Type=EFI_FV_FILETYPE_FFS_PAD),
- EFI_FIRMWARE_VOLUME_EXT_HEADER (20 bytes, see above),
- 4 padding bytes.
(The initial 16 padding bytes and the EFI_FFS_FILE_HEADER2 structure are
the reason why EFI_FIRMWARE_VOLUME_HEADER.ExtHeaderOffset does not point
immediately past EFI_FIRMWARE_VOLUME_HEADER.)
The sizes of the firmware volumes don't change, only their internal
usages grow by 48 bytes. I verified that the statements and calculations
in "OvmfPkg/DecomprScratchEnd.fdf.inc" are unaffected and remain valid.
- The new data consume 0 bytes in PEIFV. This is because PEIFV has enough
internal padding at the moment to accomodate the above structures
without a growth in usage.
In the future, firmware volumes can be identified by Name GUID (Fv(...)
device path nodes), rather than memory location (MemoryMapped(...) device
path nodes). This is supposed to improve stability for persistent device
paths that refer to FFS files; for example, UEFI boot options.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Suggested-by: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
The Driver Health HII menu is not an integral part of the MdeModulePkg BDS
driver / UI app. Because we abandoned the IntelFrameworkModulePkg BDS, now
we have to get the same functionality explicitly from
DriverHealthManagerDxe.
Suggested-by: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Bruce Cran <bruce.cran@gmail.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
[lersek@redhat.com: update commit message]
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
The default stack size (from UefiCpuPkg/UefiCpuPkg.dec) is 8KB, which
proved too small (i.e., led to stack overflow) across commit range
98c2d9610506^..f85d3ce2efc2^, during certificate enrollment into "db".
As the edk2 codebase progresses and OVMF keeps including features, the
stack demand constantly fluctuates; double the SMM stack size for good
measure.
Cc: Jeff Fan <jeff.fan@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Ref: http://thread.gmane.org/gmane.comp.bios.edk2.devel/12864
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1341733
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
When OVMF tried to load the file-based NvVars, it checked all the PCI
instances and connected the drivers to the mass storage device. However,
Xen registered its PCI device with a special class id (0xFF80), so
ConnectRecursivelyIfPciMassStorage() couldn't recognize it and skipped the
driver connecting for Xen PCI devices. In the end, the Xen block device
wasn't initialized until EfiBootManagerConnectAll() was called, and it's
already too late to load NvVars.
This commit connects the Xen drivers in ConnectRecursivelyIfPciMassStorage()
so that Xen can use the file-based NvVars.
v3:
* Introduce XenDetected() to cache the result of Xen detection instead
of relying on PcdPciDisableBusEnumeration.
v2:
* Cosmetic changes
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
We reached the size limit again.
Building OVMF with the following command
$ ./OvmfPkg/build.sh -D SECURE_BOOT_ENABLE -D NETWORK_IP6_ENABLE -D HTTP_BOOT_ENABLE
and it ended up with
GenFds.py...
GenFv: ERROR 3000: Invalid
: error 7000: Failed to generate FV
the required fv image size 0x900450 exceeds the set fv image size 0x900000
Since the new UEFI features, such as HTTPS, are coming, we need a
larger DEXFV eventually.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
OVMF (unlike ArmVirtPkg) has traditionally cleared the screen after
connecting devices. This is not really necessary, and keeping the logo up
while the progress bar is advancing at the bottom looks great. So don't
clear the screen.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
OVMF's Platform BDS used to have a nice progress bar (with
IntelFrameworkModulePkg BDS). We can restore it by copying the
PlatformBootManagerWaitCallback() function verbatim from
Nt32Pkg/Library/PlatformBootManagerLib/PlatformBootManager.c
It can be tested by passing the following option to QEMU (5 seconds):
-boot menu=on,splash-time=5000
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
In the course of porting OvmfPkg to the MdeModulePkg BDS, commit
817fb3ac2a
OvmfPkg/PlatformBootManagerLib: Add EnableQuietBoot & DisableQuietBoot
open-coded the EnableQuietBoot() function (and its dependencies / friends)
from IntelFrameworkModulePkg BDS.
This code duplication can be avoided; the functionality is available from
the following three libraries in MdeModulePkg:
- BootLogoLib: provides the BootLogoEnableLogo() function. It does not
provide the internal ConvertBmpToGopBlt() function -- that one is
delegated to ImageDecoderLib (function DecodeImage()).
- ImageDecoderLib: a general library that registers decoder plugins for
specific image formats, and provides the generic DecodeImage() on top.
- BmpImageDecoderLib: one of said decoder plugins, for handling BMP images
(which is the format of our logo).
In this patch, we revert 817fb3ac2a, and atomically incorporate the
above libraries. This is inspired by Nt32Pkg commit 859e75c4fc42:
Nt32Pkg: Use BootLogoLib for logo and progress bar drawing.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
When OVMF tried to restore the variables from the file-based NvVars, it
failed to set the read-only variable and aborted the restoration with
this message:
Variable Check ReadOnly variable fail Write Protected - 04B37FE8-F6AE-480B-BDD5-37D98C5E89AA:VarErrorFlag
Since it's a read-only variable maintained by the firmware, it's
pointless to restore the previous value, so the check can be
relaxed to allow EFI_WRITE_PROTECTED returned from SetVariable.
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
"SerializeVariablesLib.h" is pure LF, while "SerializeVariablesLib.c" is
mixed (its only CRLF terminators are from commit e678f9db89). Convert
them both with "unix2dos".
"git show -b" produces no code hunks for this patch. Due to its simple and
mechanic nature (and because it blocks the application of another patch),
it's being committed without review.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
According to edk2 commit
"MdeModulePkg/PciBus: do not improperly degrade resource"
and to the EFI_INCOMPATIBLE_PCI_DEVICE_SUPPORT_PROTOCOL definition in the
Platform Init 1.4a specification, a platform can provide such a protocol
in order to influence the PCI resource allocation performed by the PCI Bus
driver.
In particular it is possible instruct the PCI Bus driver, with a
"wildcard" hint, to allocate the 64-bit MMIO BARs of a device in 64-bit
address space, regardless of whether the device features an option ROM.
(By default, the PCI Bus driver considers an option ROM reason enough for
allocating the 64-bit MMIO BARs in 32-bit address space. It cannot know if
BDS will launch a legacy boot option, and under legacy boot, a legacy BIOS
binary from a combined option ROM could be dispatched, and fail to access
MMIO BARs in 64-bit address space.)
In platform code we can ascertain whether a CSM is present or not. If not,
then legacy BIOS binaries in option ROMs can't be dispatched, hence the
BAR degradation is detrimental, and we should prevent it. This is expected
to conserve the 32-bit address space for 32-bit MMIO BARs.
The driver added in this patch could be simplified based on the following
facts:
- In the Ia32 build, the 64-bit MMIO aperture is always zero-size, hence
the driver will exit immediately. Therefore the driver could be omitted
from the Ia32 build.
- In the Ia32X64 and X64 builds, the driver could be omitted if CSM_ENABLE
was defined (because in that case the degradation would be justified).
On the other hand, if CSM_ENABLE was undefined, then the driver could be
included, and it could provide the hint unconditionally (without looking
for the Legacy BIOS protocol).
These short-cuts are not taken because they would increase the differences
between the OVMF DSC/FDF files. If we can manage without extreme
complexity, we should use dynamic logic (vs. build time configuration),
plus keep conditional compilation to a minimum.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
This completes the transition to the new BDS.
The FILE_GUID in "QemuBootOrderLib.inf" is intentionally not changed.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Gary Ching-Pang Lin <glin@suse.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
With OvmfPkg's original QemuBootOrderLib (and USE_OLD_BDS) gone, we no
longer need the BootOptionList parameter in the SetBootOrderFromQemu()
prototype. Update the library class header file (including the function's
documentation), and adapt the library instance and the call sites.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Gary Ching-Pang Lin <glin@suse.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
This library instance is no longer referenced.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Gary Ching-Pang Lin <glin@suse.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
This library instance is no longer referenced.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Gary Ching-Pang Lin <glin@suse.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reasons:
- USE_OLD_BDS requires duplicating updates between OVMF's library
instances that depend on USE_OLD_BDS being FALSE vs. TRUE. Examples:
d5aee61bfa OvmfPkg/QemuNewBootOrderLib: adapt Q35 SATA PMPN to UEFI
spec Mantis 1353
1da7616649 OvmfPkg/QemuBootOrderLib: adapt Q35 SATA PMPN to UEFI spec
Mantis 1353
- The Xen community has embraced the new BDS. Examples:
14b2ebc30c OvmfPkg/PlatformBootManagerLib: Postpone the shell
registration
49effaf26e OvmfPkg/PciHostBridgeLib: Scan for root bridges when
running over Xen
- OVMF doesn't build with "-D USE_OLD_BDS -D HTTP_BOOT_ENABLE" anyway, as
NetworkPkg/HttpBootDxe now requires UefiBootManagerLib:
50a65824c7 NetworkPkg: Use UefiBootManagerLib API to create load
option.
We (correctly) don't resolve UefiBootManagerLib when USE_OLD_BDS is
TRUE.
- The new BDS has been working well; for example it's the only BDS
available in ArmVirtPkg:
1946faa710 ArmVirtPkg/ArmVirtQemu: use MdeModulePkg/BDS
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Gary Ching-Pang Lin <glin@suse.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
The "UNIXGCC Debug" section happens to name PlatformBdsLib and
IntelFrameworkModulePkg's BdsDxe as examples. OVMF will soon stop offering
those even as a fallback option.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Gary Ching-Pang Lin <glin@suse.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
This can accommodate 10 bridges (including root bridges, PCIe upstream and
downstream ports, etc -- see
<https://bugzilla.redhat.com/show_bug.cgi?id=1333238#c12> for more
details).
10 is not a whole lot, but closer to the architectural limit of 15 than
our current 4, so it can be considered a stop-gap solution until all
guests manage to migrate to virtio-1.0, and no longer need PCI IO BARs
behind PCIe downstream ports.
Cc: Gabriel Somlo <somlo@cmu.edu>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1333238
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Tested-by: Gabriel Somlo <somlo@cmu.edu>
Make PcdPciIoBase and PcdPciIoSize dynamic PCDs, and set them in
MemMapInitialization(), where we produce our EFI_RESOURCE_IO descriptor
HOB. (The PCD is consumed by the core PciHostBridgeDxe driver, through our
PciHostBridgeLib instance.)
Take special care to keep the GCD IO space map unchanged on all platforms
OVMF runs on.
Cc: Gabriel Somlo <somlo@cmu.edu>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1333238
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Tested-by: Gabriel Somlo <somlo@cmu.edu>
In this patch, the AcpiTimerLib instances, ResetSystemLib, and PlatformPei
are modified together in order to keep VMs functional across a bisection:
they all must agree on the PMBA value used.
ResetSystemLib must not use dynamic PCDs. With SOURCE_DEBUG_ENABLE, it
gets linked into the debug agent, therefore the same restrictions apply to
it as to BaseRomAcpiTimerLib. Luckily, AcpiPmControl() is only used for
powering off the virtual machine, thus the extra cost of a PCI config
space read, compared to a PcdGet16(), should be negligible.
This is the patch that moves the PMBA to IO port 0x0600 on Q35 in
practice.
The ResetSystemLib change is easiest to verify with the "reset -s" command
in the UEFI shell (which goes through gRT->ResetSystem() and, in OVMF,
PcAtChipsetPkg/KbcResetDxe).
Cc: Gabriel Somlo <somlo@cmu.edu>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1333238
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Tested-by: Gabriel Somlo <somlo@cmu.edu>
According to the ICH9 spec, PMBASE "provides 128 bytes of I/O space for
ACPI, GPIO, and TCO logic. This is placed on a 128-byte boundary".
On the Q35 machine type of QEMU, our current PMBASE setting of 0xB000 is
the only thing that prevents us from lowering the base of the PCI IO port
aperture from 0xC000. (The base must be aligned to 0x1000 due to PCI
bridge requirements.)
By moving our PMBASE to 0x0600 (moving the register block to
0x0600..0x067F inclusive), which is also what SeaBIOS uses on Q35, we will
be able to lower the PCI IO port aperture base to 0x6000 (the next IO port
under it being taken by the "vmport" device, at fixed 0x5658), while
steering clear of other QEMU devices.
On PIIX4, freeing up the 0x1000 IO ports at 0xB000 wouldn't help much,
because the 0xA000 block right below it is occupied by unmovable devices
(see <https://bugzilla.redhat.com/show_bug.cgi?id=1333238#c19> for
details).
Doing this for Q35 only has two more benefits:
- It won't interfere with Xen guests,
- The Q35 machine type with the smallest version number is "pc-q35-2.4",
which is guaranteed to have an ACPI generator. This matters because the
ACPI tables (FACP, DSDT) have to reflect the PM base address that we
program.
Cc: Gabriel Somlo <somlo@cmu.edu>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1333238
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Tested-by: Gabriel Somlo <somlo@cmu.edu>
We already have the identical purpose (but different value) macro for
ICH9, namely ICH9_PMBASE_MASK in
"OvmfPkg/Include/IndustryStandard/Q35MchIch9.h".
Also, stop bit-negating signed integer constants.
Cc: Gabriel Somlo <somlo@cmu.edu>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1333238
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Tested-by: Gabriel Somlo <somlo@cmu.edu>
In the next patches, we'll differentiate the PMBA IO port address that we
program on PIIX4 vs. Q35.
Normally we'd just turn PcdAcpiPmBaseAddress into a dynamic PCD. However,
because we need this value in BaseRomAcpiTimerLib too (which cannot access
RAM and dynamic PCDs), it must remain a build time constant. We will
introduce its Q35 counterpart later.
As first step, replace the PCD with a new macro in "OvmfPlatforms.h";
Jordan prefers the latter to fixed PCDs in this instance.
Cc: Gabriel Somlo <somlo@cmu.edu>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1333238
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Tested-by: Gabriel Somlo <somlo@cmu.edu>
We should store the right value to the PMBA (if the PMBA needs
initialization) before setting mAcpiTimerIoAddr from the PMBA.
Cc: Gabriel Somlo <somlo@cmu.edu>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Fixes: f122712b42
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Tested-by: Gabriel Somlo <somlo@cmu.edu>
We currently register the shell before creating the boot options for
the block devices and the network devices, so the boot manager boots
into the internal shell if the user doesn't specify the boot order.
However, Xen doesn't support fw_cfg, so there is no way to change the
boot order with the external command, and the firmware will always
boot into the internal shell if the user doesn't interfere the boot
process.
This patch postpones the shell registration after MdeModulePkg/BDS
creates all the boot options for the block and network devices, so
that firmware will try to boot the block/network devices first.
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
On the Q35 machine type of QEMU, there is no port multiplier connected to
the on-board SATA controller. Therefore the AtaAtapiPassThru driver update
for Mantis ticket 1353 <https://mantis.uefi.org/mantis/view.php?id=1353>
changes the middle number (the Port Multiplier Port Number) in the Sata()
device path nodes from 0x0 to 0xFFFF.
Adapt the translation from OpenFirmware in QemuBootOrderLib.
(Note: QemuBootOrderLib is deprecated at this point (see USE_OLD_BDS in
the DSC files), but until we remove it, it should be kept in sync with
QemuNewBootOrderLib.)
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Feng Tian <feng.tian@intel.com>
Cc: Hao Wu <hao.a.wu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
On the Q35 machine type of QEMU, there is no port multiplier connected to
the on-board SATA controller. Therefore the AtaAtapiPassThru driver update
for Mantis ticket 1353 <https://mantis.uefi.org/mantis/view.php?id=1353>
changes the middle number (the Port Multiplier Port Number) in the Sata()
device path nodes from 0x0 to 0xFFFF.
Adapt the translation from OpenFirmware in QemuNewBootOrderLib.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Feng Tian <feng.tian@intel.com>
Cc: Hao Wu <hao.a.wu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
The patch re-factors the code without functionality impact.
Next patch will add code to support OVMF above Xen.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
In order to match the previous commit, Base must be strictly larger than
Limit if some type of aperture is not available on a PCI root bridge.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
The RamDiskDxe driver in MdeModulePkg now will use EFI_ACPI_TABLE_PROTOCOL
and EFI_ACPI_SDT_PROTOCOL during reporting RAM disks to NVDIMM Firmware
Interface Table (NFIT).
A Pcd 'PcdInstallAcpiSdtProtocol' controls whether the
EFI_ACPI_SDT_PROTOCOL will be produced. Its default value is set to FALSE
in MdeModulePkg. To make the NFIT reporting feature working properly under
OVMF, the patch will set the Pcd to TRUE in OVMF DSC files.
Also, the RamDiskDxe driver will sometimes report a NVDIMM Root Device
using ASL code which is put in a Secondary System Description Table (SSDT)
according to the ACPI 6.1 spec.
Locating the SSDT requires modifying the [Rule.Common.DXE_DRIVER] field in
OVMF FDF files.
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Samer El-Haj-Mahmoud <elhaj@hpe.com>
PcdShellFile is never used in the PEI phase.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
By default the new MdeModulePkg/BDS is used.
If USE_OLD_BDS is defined to TRUE, IntelFrameworkModulePkg/BDS
is used.
Fixes: https://github.com/tianocore/edk2/issues/62
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
The Width and Height assignment suppresses an invalid gcc-4.8 warning
on Ia32.
These warnings look unjustified to me. Namely, near the beginning of
the function, there is a while(1) loop. In that loop,
ConvertBmpToGopBlt() is called unconditionally. If the call fails,
the rest of the loop body is not reached (where the Height and Width
variables are used -- the compiler warns about their use in the
switch statement). If the call succeeds, then the variables are set.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
EnableQuietBoot and DisableQuietBoot are copied from
IntelFrameworkModulePkg/Library/GenericBdsLib/BdsConsole.c.
Because these two functions are not in UefiBootManagerLib.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
The patch uses EfiBootManagerRefreshAllBootOption() to collect
all boot options and uses SetBootOrderFromQemu exposed by
QemuNewBootOrderLib to adjust the boot option order.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
The patch changes PlatformBdsConnectSequence() to use library API
exposed from UefiBootManagerLib and removes the additional
connect ALL action.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
MdeModulePkg/BDS doesn't launch UI (Boot Manager Menu) from platform
side.
The change removes the code which launches the UI but still set the
boot timeout.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
The major difference between IntelFrameworkModulePkg/BDS and
MdeModulePkg/BDS is the latter connects the consoles in core
code while the former connects in platform code.
The change initializes the console variables in
PlatformBootManagerBeforeConsole() and removes the console
connection code.
It also removes unused functions: PlatformBdsNoConsoleAction()
and LockKeyboards().
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
The DevicePathToStr() function (in
"IntelFrameworkModulePkg/Library/GenericBdsLib/DevicePath.c") is a
simple wrapper around ConvertDevicePathToText().
DevicePathToStr() passes DisplayOnly=TRUE and AllowShortcuts=TRUE to
ConvertDevicePathToText(), whereas in this patch, both parameters are
flipped to FALSE.
The formatted devpaths are used only for debugging purposes, so this
change is safe.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Change the function name to follow new library class
PlatformBootManagerLib interfaces.
NOTE: There is no progress bar during BDS timeout waiting.
In order to show the progress bar, PlatformBootManagerWaitCallback ()
needs to change to draw it.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
It will be changed to build with MdeModulePkg/BDS.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
NOTE: SetBootOrderFromQemu() interface is not changed.
But when the old IntelFrameworkModulePkg/BDS is no longer used in
OVMF and ArmVirtPkg, additional patch will be submitted to change
this interface to remove parameter BootOptionList.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
QemuNewBootOrderLib will be changed to work with MdeModulePkg/BDS.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Since PlatformBootManagerLib do not run memory test
to convert untested memory to tested.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
At the moment, the EFI_DXE_SMM_READY_TO_LOCK_PROTOCOL is only installed if
S3 is enabled -- at the end of SaveS3BootScript().
While a runtime OS is never booted with SMM unlocked (because the SMM IPL
locks down SMM as a last resort:
> SMM IPL! DXE SMM Ready To Lock Protocol not installed before Ready To
> Boot signal
> SmmInstallProtocolInterface: [EfiSmmReadyToLockProtocol] 0
> Patch page table start ...
> Patch page table done!
> SMM IPL locked SMRAM window
), we shouldn't allow UEFI drivers and applications either to mess with
SMM just because S3 is disabled. So install
EFI_DXE_SMM_READY_TO_LOCK_PROTOCOL in PlatformBdsInit() unconditionally.
Cc: Feng Tian <feng.tian@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
OVMF's PlatformBdsLib currently makes SMM vulnerable to the following
attack:
(1) a malicious guest OS copies a UEFI driver module to the EFI system
partition,
(2) the OS adds the driver as a Driver#### option, and references it from
DriverOrder,
(3) at next boot, the BdsEntry() function in
"IntelFrameworkModulePkg/Universal/BdsDxe/BdsEntry.c" processes
Driver#### and DriverOrder between the calls to PlatformBdsInit() and
PlatformBdsPolicyBehavior(),
(4) OVMF locks down SMM only in PlatformBdsPolicyBehavior(), hence the
driver runs with SMM unlocked.
The BdsEntry() function of the MdeModulePkg BDS driver (in file
"MdeModulePkg/Universal/BdsDxe/BdsEntry.c") recommends to "Signal
ReadyToLock event" in PlatformBootManagerBeforeConsole() -- which
corresponds to PlatformBdsInit() --, not in
PlatformBootManagerAfterConsole() -- which corresponds to
PlatformBdsPolicyBehavior().
Albeit an independent question, but it's worth mentioning: this patch also
brings OvmfPkg's PlatformBdsInit() closer to ArmVirtPkg's. Namely, the
latter signals End-of-Dxe in PlatformBdsInit() already.
Cc: Feng Tian <feng.tian@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
It would be possible to remove the UAF without local variables, by calling
SataPrivateData->PciIo->Attributes() before releasing SataPrivateData.
However, by keeping the location of the call (for which temporary
variables are necessary), we continue to match the error path logic in
SataControllerStart(), which is always recommended.
Reported-by: wang xiaofeng <winggundum82@163.com>
Fixes: bcab714134
Cc: wang xiaofeng <winggundum82@163.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
"ASSERT (SataPrivateData != NULL)" is just a few lines higher up.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
XenIoMmioLib depends on MemoryAllocationLib, and uses its header, but
failed to declare the dependency in its INF.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
This driver is now unused.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
It's been a month since the following commits appeared in the repo:
4014885ffd OvmfPkg: switch to MdeModulePkg/Bus/Pci/PciHostBridgeDxe
c47ed6fcb5 OvmfPkg: match PCI config access to machine type (if not
USE_OLD_PCI_HOST)
in which we introduced the USE_OLD_PCI_HOST fallback, and made other work
depend on it. I have not heard of any problems (primarily from the
vfio-users group that uses Gerd's daily / hourly OVMF builds), so it's
time to drop the fallback.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Now that FatPkg is open source (and therefore can be included in the
EDK II tree) we build and use it directly.
Build tested with GCC 5.3 on IA32 and X64. Boot tested to UEFI Shell
on IA32 and UEFI Linux on X64.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
The same functional code has been in S3SaveStateDxe,
OVMF AcpiS3SaveDxe can be retired now.
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
Currently, the LockBox protocol is installed in entrypoint of
OVMF AcpiS3SaveDxe.
We can let the first driver run with LockBoxDxeLib linked to have its
library constructor to install LockBox protocol on the ImageHandle.
As other drivers may have gEfiLockBoxProtocolGuid dependency,
the first driver should run before them.
The later patches to retire AcpiS3SaveDxe for OVMF depends on this patch.
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Also need to declare PcdAcpiS3Enable as DynamicDefault in *.dsc.
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Edk2 commit 8a45f80eda ("MdeModulePkg: Make HII configuration settings
available to OS runtime") implements the optional UEFI feature described
in "31.2.11.1 OS Runtime Utilization" in UEFI v2.6.
While this feature might show benefits down the road even in QEMU virtual
machines, at the moment it only presents drawbacks:
- it increases the EfiRuntimeServicesData footprint,
- it triggers HII compatibility problems between edk2 and external drivers
unconditionally, even if the end-user is not interested in HII and/or in
configuring said drivers (see
<https://www.redhat.com/archives/vfio-users/2016-March/msg00153.html>
and <http://thread.gmane.org/gmane.comp.bios.edk2.devel/9894> for an
example).
While the feature was being introduced, popular demand for a controlling
Feature PCD rose (see
<http://thread.gmane.org/gmane.comp.bios.edk2.devel/7626>), which is why
we can set it now to FALSE.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
PcdMaxHardwareErrorVariableSize sets the size limit for individual
Hardware Error Record Variables (see "7.2.3 Hardware Error Record
Persistence" and "Appendix P, Hardware Error Record Persistence Usage" in
the UEFI-2.6 spec).
Since Hardware Error Record Persistence is an optional firmware feature,
according to the spec, and OVMF does not enable it -- it inherits
PcdHwErrStorageSize and PcdHardwareErrorRecordLevel with zero values --,
the PcdMaxHardwareErrorVariableSize setting in our DSC files has no
effect. Remove it in order to eliminate future confusion.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Suggested-by: Star Zeng <star.zeng@intel.com>
Ref: http://thread.gmane.org/gmane.comp.bios.edk2.devel/9743/focus=9780
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
This driver implements the VIRTIO_DEVICE_PROTOCOL for non-transitional PCI
devices, based on the virtio-1.0 specification (csprd05). Non-transitional
means that it only binds QEMU's virtio-xxx-pci devices that receive the
",disable-legacy=on,disable-modern=off" properties on the QEMU command
line. These devices have distinct PCI Device IDs from those that are bound
by VirtioPciDeviceDxe.
The central abstraction of this driver is the VIRTIO_1_0_CONFIG type. It
is practically a "fat pointer" to a register block. The pointed-to
register block
- may or may not exist (the latter being mostly useful for virtio-1.0
devices that have no device-specific registers),
- lives in one of the device's BARs,
- lives in an IO or MMIO BAR,
- lives at an offset relative to the BAR start,
- has its size also maintained.
Such VIRTIO_1_0_CONFIG "fat pointers" (i.e., the locations of the register
blocks) are parsed from vendor capabilities that reside in the device's
standard PCI capabilities list (in PCI config space).
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Jordan Justen <jordan.l.justen@intel.com>
In virtio-0.9.5, the size of the virtio-net packet header depends on
whether the VIRTIO_NET_F_MRG_RXBUF feature is negotiated -- the
"num_buffers" field is only appended to the header if the feature is
negotiated.
Since we never negotiate this feature, VirtioNetDxe never allocates room
for the "num_buffers" field.
With virtio-1.0, the "num_buffers" field is always there (although it
doesn't carry useful information without VIRTIO_NET_F_MRG_RXBUF). Adapt
the buffers that depend on the virtio-net header size (otherwise we have
skewed / truncated packets).
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Relative to virtio-0.9.5, virtio-1.0 reverses the order of queue discovery
and feature negotiation. In virtio-1.0, feature negotiation has to
complete first, and the device can also reject a self-inconsistent feature
request through the new VSTAT_FEATURES_OK status bit. (For example if the
driver requests a higher level feature but clears a prerequisite feature.)
Furthermore, we retain the VIRTIO_F_VERSION_1 feature bit if the
VIRTIO_DEVICE_PROTOCOL provider has high enough revision.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Relative to virtio-0.9.5, virtio-1.0 reverses the order of queue discovery
and feature negotiation. In virtio-1.0, feature negotiation has to
complete first, and the device can also reject a self-inconsistent feature
request through the new VSTAT_FEATURES_OK status bit. (For example if the
driver requests a higher level feature but clears a prerequisite feature.)
Furthermore, we retain the VIRTIO_F_VERSION_1 feature bit if the
VIRTIO_DEVICE_PROTOCOL provider has high enough revision.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Relative to virtio-0.9.5, virtio-1.0 reverses the order of queue discovery
and feature negotiation. In virtio-1.0, feature negotiation has to
complete first, and the device can also reject a self-inconsistent feature
request through the new VSTAT_FEATURES_OK status bit. (For example if the
driver requests a higher level feature but clears a prerequisite feature.)
Furthermore, we retain the VIRTIO_F_VERSION_1 feature bit if the
VIRTIO_DEVICE_PROTOCOL provider has high enough revision.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Relative to virtio-0.9.5, virtio-1.0 reverses the order of queue discovery
and feature negotiation. In virtio-1.0, feature negotiation has to
complete first, and the device can also reject a self-inconsistent feature
request through the new VSTAT_FEATURES_OK status bit. (For example if the
driver requests a higher level feature but clears a prerequisite feature.)
Furthermore, we retain the VIRTIO_F_VERSION_1 feature bit if the
VIRTIO_DEVICE_PROTOCOL provider has high enough revision.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
In VirtIo 1.0, a device can reject a self-inconsistent feature bitmap
through the new VSTAT_FEATURES_OK status bit. (For example if the driver
requests a higher level feature but clears a prerequisite feature.) This
function is a small wrapper around
VIRTIO_DEVICE_PROTOCOL.SetGuestFeatures() that also verifies if the VirtIo
1.0 device accepts the feature bitmap.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
These header files are intentionally minimal, and intentionally kept apart
from the VirtIo 0.9.5 headers.
The header inclusion chains end up like this (the Virtio10*.h header files
in the middle are new):
Virtio.h -> Virtio10.h -> Virtio095.h
^ ^
| |
VirtioNet.h -> Virtio10Net.h -> Virtio095Net.h
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Jordan Justen <jordan.l.justen@intel.com>
In the upcoming virtio-1.0 series, we'll introduce "Virtio10Net.h".
However, the "VirtioNet.h" header file should continue to expose the
Virtio Network Device specific type and macro definitions for all virtio
versions that OvmfPkg supports. Therefore extract "Virtio095Net.h" like
this:
VirtioNet.h -> Virtio095Net.h
so that in the upcoming patches, we can insert "Virtio10Net.h" in the
middle of the inclusion chain.
This follows the example of "Acpi.h" and "Pci.h" under
"MdePkg/Include/IndustryStandard".
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Suggested-by: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
In the upcoming virtio-1.0 series, we'll introduce "Virtio10.h". However,
the "Virtio.h" header file should continue to expose the generic type and
macro definitions for all virtio versions that OvmfPkg supports. Therefore
extract "Virtio095.h" like this:
Virtio.h -> Virtio095.h
so that in the upcoming patches, we can insert "Virtio10.h" in the middle
of the inclusion chain.
This follows the example of "Acpi.h" and "Pci.h" under
"MdePkg/Include/IndustryStandard".
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Suggested-by: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
This too is in preparation for the following patches.
After this patch, all four drivers manage their feature bits with explicit
masking.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
VirtioBlkDxe only recognizes virtio-block feature bits that the device
offers non-negotiably. Nonetheless, in preparation for the following
patches, don't try to clear them even for simplicity.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
In virtio-1.0, it is not enough to pass the base address of the virtio
queue to the hypervisor (as a frame number); instead it will want the
addresses of the descriptor table, the available ring, and the used ring
separately. Pass the VRING object to the SetQueueAddress() member
function; this will enable a virtio-1.0 implementation. Convert the
current producers and consumers to this prototype.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
This function was never consumed by drivers, and the current prototype is
unsupportable with virtio-1.0. Remove the function from the protocol
definition, and drop the current (unused) implementations.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
The virtio-1.0 spec widens the Features bitmap to 64 bits. Modify the
declarations of the GetDeviceFeatures() and SetGuestFeatures() protocol
member functions accordingly.
Normally, a protocol cannot be changed in incompatible ways if the GUID
stays the same; however, we've always been extremely clear that
VIRTIO_DEVICE_PROTOCOL is internal to edk2. See for example the top of
"OvmfPkg/Include/Protocol/VirtioDevice.h".
In this patch, all producers and consumers of the GetDeviceFeatures() and
SetGuestFeatures() protocol members are updated.
The drivers that currently produce these members are "legacy" drivers (in
virtio-1.0 terminology), and they cannot (and will not) handle feature
bits above BIT31. Therefore their conversion is only for compatibility
with the modified protocol interface. The consumers will be responsible
for checking the VIRTIO_DEVICE_PROTOCOL.Revision field, and for not
passing feature bits that these backends cannot handle.
The VirtioMmioGetDeviceFeatures() implementation stores the result of an
MmioRead32() call with normal assignment, so it needs no change beyond
adapting its prototype.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Currently booting off of a RAM disk is not supported by
IntelFrameWorkModulePkg BDS, however on systems without writable
disks, the RAM disk can be made useful when loading raw HDD images
into it -- specially the ones with a FAT32 partition on which files
can be natively accessed by system firmware.
This patch adds RamDiskDxe driver by default in OVMF platform.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Paulo Alcantara <paulo.alc.cavalcanti@hp.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
During real world testing I was getting an error with too many entries
in db: On my Secure boot laptop, I currently have seven certificates:
two Microsoft ones, Three Kernel ones from various distributions, my
own Secure Key and a temporary test key. That gives a total EFI
Signature List size of 8317 which is over the 0x2000 maximum.
Fix this by setting the PcdMaxAuthVariableSize to 0x2800 (10K) which
isn't much of an increase but allows for 9-10 certificates.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Laszlo Ersek
Anthony PERARD
Ruiyu Ni
Dandan Bi
Jiaxin Wu
Thomas Huth
Gary Lin
Leo Duran
Michael Kinney
Bhupesh Sharma
Leif Lindholm
Konrad Rzeszutek Wilk
Jiewen Yao
Liming Gao
Marvin Häuser
Bruce Cran
Jeff Fan
Cinnamon Shia
Thomas Palmer
Ard Biesheuvel
Giri P Mudusuru
Bruce Cran
Zenith432
Hao Wu
Volker Rümelin
Jordan Justen
Star Zeng
Alcantara, Paulo
James Bottomley