Memory layout in CLoud Hypervisor for arm is changed and is different
with Qemu, thus we should build its own PeiMemInfoLib.
The main change in the memory layout is that normal ram may not contiguous
under 4G. The top 64M under 4G is reserved for 32bit device.
What this patch does:
1. get all of the memory node from DT;
2. Init page table for each memory node;
3. Add all of the memory nodes to Hob;
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Jianyong Wu <jianyong.wu@arm.com>
In an effort to clean the documentation of the above
package, remove duplicated words.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.muajwar@arm.com>
Alex reports that the cache invalidation performed by
ArmVirtMemoryInitPeiLib takes a non-negligible amount of time at boot.
This cache invalidation used to be necessary to avoid inconsistencies
between the CPU's cached and uncached views of the permanent PEI memory
region, given that the PEI phase is where the MMU gets enabled.
The only allocations done from permanent PEI memory with the MMU off are
pages used for page tables, and since commit 748fea6279
("ArmPkg/ArmMmuLib AARCH64: invalidate page tables before populating
them"), each of those is invalidated in the caches explicitly, for
reasons described in the patch's commit log. All other allocations done
in PEI are either from temporary PEI memory, which includes the stack,
or from permanent PEI memory but after the MMU has been enabled.
This means that the cache invalidation in ArmVirtMemoryInitPeiLib is no
longer necessary, and can simply be dropped.
Reported-by: Alexander Graf <graf@amazon.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
Reviewed-by: Alexander Graf <graf@amazon.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Move BaseCachingPciExpressLib library from ArmVirtPkg to under OvmfPkg.
RISC-V Virt platform can leverage the same library to access PCI Express
registers through PCI Express base address set in PcdPciExpressBaseAddress
and cached in a global variable.
Cc: Daniel Schaefer <daniel.schaefer@hpe.com>
Cc: Sunil V L <sunilvl@ventanamicro.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Abner Chang <abner.chang@hpe.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3737
Apply uncrustify changes to .c/.h files in the ArmVirtPkg package
Cc: Andrew Fish <afish@apple.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3767
Update use of DEBUG_CODE(Expression) if Expression is a complex code
block with if/while/for/case statements that use {}.
Cc: Andrew Fish <afish@apple.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Michael Kubacki <michael.kubacki@microsoft.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3760
Update all use of ', OPTIONAL' to ' OPTIONAL,' for function params.
Cc: Andrew Fish <afish@apple.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Michael Kubacki <michael.kubacki@microsoft.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3739
Update all use of EFI_D_* defines in DEBUG() macros to DEBUG_* defines.
Cc: Andrew Fish <afish@apple.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Michael Kubacki <michael.kubacki@microsoft.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Relocate FdtPciHostBridgeLib to OvmfPkg/Fdt, this library is
leverage by both ARM and RISC-V archs. Also use
PcdPciMmio32Translation and PcdPciMmio64Translation
PCDs provided by MdePkg instead of ArmPkg.
Signed-off-by: Abner Chang <abner.chang@hpe.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Daniel Schaefer <daniel.schaefer@hpe.com>
Cc: Sunil V L <sunilvl@ventanamicro.com>
Reviewed-by: Daniel Schaefer <daniel.schaefer@hpe.com>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Jiewen Yao <jiewen.yao@intel.com>
Relocate QemuFwCfgLib to OvmfPkg/Library/QemuFwCfgLib and rename
it to QemuFwCfgLibMmio, this library is leverage by both ARM and
RISC-V archs.
Signed-off-by: Abner Chang <abner.chang@hpe.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Daniel Schaefer <daniel.schaefer@hpe.com>
Cc: Sunil V L <sunilvl@ventanamicro.com>
Reviewed-by: Daniel Schaefer <daniel.schaefer@hpe.com>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Jiewen Yao <jiewen.yao@intel.com>
Relocate PciPcdProducerLib to OvmfPkg/Fdt, this library is
leverage by both ARM and RISC-V archs.
Add OvmfPkg/Fdt maintainers in Maintainers.txt
Signed-off-by: Abner Chang <abner.chang@hpe.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Daniel Schaefer <daniel.schaefer@hpe.com>
Cc: Sunil V L <sunilvl@ventanamicro.com>
Reviewed-by: Daniel Schaefer <daniel.schaefer@hpe.com>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
PcdPciIoTranslation PCD is relocated to MdePkg and leveraged by
both ARM and RISC-V arch. This patch removes the one from ArmPkg
and address the corresponding changes required for other modules
under ArmVirtPkg.
Signed-off-by: Abner Chang <abner.chang@hpe.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Daniel Schaefer <daniel.schaefer@hpe.com>
Cc: Sunil V L <sunilvl@ventanamicro.com>
Reviewed-by: Daniel Schaefer <daniel.schaefer@hpe.com>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
This is one of the series patches to restructure the location of modules under
ArmVirtPkg for RiscVVirtPkg. RiscVVirtPkg leverage FDT Client protocol to
parse FDT nodes.
Signed-off-by: Abner Chang <abner.chang@hpe.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Daniel Schaefer <daniel.schaefer@hpe.com>
Cc: Sunil V L <sunilvl@ventanamicro.com>
Reviewed-by: Daniel Schaefer <daniel.schaefer@hpe.com>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Disable the TPM2 platform hierarchy by directly calling
ConfigureTpmPlatformHierarchy().
Per the TCG firmware specification "TCG PC Client Platform Firmware Profile
Specification" the TPM 2 platform hierarchy needs to be disabled or a
random password set and discarded before the firmware passes control to the
next stage bootloader or kernel.
Current specs are here:
https://trustedcomputinggroup.org/wp-content/uploads/TCG_PCClient_PFP_r1p05_v23_pub.pdf
Section 11 states:
"Platform Firmware MUST protect access to the Platform Hierarchy
and prevent access to the platform hierarchy by non-manufacturer-
controlled components."
Link: https://bugzilla.tianocore.org/show_bug.cgi?id=3510
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
We just added the same functionality to the OvmfPkg. However, on x86, we
could use the notification mechanism around
gEfiDxeSmmReadyToLockProtocolGuid to indirectly invoke
ConfigureTpmPlatformHierarchy(). Since ARM does not have an SMM mode, we
have to use direct invocation of this function at the same place in
PlatformBootManagerBeforeConsole() as it is called on x86.
Link: https://bugzilla.tianocore.org/show_bug.cgi?id=3510
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
PCIe support has been added to Kvmtool Virtual Machine Manager.
The PCI host bridge utility lib is used to retrieve information
about the Root Bridges in a platform.
Therefore, add an instance of PciHostBridgeUtilityLib as this is
required to enable PCIe support for Kvmtool firmware.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Pierre Gondois <Pierre.Gondois@arm.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Tested-by: Alexandru Elisei <alexandru.elisei@arm.com>
In order to take advantages of extra pci root buses in ArmVirtPkg, it is
necessary to scan extra root buses when getting root briges. And now
PciHostBridgeUtilityLib already provides a set of utility functions that
support for extra pci root buses, like PciHostBridgeUtilityGetRootBridges()
/ PciHostBridgeUtilityFreeRootBridges(). So let's rebase
ArmVirtPkg/FdtPciHostBridgeLib to PciHostBridgeUtilityGetRootBridges() /
PciHostBridgeUtilityFreeRootBridges() to extend ArmVirtPkg with extra
pci root buses support.
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3059
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Signed-off-by: Jiahui Cen <cenjiahui@huawei.com>
Signed-off-by: Yubo Miao <miaoyubo@huawei.com>
Message-Id: <20210119011302.10908-11-cenjiahui@huawei.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
The PlatformPeim() in the PlatformPeiLib is invoked
by the PrePiMain() and provides the platform an
opportunity to setup the plaform specific HOBs.
This PlatfromPeiLib initialises the Kvmtool platform
HOBs like the Fdt, 16550BaseAddress, etc.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Ard Biesheuvel <Ard.Biesheuvel@arm.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
The BaseSerialPort16550 library invokes the
PlatformHookSerialPortInitialize() implemented as
part of the PlatformHook library, to perform platform
specific initialization required to enable use of the
16550 device. The BaseSerialPort16550 library uses
the PcdSerialRegisterBase to obtain the base address
of the UART for MMIO operations.
Some VMMs like Kvmtool provide the base address of
the console serial port in the platform device tree.
This patch introduces two instances of the Platform
Hook library:
1. EarlyFdt16550SerialPortHookLib - parses the
platform device tree to extract the base
address of the 16550 UART and update the PCD
PcdSerialRegisterBase.
2. Fdt16550SerialPortHookLib - reads the GUID
Hob gEarly16550UartBaseAddressGuid (that caches
the base address of the 16550 UART discovered
during early stages) and updates the PCD
PcdSerialRegisterBase.
Note:
a. The PCD PcdSerialRegisterBase is configured
as PatchableInModule.
b. A separate patch introduces a PlatformPeiLib
that trampolines the 16550 UART base address
from the Pcd PcdSerialRegisterBase to the
GUID Hob gEarly16550UartBaseAddressGuid.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Ard Biesheuvel <Ard.Biesheuvel@arm.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Kvmtool places the base address of the CFI flash in
the device tree it passes to UEFI. This library
parses the kvmtool device tree to read the CFI base
address and initialise the PCDs use by the NOR flash
driver and the variable storage.
UEFI takes ownership of the CFI flash hardware, and
exposes its functionality through the UEFI Runtime
Variable Service. Therefore, disable the device tree
node for the CFI flash used for storing the UEFI
variables, to prevent the OS from attaching its device
driver as well.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Kvmtool is a virtual machine manager that enables
hosting KVM guests. Kvmtool allows to vary the
hardware configuration of the virtual platform
it provides to the guest partition. It provides
the current hardware configuration to the firmware
by handing off a device tree containing the hardware
information.
This library parses the kvmtool provided device
tree and populates the system memory map for the
kvmtool virtual platform.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Ard Biesheuvel <Ard.Biesheuvel@arm.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Add library that parses the Kvmtool device tree and updates
the dynamic PCDs describing the RTC Memory map.
It also maps the MMIO region used by the RTC as runtime memory
so that the RTC registers are accessible post ExitBootServices.
Since UEFI takes ownership of the RTC hardware disable the RTC
node in the DT to prevent the OS from attaching its device
driver as well.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Our UEFI guest firmware takes ownership of the emulated NOR flash in
order to support the variable runtime services, and it does not expect
the OS to interfere with the underlying storage directly. So disable
the NOR flash DT nodes as we discover them, in a way similar to how we
disable the PL031 RTC in the device tree when we attach our RTC runtime
driver to it.
Note that this also hides the NOR flash bank that carries the UEFI
executable code, but this is not intended to be updatable from inside
the guest anyway, and if it was, we should use capsule update to do so.
Also, the first -pflash argument that defines the backing for this flash
bank is often issued with the 'readonly' modifier, in order to prevent
any changes whatsoever to be made to the executable firmware image by
the guest.
This issue has become relevant due to the following Linux changes,
which enable the flash driver stack for default build configurations
targetting arm64 and 32-bit ARM.
ce693fc2a877
("arm64: defconfig: Enable flash device drivers for QorIQ boards", 2020-03-16).
5f068190cc10
("ARM: multi_v7_defconfig: Enable support for CFI NOR FLASH", 2019-04-03)
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
We don't distribute UEFI_DRIVER modules stand-alone that were built as
part of an ArmVirtQemu* platform. ArmVirtQemu* UEFI_DRIVERs are allowed to
inherit platform dependencies.
By enabling UEFI_DRIVERs to consume QemuFwCfgLib, we can hook fw_cfg-based
NULL class libraries into UEFI drivers, e.g. in order to set dynamic PCDs.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Per Sundstrom <per_sundstrom@yahoo.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2681
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200424075353.8489-7-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Older GCC (<= 4.9) fail to infer that Parent is never used unless it
has been assigned before, and may throw an error like
/work/git/edk2/ArmVirtPkg/Library/PlatformPeiLib/PlatformPeiLib.c:
In function ‘PlatformPeim’:
/work/git/edk2/ArmVirtPkg/Library/PlatformPeiLib/PlatformPeiLib.c:132:24:
error: ‘Parent’ may be used uninitialized in this function
[-Werror=maybe-uninitialized]
RangesProp = fdt_getprop (Base, Parent, "ranges", &RangesLen);
Set Parent to 0 at the start of the sequence to work around this.
Link: https://bugzilla.tianocore.org/show_bug.cgi?id=2601
Fixes: 82662a3b5f ("ArmVirtPkg/PlatformPeiLib: discover the TPM base ...")
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
ArmVirtGicArchLib was originally implemented before virtualization
emulation was implemented in QEMU, and the GICv2 model implemented only
the physical copy of control registers.
Enabling virtualization emulation to QEMU adds also the virtual copy,
doubling the RegSize returned by FindCompatibleNodeReg () in
ArmVirtGicArchLibConstructor (). This triggered an ASSERT when running
QEMU with -M virt,virtualization=on. Address this by testing for both
possible valid values of RegSize.
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2588
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Leif Lindholm <leif@nuviainc.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Drop the QEMU loader file system implementation inside this library,
and switch to the separate QemuLoadImageLib library and the associated
driver to expose the kernel and initrd passed via the QEMU command line.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2566
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Set the Timeout global variable to the same value as
PcdPlatformBootTimeOut. This way the "setvar" command in the UEFI shell,
and the "efibootmgr" command in a Linux guest, can report the front page
timeout that was requested on the QEMU command line (see
GetFrontPageTimeoutFromQemu()).
A DEBUG_VERBOSE message is logged on success too, for our QE team's sake.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200304094413.19462-3-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Implement a ArmVirtPkg specific version of the PSCI ResetSystemLib that
is usable in the PEI phase, as the existing one relies on the FDT client
protocol, making it unsuitable.
Note that accessing the device tree passed by QEMU via its initial base
address is guaranteed to be safe at any time during the PEI phase, so we
can defer discovery of the PSCI method until the time the reset library
is actually invoked (which is rarely)
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2560
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Introduce a boolean PCD that tells us whether TPM support is enabled
in the build, and if it is, record the TPM base address in the existing
routine that traverses the device tree in the platform PEIM.
If a TPM is found, install the gOvmfTpmDiscoveredPpiGuid signalling PPI
that will unlock the dispatch of OvmfPkg's Tcg2ConfigPei. If TPM2
support is enabled in the build but no TPM2 device is found, install the
gPeiTpmInitializationDonePpiGuid PPI, which is normally installed by
Tcg2ConfigPei if no TPM2 is found, but in our case Tcg2ConfigPei will
never run so let's do it here instead.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2560
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
We currently include PcdLib.h in PlatformPeiLib, without declaring
this dependency in its .INF description. Since all the PCDs we use
resolve to fixed type in practice, this does not really matter at
the moment, but since we will be adding dynamic PCD references in
a subsequent patch, let's make the PcdLib dependency explicit, so
that its dispatch is guaranteed to be ordered correctly with respect
to the provider of the dynamic PCD PPI.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2560
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
EnterS3WithImmediateWake () no longer has any callers, so remove it
from ResetSystemLib.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2266
Similar to what we now do for OVMF, we need to consider the possibility
that PlatformBootManagerWaitCallback () may be called with a
PcdPlatformBootTimeOut that was set to zero, in which case the call should
simply return.
We also change the initial timeout variable name to make the code explicit.
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Message-Id: <20191014150311.16740-3-pete@akeo.ie>
The LoadImage() boot service is a bit unusual in that it allocates
resources in a particular failure case; namely, it produces a valid
"ImageHandle" when it returns EFI_SECURITY_VIOLATION. This is supposed to
happen e.g. when Secure Boot verification fails for the image, but the
platform policy for the particular image origin (such as "fixed media" or
"removable media") is DEFER_EXECUTE_ON_SECURITY_VIOLATION. The return code
allows platform logic to selectively override the verification failure,
and launch the image nonetheless.
ArmVirtPkg/PlatformBootManagerLib does not override EFI_SECURITY_VIOLATION
for the kernel image loaded from fw_cfg -- any LoadImage() error is
considered fatal. When we simply treat EFI_SECURITY_VIOLATION like any
other LoadImage() error, we leak the resources associated with
"KernelImageHandle". From a resource usage perspective,
EFI_SECURITY_VIOLATION must be considered "success", and rolled back.
Implement this rollback, without breaking the proper "nesting" of error
handling jumps and labels.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1992
Fixes: 23d04b58e2
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Move XenRealTimeClockLib from ArmVirtPkg to OvmfPkg so it can be used
from the OvmfPkg by the following patch, "OvmfPkg/OvmfXen: use
RealTimeClockRuntimeDxe from EmbeddedPkg"
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20190813113119.14804-35-anthony.perard@citrix.com>
SERIAL_DXE_FILE_GUID is now defined in MdeModulePkg as
EDKII_SERIAL_PORT_LIB_VENDOR_GUID, simply use it.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Message-Id: <20190606131459.1464-3-anthony.perard@citrix.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
[lersek@redhat.com: drop "from MdeModulePkg" from the subject]
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1460
Add a new API ResetSystem to this ResetSystemLib instance.
It only adds the basic functions from ResetSystemRuntimeDxe.
Lacking of this interface may cause link error, if some drivers
use this new API and link to this library instance.
Notes:
This library API only provide a basic function of reset. Full
function should use the instance in the MdeModulePkg and make
sure the depex driver is dispatched.
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
The current ArmVirtMemoryInitPeiLib code splits the memory region passed
via PcdSystemMemoryBase/PcdSystemMemorySize in two if the region extends
beyond the MAX_ADDRESS limit. This was introduced for 32-bit ARM, which
may support more than 4 GB of physical address space, but cannot address
all of it via a 1:1 mapping, and a single region that is not mappable
in its entirety is unusable by the PEI core.
AArch64 is in a similar situation now: platforms may support more than
256 TB of physical address space, but only 256 TB is addressable by the
CPU, and so a memory region that extends from below this limit to above
it should be split.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
QEMU/mach-virt is rather unhelpful when it comes to tracking down
NULL pointer dereferences that occur while running in UEFI: since
we have NOR flash mapped at address 0x0, inadvertent reads go
unnoticed, and even most writes are silently dropped, unless you're
unlucky and the instruction in question is one that KVM cannot
emulate, in which case you end up with a QEMU crash like this:
error: kvm run failed Function not implemented
PC=000000013f7ff804 X00=000000013f7ab108 X01=0000000000000064
X02=000000013f801988 X03=00000000800003c4 X04=0000000000000000
X05=0000000096000044 X06=fffffffffffd8270 X07=000000013f7ab4a0
X08=0000000000000001 X09=000000013f803b88 X10=000000013f7e88d0
X11=0000000000000009 X12=000000013f7ab554 X13=0000000000000008
X14=0000000000000002 X15=0000000000000000 X16=0000000000000000
X17=0000000000000000 X18=0000000000000000 X19=0000000000000000
X20=000000013f81c000 X21=000000013f7ab170 X22=000000013f81c000
X23=0000000009000018 X24=000000013f407020 X25=000000013f81c000
X26=000000013f803530 X27=000000013f802000 X28=000000013f7ab270
X29=000000013f7ab0d0 X30=000000013f7fee10 SP=000000013f7a6f30
PSTATE=800003c5 N--- EL1h
and a warning in the host kernel log that load/store instruction
decoding is not supported by KVM.
Given that the first page of the flash device is not actually
used anyway, let's reduce the mappings of the peripheral space
and the flash device (both of which cover page #0) to only cover
what is actually required:
ArmVirtQemu.fdf:
> 0x00001000|0x001ff000
> gArmTokenSpaceGuid.PcdFvBaseAddress|gArmTokenSpaceGuid.PcdFvSize
ArmVirtQemuKernel.fdf:
> 0x00008000|0x001f8000
> gArmTokenSpaceGuid.PcdFvBaseAddress|gArmTokenSpaceGuid.PcdFvSize
For ArmVirtQemu, the resulting virtual mapping looks roughly like:
- [0, 4K) : flash, unmapped
- [4K, 2M) : flash, mapped as WB+X RAM
- [2M, 64M) : flash, unmapped
- [64M, 128M) : varstore flash, will be mapped by the NOR flash driver
- [128M, 256M) : peripherals, mapped as device
- [256M, 1GB) : 32-bit MMIO aperture, translated IO aperture, ECAM,
will be mapped by the PCI host bridge driver
- [1GB, ...) : RAM, mapped.
After this change, any inadvertent read or write from/to the first
physical page will trigger a translation fault inside the guest,
regardless of the nature of the instruction, without crashing QEMU.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
The primary FV contains the firmware boot image, which is not
runtime updatable in our case. So exposing it to the NOR flash
driver is undesirable, since it may attempt to modify the NOR
flash contents. It is also rather pointless, since we don't
keep anything there that we care to expose. (the SEC and PEI
phase modules are not executable from DXE context, and the
contents of the embedded DXE phase FV are exposed by the DXE
core directly via the FVB2 protocol)
So let's disregard the NOR flash block that covers the primary
FV.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Use the new ArmLib helper to read the CPU's physical address limit
so we can drop our own homecooked one.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Currently, we map DRAM as EFI_MEMORY_WB, and the remainder of the
entire virtual address space is mapped with EFI_MEMORY_UC attributes,
regardless of whether any devices actually reside there.
Now that we are relaxing the address space limit to more than 40 bits,
mapping all that address space actually takes up more space in page
tables than we have so far made available as temporary RAM. So let's
get rid of the mapping rather than increasing the available RAM, given
that the mapping is not particularly useful anyway.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Up until now, we have been getting away with not declaring the ECAM
and translated I/O spaces at all in the GCD memory map, simply because
we map the entire address space with device attributes in the early PEI
code, and so the ECAM space will be mapped wherever it ends up.
Now that we are about to make changes to how ArmVirtQemu reasons
about the size of the address space, it would be better to get rid
of this mapping of the entire address space, since it can get
arbitrarily large without real benefit.
So start by mapping the ECAM and translated I/O spaces explicitly,
instead of relying on the early PEI mapping.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
NorFlashQemuLib is one of the last remaining drivers in ArmVirtPkg
that are not based on the device tree received from QEMU.
For ArmVirtQemu, this does not really matter, given that the NOR
flash banks are always the same: the PEI code is linked to execute
in place from flash bank #0, and the fixed varstore PCDs refer to
flash bank #1 directly.
However, ArmVirtQemuKernel can execute at any offset, permitting it
to be used as an intermediary loader when running QEMU with secure
world emulation enabled, in which case NOR flash bank #0 is secure
only and contains the secure world firmware. In this case,
NorFlashQemuLib should not expose the first flash bank at all.
To prevent introducing too much internal knowledge about which flash
bank is accessible under which circumstances, let's switch to using
the DTB to decide which flash banks to expose to the NOR flash driver.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Jianyong Wu
Pierre Gondois
Ard Biesheuvel
Abner Chang
Michael Kubacki
Michael D Kinney
Stefan Berger
Sami Mujawar
Jiahui Cen via groups.io
Ard Biesheuvel
Laszlo Ersek
Ard Biesheuvel
Leif Lindholm
Pete Batard
Anthony PERARD
Zhichao Gao
Antoine Coeur
Ruiyu Ni