The FACS may still exist when the reduced hardware flag is set in FADT;
it is optional. Since it contains the hardware signature field which
indicates that a hibernated system should boot cleanly instead of
attempting to resume, a platform may choose to expose it. Propagate it
correctly.
Also avoid a NULL pointer dereference if the platform doesn't provide
a DSDT.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Message-Id: <881dd0a2558ecbdfa02c844722d8a1103ab97ab3.camel@infradead.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
[lersek@redhat.com: uncrustify]
Moved the PlatformBootManagerLib to OvmfPkg and renamed to
PlatformBootManagerLibLight for easy use by other ARCH.
Build-tested only (with "ArmVirtQemu.dsc and OvmfPkgX64.dsc").
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4663
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Lazlo Ersek <lersek@redhat.com>
Signed-off-by: Chao Li <lichao@loongson.cn>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Move the PcdTerminalTypeGuidBuffer and PcdUninstallMemAttrProtocol into
OvmfPkg so other ARCH can easily use it.
Build-tested only (with "ArmVirtQemu.dsc and OvmfPkgX64.dsc").
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4584
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Chao Li <lichao@loongson.cn>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Move the FdtSerialPortAddressLib to Ovmfpkg so that other ARCH can
easily use it.
Build-tested only (with "ArmVirtQemu.dsc and OvmfPkgX64.dsc").
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4584
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Chao Li <lichao@loongson.cn>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Moved PcdDeviceTreeInitialBaseAddress and PcdDeviceTreeAllocationPadding
to OvmfPkg for easier use by other architectures.
Build-tested only (with "ArmVirtQemu.dsc").
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4584
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Signed-off-by: Chao Li <lichao@loongson.cn>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Add the long lost CI for CloudHv on AArch64.
As CloudHv CI works nearly the same way with other VMMs like KvmTool,
thus we can easily create its CI configuration based on KvmTool.
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Jianyong Wu <jianyong.wu@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Shim's PE loader uses the EFI memory attributes protocol in a way that
results in an immediate crash when invoking the loaded image, unless the
base and size of its executable segment are both aligned to 4k.
If this is not the case, it will strip the memory allocation of its
executable permissions, but fail to add them back for the executable
region, resulting in non-executable code. Unfortunately, the PE loader
does not even bother invoking the protocol in this case (as it notices
the misalignment), making it very hard for system firmware to work
around this by attempting to infer the intent of the caller.
So let's introduce a QEMU command line option to indicate that the
protocol should not be exposed at all, and a PCD to set the default for
this option when it is omitted.
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Link: https://gitlab.com/qemu-project/qemu/-/issues/1990
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Update the debug level comments in ArmVirt.dsc.inc to sync with
MdePkg/Include/Library/DebugLib.h.
Signed-off-by: Rebecca Cran <rebecca@os.amperecomputing.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Add an instance of ImagePropertiesRecordLib which will be used by the
DXE Core.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Taylor Beebe <taylor.d.beebe@gmail.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Since the code is most regularly tested in CI, distro/versioning
details are updated to match the latest CI configuration.
CI has moved from Ubuntu 18.04 to Ubuntu 22.04 since the time of the
file's creation, but the code is actually built in a Fedora container
so Fedora is mentioned as the primary build/test environment.
Updates the following information:
- Build OS: Fedora 37 Linux
- Supported Configuration: Additional DSCs added
- Python: 3.12.x
- Packaging Tool: dnf instead of apt
- Container Details: Added
- Primary Build Example: QemuBuild.py instead of PlatformBuild.py
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Julien Grall <julien@xen.org>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Message-Id: <20231030230902.849-1-mikuback@linux.microsoft.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
[lersek@redhat.com: don't specify the number of supported firmware builds]
Adds the varpolicy EFI shell command to all DSC files that
currently include other dynamic shell commands from ShellPkg.
This command allows variable policies to be dumped in the EFI
shell for convenient auditing and debug.
Use the command in the EFI shell as follows:
- `"varpolicy"` dumps platform variables
- `"varpolicy -?"` shows help text
- `"varpolicy -b"` pages output as expected
- `"varpolicy -s"` shows accurate variable statistic information
- `"varpolicy -p"` shows accurate UEFI variable policy information
- `"varpolicy-v -b"` dumps all information including variable data hex dump
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Julien Grall <julien@xen.org>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Message-Id: <20231030203112.736-5-mikuback@linux.microsoft.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
For the RELEASE target, all ArmVirtPkg DSCs inherit BaseDebugLibNull from
"ArmVirt.dsc.inc"; keep that.
For NOOPT and DEBUG:
- switch the lib class resolution pair (BaseDebugLibSerialPort +
FdtPL011SerialPortLib) that is set as the default for all module types
in "ArmVirt.dsc.inc" to DebugLibFdtPL011UartRam;
- switch the lib class resolution pair (BaseDebugLibSerialPort +
EarlyFdtPL011SerialPortLib) that is set as an override for SEC,
PEI_CORE, PEIM modules in "ArmVirt.dsc.inc" to
DebugLibFdtPL011UartFlash;
- switch the lib class resolution pair (DxeRuntimeDebugLibSerialPort +
FdtPL011SerialPortLib) that is set as an override for DXE_RUNTIME_DRIVER
modules in "ArmVirt.dsc.inc" to DxeRuntimeDebugLibFdtPL011Uart;
- mask all of the above DebugLib class resolution changes in
"ArmVirtKvmTool.dsc", because "ArmVirtKvmTool.dsc" uses
BaseSerialPortLib16550 rather than PL011 UARTs,
- mask all of the above DebugLib class resolution changes in
"ArmVirtXen.dsc" too, because "ArmVirtXen.dsc" uses
XenConsoleSerialPortLib rather than PL011 UARTs.
I regression-tested this change for "ArmVirtKvmTool.dsc" and
"ArmVirtXen.dsc" by building them for both DEBUG and RELEASE, both before
the patch and after, and comparing the edk2 build report files (focusing
on lib class resolutions). There are no changes.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Julien Grall <julien@xen.org>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20231008153912.175941-10-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4577
[lersek@redhat.com: add TianoCore BZ reference]
Introduce three new DebugLib instances, forked from
MdePkg/Library/BaseDebugLibSerialPort. All three instances rely on
PL011UartLib rather than SerialPortLib so that they can customize the
PL011 UART that the debug messages are written to. All three instances
direct the debug output to the first such PL011 UART that *differs* from
the one specified in the Device Tree's /chosen node's "stdout-path"
property.
From these, DxeRuntimeDebugLibFdtPL011Uart is identical to
DebugLibFdtPL011UartRam, with the addition that UART access is permanently
disabled when the containing DXE_RUNTIME_DRIVER module is notified about
exiting boot services.
The contexts in which these DebugLib instances run are identical to those
in which the corresponding SerialPortLib instances run. The particular
original dependency chain is
DxeRuntimeDebugLibSerialPort (DXE_RUNTIME_DRIVER)
FdtPL011SerialPortLib
gEarlyPL011BaseAddressGuid
HobLib
PL011UartLib
and the new dependency chain is
DxeRuntimeDebugLibFdtPL011Uart (DXE_RUNTIME_DRIVER)
gEarlyPL011BaseAddressGuid
HobLib
PL011UartLib
The ArmVirtPkg DSC files will be switched to the new library instances in
a separate patch.
This patch is worth viewing with "git show --find-copies-harder".
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20231008153912.175941-9-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4577
[lersek@redhat.com: add TianoCore BZ reference]
Introduce three new DebugLib instances, forked from
MdePkg/Library/BaseDebugLibSerialPort. All three instances rely on
PL011UartLib rather than SerialPortLib so that they can customize the
PL011 UART that the debug messages are written to. All three instances
direct the debug output to the first such PL011 UART that *differs* from
the one specified in the Device Tree's /chosen node's "stdout-path"
property.
From these, DebugLibFdtPL011UartRam mirrors FdtPL011SerialPortLib: it
relies on the EarlyPL011BaseAddress GUID HOB, and initializes the UART --
a UART different from FdtPL011SerialPortLib's -- only once in the lifetime
of the containing module. Suitable for module types that can only execute
from RAM (i.e., all types different from SEC, PEI_CORE, PEIM), except
DXE_RUNTIME_DRIVER.
(Note that OVMF uses a similar set of dedicated DebugLib instances
(PlatformDebugLibIoPort) for logging to the (x86-only) isa-debugcon device
from various firmware phases.)
The contexts in which these DebugLib instances run are identical to those
in which the corresponding SerialPortLib instances run. The particular
original dependency chain is
BaseDebugLibSerialPort (not SEC, PEI_CORE, PEIM, DXE_RUNTIME_DRIVER)
FdtPL011SerialPortLib
gEarlyPL011BaseAddressGuid
HobLib
PL011UartLib
and the new dependency chain is
DebugLibFdtPL011UartRam (not SEC, PEI_CORE, PEIM, DXE_RUNTIME_DRIVER)
gEarlyPL011BaseAddressGuid
HobLib
PL011UartLib
Note that FdtPL011SerialPortLib remains in use (just not via
BaseDebugLibSerialPort); for instance by MdeModulePkg/Universal/SerialDxe,
which produces the SerialIo protocol, underlying the UEFI console.
The ArmVirtPkg DSC files will be switched to the new library instances in
a separate patch.
This patch is worth viewing with "git show --find-copies-harder".
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20231008153912.175941-8-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4577
[lersek@redhat.com: add TianoCore BZ reference]
Introduce three new DebugLib instances, forked from
MdePkg/Library/BaseDebugLibSerialPort. All three instances rely on
PL011UartLib rather than SerialPortLib so that they can customize the
PL011 UART that the debug messages are written to. All three instances
direct the debug output to the first such PL011 UART that *differs* from
the one specified in the Device Tree's /chosen node's "stdout-path"
property.
From these, DebugLibFdtPL011UartFlash mirrors EarlyFdtPL011SerialPortLib:
it parses the initial Device Tree, and initializes the UART -- a UART
different from EarlyFdtPL011SerialPortLib's -- for every message written.
Suitable for SEC, PEI_CORE, PEIM.
(Note that OVMF uses a similar set of dedicated DebugLib instances
(PlatformDebugLibIoPort) for logging to the (x86-only) isa-debugcon device
from various firmware phases.)
The contexts in which these DebugLib instances run are identical to those
in which the corresponding SerialPortLib instances run. The particular
original dependency chain is
BaseDebugLibSerialPort (SEC, PEI_CORE, PEIM)
EarlyFdtPL011SerialPortLib
PcdDeviceTreeInitialBaseAddress
FdtSerialPortAddressLib
PL011UartLib
and the new dependency chain is
DebugLibFdtPL011UartFlash (SEC, PEI_CORE, PEIM)
PcdDeviceTreeInitialBaseAddress
FdtSerialPortAddressLib
PL011UartLib
Note that EarlyFdtPL011SerialPortLib remains in use (just not via
BaseDebugLibSerialPort), namely for direct SerialPortLib calls from SEC,
PEI_CORE, PEIM. See for example commit 56035d1c8b
("ArmPlatformPkg/PrePeiCore: Print the firmware version early in boot",
2022-10-25).
The ArmVirtPkg DSC files will be switched to the new library instances in
a separate patch.
This patch is worth viewing with "git show --find-copies-harder".
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20231008153912.175941-7-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4577
[lersek@redhat.com: add TianoCore BZ reference]
PlatformPeiLib produces the EarlyPL011BaseAddress GUID HOB, and
FdtPL011SerialPortLib consumes it. Extend the HOB such that it also carry
the base address of the PL011 UART meant for DebugLib usage -- namely the
first UART that is *not* designated by the /chosen node's "stdout-path"
property. Implement this policy in PlatformPeiLib.
Note that as far as the SerialPortLib+console UART is concerned, this
patch makes no difference. That selection remains consistent with the
pre-patch state, and therefore consistent with EarlyFdtPL011SerialPortLib.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20231008153912.175941-6-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4577
[lersek@redhat.com: add TianoCore BZ reference]
Convert both EarlyFdtPL011SerialPortLib and PlatformPeiLib at the same
time to clients of FdtSerialPortAddressLib (so that both "early" and
"late" serial output continue going to a common serial port). If the
device tree specifies just one serial port, this conversion makes no
difference, but if there are multiple ports, the output is written to the
port identified by /chosen "stdout-path".
In this patch, DebugLib output is not separated yet from the UEFI console.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20231008153912.175941-5-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4577
[lersek@redhat.com: add TianoCore BZ reference]
I strongly dislike when *small* local variable declaration changes are
muddled by whitespace changes. When that happens, a reviewer can choose
from two suboptimal options: display the patch with "git show -b", which
creates confusion in *other* parts of the patch, or display the patch with
just "git show", which then produces an unjustifiedly large hunk for the
sequence of declarations.
For avoiding that in subsequent patches, adjust some whitespace in this
patch in isolation. Functionally this is a no-op; "git show -b" produces
empty output.
Note that uncrustify is (of course) unhappy with this patch, but that's
fine -- this patch is in the middle of a series, and by the end of the
series (which is where uncrustify is run in CI) the whitespace is going to
be tight.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20231008153912.175941-4-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4577
[lersek@redhat.com: add TianoCore BZ reference]
This is only a refactoring; the patch is not supposed to cause any
observable change.
Build-tested only (with "ArmVirtKvmTool.dsc").
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20231008153912.175941-3-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4577
[lersek@redhat.com: add TianoCore BZ reference]
Introduce a new library class + instance for:
- collecting serial port base addresses from the device tree,
- collecting the /chosen stdout-path serial port base address from the
device tree.
The logic is loosely based on the following functions:
- SerialPortGetBaseAddress()
[ArmVirtPkg/Library/FdtPL011SerialPortLib/EarlyFdtPL011SerialPortLib.c]
- PlatformPeim() [ArmVirtPkg/Library/PlatformPeiLib/PlatformPeiLib.c]
- GetSerialConsolePortAddress()
[ArmVirtPkg/Library/Fdt16550SerialPortHookLib/EarlyFdt16550SerialPortHookLib.c]
which are going to be converted to clients of the new library later.
Copyright notices from those other files are preserved.
The new library fixes the following warts, found by reading the existent
code:
- Neither of the three functions check whether the "reg" property exists.
(This may be implicitly checked when they compare the property size to
16.)
- GetSerialConsolePortAddress() uses ScanMem8() for locating a colon (":")
node path separator in "stdout-path", when AsciiStrStr() could work just
as fine. While ScanMem8() is likely faster, "stdout-path" is presumably
very short, and ScanMem8() introduces an extra lib class dependency
(namely BaseMemoryLib).
- If ScanMem8() fails to locate a colon in "stdout-path", then
GetSerialConsolePortAddress() re-measures the length of the whole
"stdout-path" property. This is conceptually (if not performance-wise)
disturbing, because we know the whole size of the "stdout-path" property
from the property lookup just before, so we only need to subtract the
NUL-terminator for learning the length.
- GetSerialConsolePortAddress() does not check if the first (or only) node
path inside the "stdout-path" property is empty. (Not a big deal, the
subsequent alias resolution should simply fail.)
- GetSerialConsolePortAddress() does not verify if the node path retrieved
(and potentially alias-resolved) from "stdout-path" can be located in
the device tree; it assumes it.
- Code is duplicated (of course) between SerialPortGetBaseAddress() and
PlatformPeim(), but more surprisingly, all three functions embed the
same code for verifying the "status" property of the serial port node,
and for checking and reading its "reg" property.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20231008153912.175941-2-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4577
[lersek@redhat.com: add TianoCore BZ reference]
FdtPL011SerialPortLib claims that it's usable from the DXE_CORE. That's
not correct: the DXE_CORE calls DEBUG() and ASSERT() before it calls
ProcessLibraryConstructorList(). Via the BaseDebugLibSerialPort instance,
those DEBUG() and ASSERT() calls result in SerialPortWrite() calls, before
ProcessLibraryConstructorList() called either our constructor
FdtPL011SerialPortLibInitialize(), or BaseDebugLibSerialPortConstructor().
(And even if the DXE_CORE called the latter function early enough, it
would just invoke our SerialPortInitialize() function -- which does
nothing.)
This means that the earliest DXE_CORE debug messages are lost.
Rename FdtPL011SerialPortLibInitialize() to SerialPortInitialize(), so
that the same initialization occur through the constructor and the public
SerialPortInitialize() library API.
Turn SerialPortInitialize() calls after the first one into no-ops.
Our SerialPortLib APIs already use (mSerialBaseAddress != 0) to track
initialization. Rework those checks to actually initialize the library if
that hasn't happened yet.
The following new lines appear in the log:
> CoreInitializeMemoryServices:
> BaseAddress - 0x48000000 Length - 0xF8000000 MinimalMemorySizeNeeded - 0x38C8000
> InstallProtocolInterface: [EfiLoadedImageProtocol] 46EFC3E0
> ProtectUefiImageCommon - 0x46EFC3E0
> - 0x0000000046EB2000 - 0x0000000000068000
(0x46EB2000 is the load address of the DXE Core.)
Reported-by: Oliver Smith-Denny <osde@linux.microsoft.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
FEAT_VHE, introduced in ARMv8.1, adds a virtual EL2 timer.
However, this library verifies that exactly 3 or 4 12-byte timer
interrupts are provided in input DT, ASSERTing when the new timer
is added.
Change the assert to >= 36.
Extend the current logic, also initializing PcdArmArchTimerHypVirtIntrNum
if 5 interrupts are provided.
Signed-off-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reported-by: Peter Maydell <peter.maydell@linaro.org>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Peter Maydell <peter.maydell@linaro.org>
Adds a CI YAML entry to acknowledge a case where a macro is expanded
that contains a print specifier.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4504
The BaseRngLibTimerLib allows to generate number based on a timer.
This mechanism allows to have a basic non-secure implementation
for non-production platforms.
To bind and identify Random Number Generators implementations with
a GUID, an unsafe GUID should be added. This GUID cannot be added
to the MdePkg unless it is also added to a specification.
To keep the MdePkg self-contained, copy the BaseRngLibTimerLib to
the MdeModulePkg. This will allow to define an unsafe Rng GUID
in a later patch in the MdeModulePkg.
The MdePkg implementation will be removed later. This allows to give
some time to platform owners to switch to the MdeModulePkg
implementation.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Kun Qin <kun.qin@microsoft.com>
Currently, unlike OVMF, ArmVirtQemu does not display any graphics, only
the QEMU monitor. Graphics are helpful to confirm booting into an OS is
successful, interacting with the EFI shell while getting separate
logging messages, etc.
This patch adds the QEMU parameters to launch a graphical window and add
a USB keyboard and mouse, which is modeled as a tablet as it tracks
better in QEMU than a generic mouse. virtio-gpu-pci is chosen as the
graphics device as it is recommended by QEMU for the ARM virtual
platform.
The graphics and USB input devices will only be added to QEMU when
QEMU_HEADLESS == FALSE, so CI builds will not attempt to use the
graphics and if a user does not want graphics, they can add
QEMU_HEADLESS=TRUE to the build cmdline.
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Bhyve supports providing ACPI tables by FwCfg. Therefore,
InstallQemuFwCfgTables should be moved to AcpiPlatformLib to reuse the
code. As first step, move PciEncoding into AcpiPlatformLib.
Signed-off-by: Corvin Köhne <corvink@FreeBSD.org>
Acked-by: Peter Grehan <grehan@freebsd.org>
In case a virtio serial device is found in the system register the first
console port as EFI console, by updating ConIn, ConOut and ErrOut.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
IsVirtioPciRng() becomes just a thin wrapper for IsVirtioPci().
This allows to add similar thin wrappers for other virtio
devices in the future.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
IsVirtioRng() becomes just a thin wrapper for IsVirtio().
This allows to add similar thin wrappers for other virtio
devices in the future.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Map the code flash with read-only attributes so we can execute from it
even under a memory protection regime that enables WXN, making all
writable memory regions non-executable by default.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
The VariableRuntimeDxe links with NvVarStoreFormattedLib which is
required to establish the dependency on OvmfPkg\VirtNorFlashDxe.
The VirtNorFlashDxe installs the gEdkiiNvVarStoreFormattedGuid to
indicate it has finished initialising the flash variable storage
and that the variable service can be dispatched.
However, the kvmtool guest firmware dynamically detects if CFI
flash is absent and sets PcdEmuVariableNvModeEnable to TRUE
indicating emulated runtime variable must be used. Therefore,
in this scenario install the gEdkiiNvVarStoreFormattedGuid so
that the variable service can be dispatched.
Also link the NorFlashKvmtoolLib as a NULL library so that
it can discover if the CFI flash is absent and setup the PCD
PcdEmuVariableNvModeEnable. This is required in case the
NorFlashDxe is not yet dispatched.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
The kvmtool option '--flash <flash filename>' is used to launch
a guests VM with a CFI flash device that maps the flash file
specified at the command line.
However, kvmtool allows guest VMs to be launched without a CFI
flash device. In such scenarios the firmware can utilize the
emulated variable storage for UEFI variables. To support this
the PCD gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvModeEnable
must be set to TRUE.
Therefore, update the NorFlashKvmtoolLib to fallback to variable
emulation if a CFI device is not detected. Also improve the error
logging.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Kvmtool allows guest VMs to be launched with or without a
CFI flash device.
When the kvmtool option '--flash <flash filename>' is used to
launch a guest VM a CFI flash device maps the flash file that
was specified at the command line. The NorFlash driver uses
this flash as the variable storage backend.
However, when the above option is not specified, a CFI flash
device is not present. In such cases, the firmware can fallback
to use emulated runtime variables (which uses the VMs DRAM as
the storage backend).
Therefore, define the PCD PcdEmuVariableNvModeEnable required
to enable the emulated runtime variable support, but do not
enable it by default.
The firmware is expected to dynamically discover if the CFI
flash is present and subsequently enable NorFlash or emulate
the runtime variables.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
The patch "f07a9df9af60 ArmVirtPkg: Enable stack guard"
enabled stack overflow detection for ArmVirtPkg. Following
this patch, running UEFI shell command 'dmpstore' resulted
in a crash indicating a stack overflow. Invoking 'dmpstore'
results in recursive calls to CascadeProcessVariables ()
which apparently consumes the available stack space and
overflows.
Normally, SEC and PEI run off the initial stack, and the
DxeIpl PEIM is in charge of launching the DxeCore with a
full-sized stack and remapping it non-executable as well.
PrePi platforms take some shortcuts and the DXE and BDS
run off the initial stack which is relatively small. It
is therefore desirable to allocate 128 KiB worth of boot
services data memory as the stack for the Dxe phase.
The PrePiMain () in ArmVirtPkg/PrePi/PrePi.c invokes the
LoadDxeCoreFromFv () to load the Dxe core and transfers
control. The second parameter to LoadDxeCoreFromFv () is
the stack size, which is currently set to 0.
LoadDxeCoreFromFv () is implemented in PrePiLib and if the
stack size is 0, it continues to use the initial stack.
However, if a stack size is specified in the call to
LoadDxeCoreFromFv (), memory is allocated for a new stack
and the stack is switched to use the newly allocated stack
for the Dxe phase.
Therefore, specify 128 KiB as the stack size in the call to
LoadDxeCoreFromFv () so that a separate stack is allocated
and used for the Dxe phase.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
ArmVirtXen.dsc initializes
gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVersionString with with the
value of the variable "FIRMWARE_VER".
Move that functionality to ArmVirt.dsc.inc to make it available to all
ArmVirt packages, and make it conditional: only set the PCD string if
FIRMWARE_VER is actually defined.
This allows specifying the firmware version string on the build command
line with -D FIRMARE_VER=...
Signed-off-by: Oliver Steffen <osteffen@redhat.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
__FUNCTION__ is a pre-standard extension that gcc and Visual C++ among
others support, while __func__ was standardized in C99.
Since it's more standard, replace __FUNCTION__ with __func__ throughout
ArmVirtPkg.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
The IdMap.S asm source file has not executable content, but its lack of
a BTI annotation prevents the linker from marking any executables it
emits as BTI compatible if this object is part of the build. So add the
BTI note by hand.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
The Rtc library for the kvmtool guest firmware configures the
RTC controller address range as runtime memory by calling the
gDS->SetMemorySpaceAttributes().
The SetMemorySpaceAttributes() function has a dependency on
the CPU Arch Protocol. If the CPU Arch Protocol is not
installed the call to set the memory attributes fails with
error code EFI_NOT_AVAILABLE_YET.
Therefore, set the library dependency on the CPU Arch protocol.
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
When scanning for the Serial Port in the device
tree, the length and value parameters to ScanMem8()
are not in the right order. This results in the
serial port not being detected if the chosen node
in the device tree has additional elements.
Therefore, pass the parameters to ScanMem8() in the
correct order to fix this issue.
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Pierre Gondois <pierre.gondois@arm.com>
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
commit f13264b34 introduces a bug for CloudHv as OvmfPkg/OvmfPkg.dec is
missing in CloudHvHasAcpiDtDxe.inf which leads to
gUefiOvmfPkgTokenSpaceGuid found nowhere when build.
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Jianyong Wu <jianyong.wu@arm.com>
The PEI flavor of the ArmMmuLib will install a HOB that exposes its
implementation of the special helper routine that is used to update live
entries, so that other instantiations of ArmMmuLib can invoke it. This
is needed to ensure that splitting page tables using break-before-make
(BBM) does not unmap the code that is performing the split.
However, the BASE variety of ArmMmuLib discovers the HOB and sets a
global pointer to refer to it, which is not possible in PEIMs, and so
all PEIMs must use the PEI variety of this library if one does.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Enable the stack guard in ArmVirtPkg builds, so that stack overflows are
caught as they occur, rather than when they happen to hit a read-only
memory region.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4076
PlatformHasAcpiDtDxe is required by other architectures also.
Hence, it is moved to OvmfPkg. So, update the consumers of this
module with the new location.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Sunil V L <sunilvl@ventanamicro.com>
Reviewed-by: Andrei Warkentin <andrei.warkentin@intel.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4076
This module is required by other architectures like RISC-V.
Hence, move this to OvmfPkg.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Sunil V L <sunilvl@ventanamicro.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Andrei Warkentin <andrei.warkentin@intel.com>
Since RvdPeCoffExtraActionLib has been deleted, remove lines referencing
it and the RealView Debugger from ArmVirtPkg.dsc.inc.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Acked-by: Bob Feng <bob.c.feng@intel.com>
ArmVirtQemuKernel.dsc describes a firmware build that is loadable at
arbitrary address and can be invoked using the Linux/arm64 kernel boot
protocol. The early code deviates significantly from ArmVirtQemu, and so
it makes sense to cover this platform in CI even if it is not widely
used. This ensures that the relocatable PrePi and other components in
EmbeddedPkg don't regress on ARM as they are being updated for use on
TDVF.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
David Woodhouse
Chao Li
Jianyong Wu
Ard Biesheuvel
Rebecca Cran
Taylor Beebe
Michael Kubacki
Laszlo Ersek
Leif Lindholm
Pierre Gondois
Gerd Hoffmann
Oliver Smith-Denny
Corvin Köhne
Sami Mujawar
Oliver Steffen
Rebecca Cran
Sunil V L