The EFI_RETURN_STATUS_EXTENDED_DATA feature from PI-1.7
(<https://mantis.uefi.org/mantis/view.php?id=1885>) enables platform code
to learn about boot option failures (loading and launching) via status
codes reported by the UEFI Boot Manager.
In commit 59541d4163, we removed all status code support from
ArmVirtPkg. Reenable that support now, minimally, just to the extent so we
can benefit from the PI-1.7 feature mentioned above:
(1) Include the ReportStatusCodeRouterRuntimeDxe driver.
This driver produces two protocols, EFI_STATUS_CODE_PROTOCOL and
EFI_RSC_HANDLER_PROTOCOL. The former allows DXE phase modules and
runtime modules to report (produce) status codes. The latter allows
the same types of modules to register callbacks for status code
handling (consumption).
(Handler registration occurs only at boot time. Status codes are
delivered to each handler at runtime as well, unless the handler is
unregistered at ExitBootServices().)
(2) Resolve ReportStatusCodeLib to a non-Null instance, for DXE_DRIVER
modules only. This way DXE_DRIVER modules that use the
REPORT_STATUS_CODE_EX() macro and friends will reach
EFI_STATUS_CODE_PROTOCOL from point (1).
(3) Set PcdReportStatusCodePropertyMask to 3 (the default value is 0).
This causes the REPORT_STATUS_CODE_EX() macro and friends to let
Progress Codes (bit#0) and Error Codes (bit#1) through to point (1).
Debug Codes (bit#2) are filtered out.
(4) Include no driver, for now, that registers any status code handler via
EFI_RSC_HANDLER_PROTOCOL, from point (1). Status codes that reach
ReportStatusCodeRouterRuntimeDxe will be thrown away.
(5) Modify only the ArmVirtQemu* platforms. A status code handler will
be added to "ArmVirtPkg/Library/PlatformBootManagerLib" in the next patch,
and this library instance is not consumed by ArmVirtXen.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Julien Grall <julien.grall@linaro.org>
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1515418
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
According to the
PCDs not used by modules or in conditional directives
sections of all the build reports for
{AARCH64,ARM} x {Xen} x {DEBUG,NOOPT,RELEASE} x {feat-1}
(6 builds in total), PcdOptionRomImageVerificationPolicy,
PcdFixedMediaImageVerificationPolicy, and
PcdRemovableMediaImageVerificationPolicy are not used in any of those
builds.
Restrict the settings to the ArmVirtQemu and ArmVirtQemuKernel platforms
(preserving the -D SECURE_BOOT_ENABLE restriction in the process).
("feat-1" stands for "-D HTTP_BOOT_ENABLE -D NETWORK_IP6_ENABLE -D
SECURE_BOOT_ENABLE -D TTY_TERMINAL", while "feat-0" stands for "".)
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Julien Grall <julien.grall@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
According to the
PCDs not used by modules or in conditional directives
sections of all the build reports for
{AARCH64,ARM} x {Xen} x {DEBUG,NOOPT,RELEASE} x {feat-0,feat-1}
(12 builds in total), the PCD is not used in any of those builds. Restrict
the setting to the ArmVirtQemu and ArmVirtQemuKernel platforms.
("feat-1" stands for "-D HTTP_BOOT_ENABLE -D NETWORK_IP6_ENABLE -D
SECURE_BOOT_ENABLE -D TTY_TERMINAL", while "feat-0" stands for "".)
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Julien Grall <julien.grall@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
According to the
PCDs not used by modules or in conditional directives
sections of all the build reports for
{AARCH64,ARM} x {Xen} x {DEBUG,NOOPT,RELEASE} x {feat-0,feat-1}
(12 builds in total), the PCD is not used in any of those builds. Remove
the setting.
("feat-1" stands for "-D HTTP_BOOT_ENABLE -D NETWORK_IP6_ENABLE -D
SECURE_BOOT_ENABLE -D TTY_TERMINAL", while "feat-0" stands for "".)
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Julien Grall <julien.grall@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
According to the
PCDs not used by modules or in conditional directives
sections of all the build reports for
{AARCH64,ARM} x {Xen} x {DEBUG,NOOPT,RELEASE} x {feat-0,feat-1}
(12 builds in total), the PCD is not used in any of those builds.
Restrict the setting to the ArmVirtQemu and ArmVirtQemuKernel platforms.
Restrict the TTY_TERMINAL define similarly.
("feat-1" stands for "-D HTTP_BOOT_ENABLE -D NETWORK_IP6_ENABLE -D
SECURE_BOOT_ENABLE -D TTY_TERMINAL", while "feat-0" stands for "".)
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Julien Grall <julien.grall@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
According to the
PCDs not used by modules or in conditional directives
sections of all the build reports for
{AARCH64,ARM} x {Xen} x {DEBUG,NOOPT,RELEASE} x {feat-0,feat-1}
(12 builds in total), the PCD is not used in any of those builds. Remove
the setting.
("feat-1" stands for "-D HTTP_BOOT_ENABLE -D NETWORK_IP6_ENABLE -D
SECURE_BOOT_ENABLE -D TTY_TERMINAL", while "feat-0" stands for "".)
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Julien Grall <julien.grall@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
According to the
PCDs not used by modules or in conditional directives
sections of all the build reports for
{AARCH64,ARM} x {Qemu,QemuKernel,Xen} x {RELEASE} x {feat-0,feat-1}
(12 builds in total), the PCD is not used in any of those builds. Restrict
the PCD setting to ($(TARGET) != RELEASE).
("feat-1" stands for "-D HTTP_BOOT_ENABLE -D NETWORK_IP6_ENABLE -D
SECURE_BOOT_ENABLE -D TTY_TERMINAL", while "feat-0" stands for "".)
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Julien Grall <julien.grall@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
According to the
PCDs not used by modules or in conditional directives
sections of all the build reports for
{AARCH64,ARM} x {Qemu,QemuKernel,Xen} x {RELEASE} x {feat-0,feat-1}
(12 builds in total), the PCD is not used in any of those builds.
Rather than just restrict the PCD setting to ($(TARGET) != RELEASE),
remove the setting completely. The current value is identical to the 0xAF
default in "MdePkg/MdePkg.dec", which recognizes Andrew Fish, and so it's
unlikely to ever change.
("feat-1" stands for "-D HTTP_BOOT_ENABLE -D NETWORK_IP6_ENABLE -D
SECURE_BOOT_ENABLE -D TTY_TERMINAL", while "feat-0" stands for "".)
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Julien Grall <julien.grall@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
According to the
PCDs not used by modules or in conditional directives
sections of all the build reports for
{AARCH64,ARM} x
{Qemu,QemuKernel,Xen} x
{DEBUG,NOOPT,RELEASE} x
{feat-0,feat-1}
(36 builds in total), the PCD is not used in any of those builds. Remove
the setting.
("feat-1" stands for "-D HTTP_BOOT_ENABLE -D NETWORK_IP6_ENABLE -D
SECURE_BOOT_ENABLE -D TTY_TERMINAL", while "feat-0" stands for "".)
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Julien Grall <julien.grall@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
The PcdCoreCount dependency in the "ArmVirtPrePiUniCoreRelocatable.inf"
file is false; the module doesn't consume the PCD. Clean up the INF.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Julien Grall <julien.grall@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
According to the
PCDs not used by modules or in conditional directives
sections of all the build reports for
{AARCH64,ARM} x
{QemuKernel,Xen} x
{DEBUG,NOOPT,RELEASE} x
{feat-0,feat-1}
(24 builds in total), the PCD is not used in any of those builds.
Move the setting from "ArmVirt.dsc.inc" to "ArmVirtQemu.dsc", to reflect
reality.
We originally moved the PCD setting in the opposite direction in commit
8aab575c26 ("ArmVirtPkg: enable non-executable DXE stack for all
platforms", 2017-03-07), generalizing it. However, as the comment itself
states, and according to all 36 ArmVirt build reports:
{AARCH64,ARM} x
{Qemu,QemuKernel,Xen} x
{DEBUG,NOOPT,RELEASE} x
{feat-0,feat-1}
the PCD is only consumed by "MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf", and
that module is only included in the ArmVirtQemu platform.
("feat-1" stands for "-D HTTP_BOOT_ENABLE -D NETWORK_IP6_ENABLE -D
SECURE_BOOT_ENABLE -D TTY_TERMINAL", while "feat-0" stands for "".)
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Julien Grall <julien.grall@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
According to the
PCDs not used by modules or in conditional directives
sections of all the build reports for
{AARCH64,ARM} x
{Qemu,QemuKernel,Xen} x
{DEBUG,NOOPT,RELEASE} x
{feat-0,feat-1}
(36 builds in total), the PCD is not used in any of those builds. Remove
the setting.
("feat-1" stands for "-D HTTP_BOOT_ENABLE -D NETWORK_IP6_ENABLE -D
SECURE_BOOT_ENABLE -D TTY_TERMINAL", while "feat-0" stands for "".)
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Julien Grall <julien.grall@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
According to the
PCDs not used by modules or in conditional directives
sections of all the build reports for
{AARCH64,ARM} x
{Qemu,QemuKernel} x
{DEBUG,NOOPT,RELEASE} x
{feat-0,feat-1}
(24 builds in total), the PCD is not used in any of those builds. Remove
the setting.
("feat-1" stands for "-D HTTP_BOOT_ENABLE -D NETWORK_IP6_ENABLE -D
SECURE_BOOT_ENABLE -D TTY_TERMINAL", while "feat-0" stands for "".)
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Julien Grall <julien.grall@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
According to the
PCDs not used by modules or in conditional directives
sections of all the build reports for
{AARCH64,ARM} x
{Qemu,QemuKernel,Xen} x
{DEBUG,NOOPT,RELEASE} x
{feat-0,feat-1}
(36 builds in total), the PCD is not used in any of those builds. Remove
the setting.
("feat-1" stands for "-D HTTP_BOOT_ENABLE -D NETWORK_IP6_ENABLE -D
SECURE_BOOT_ENABLE -D TTY_TERMINAL", while "feat-0" stands for "".)
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Julien Grall <julien.grall@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
According to the
PCDs not used by modules or in conditional directives
sections of all the build reports for
{AARCH64,ARM} x {QemuKernel} x {DEBUG,NOOPT,RELEASE} x {feat-0,feat-1}
(12 builds in total), the PCD is not used in any of those builds. Remove
the setting.
("feat-1" stands for "-D HTTP_BOOT_ENABLE -D NETWORK_IP6_ENABLE -D
SECURE_BOOT_ENABLE -D TTY_TERMINAL", while "feat-0" stands for "".)
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Julien Grall <julien.grall@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
This patch is not related directly to
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1323
Merge EmuVariable and Real variable driver.
It just makes ArmVirtXen be aligned with ArmVirtQemuXXX to
link VarCheckUefiLib NULL class library instance.
Suggested-by: Laszlo Ersek <lersek@redhat.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Julien Grall <julien.grall@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Julien Grall <julien.grall@arm.com>
Acked-by: Julien Grall <julien.grall@arm.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1323
Merge EmuVariable and Real variable driver.
The real variable driver has been updated to support emulated
variable NV mode and the EmuVariableRuntimeDxe will be removed
later, so use merged variable driver for emulated NV mode.
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Julien Grall <julien.grall@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Julien Grall <julien.grall@arm.com>
Acked-by: Julien Grall <julien.grall@arm.com>
Drop the reference to ArmPkg/DefaultExceptionHandlerLibBase, which
is no longer used anywhere now that DebugAgentSymbolsBaseLib no
longer incorporates a vector table and exception handling.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
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>
Commit 9a67ba261f ("ArmVirtPkg: Replace obsoleted network drivers
from platform DSC/FDF") incorrectly added the BaseCryptLib, OpensslLib
and IntrinsicLib to "ArmVirtPkg/ArmVirtQemuKernel.dsc", it's redundant
and the library instances from "ArmVirt.dsc.inc" is already sufficient.
This patch also adjust the order of network drivers in "ArmVirtPkg/
ArmVirtQemuFvMain.fdf.inc" to make it same as the DSC file.
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Julien Grall <julien.grall@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Fu Siyuan <siyuan.fu@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Commit 9a67ba261f ("ArmVirtPkg: Replace obsoleted network drivers
from platform DSC/FDF") failed to take into account that the now
unconditionally included IScsiDxe.inf from NetworkPkg requires a
resolution for TcpIoLib. Since specifying such a resolution is harmless
for platforms that have no networking enabled, let's just fix things
by dropping the conditionals around it.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
This patch replaces the MdeModulePkg TCP, PXE and iSCSI driver with those
ones in NetworkPkg. These 3 drivers in MdeModulePkg are not being actively
maintained and will be removed from edk2 master soon.
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Julien Grall <julien.grall@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Fu Siyuan <siyuan.fu@intel.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Drop the -mno-movt command line option override, which is no longer
needed, and actually incompatible with versions of Clang before 3.6.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
The self-relocating PrePi module that is used by the ArmVirtQemuKernel
and ArmVirtXen targets runs the linker in PIE mode so that it emits
dynamic relocations into the final image in a way that permits the
module to relocate itself into place before calling into the C code.
When building these targets using the CLANG38 toolchain, we switch
from the BFD to the GOLD linker, which behaves a bit differently when
building PIE executables, and insists on emitting GOT indirected symbol
references throughout, which means a) that we end up with absolute
addresses (which need to be fixed up at load time) for no good reason,
and b) we have to add support for handling GOT entries to GenFw if we
want to convert them into PE/COFF.
So instead, let's emit a shared library. Since the ELF image only serves
as the input to GenFw, this does not lead to any loss of functionality,
although it does require the -Bsymbolic linker option to be added to
ensure that no symbol based dynamic relocations are emitted (which
would, e.g., permit lazy binding for shared libraries). So for all
other toolchains, the linker option changes are a no-op.
Then, we have to convince CLANG38/GOLD that there is no need to refer
to symbols via a GOT entry. This is done by forcing hidden visibility
for all symbols in all components that make up the PrePi SEC module:
this informs the linker that a symbol is never exported or preempted,
making it safe to refer to it directly from anywhere in the code,
rather than indirectly via a GOT entry.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Move some PCD settings outs of the [PcdsFixedAtBuild.AARCH64] block,
so that they apply to 32-bit ARM as well. Without this change, the
ARM build doesn't work.
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>
PcdPrePiCpuMemorySize is no longer used so drop the PCD overrides
from all platform descriptions in ArmVirtPkg.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Derive the size of the GCD memory space map directly from the CPU's
information registers rather than from the PcdPrePiCpuMemorySize PCD,
which will be removed.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Acked-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>
DT has a [pseudo-]standardized 'status' property that can be set on
any node, and which signifies that a node should be treated as
absent unless it is set to 'ok' or 'okay'. So take this into account
when iterating over nodes.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
When setting up the stack in the startup code and jumping into C code
for the first time, ensure that the frame pointer register is cleared
so that backtraces terminate correctly. Otherwise, output like the
below is shown when encountering an exception on a DEBUG build:
Synchronous Exception at 0x0000000078A14780
PC 0x000078A14780 (0x000078A00000+0x00014780) [ 0] ArmVeNorFlashDxe.dll
PC 0x000078A10634 (0x000078A00000+0x00010634) [ 0] ArmVeNorFlashDxe.dll
PC 0x000078A11CF0 (0x000078A00000+0x00011CF0) [ 0] ArmVeNorFlashDxe.dll
PC 0x000078A11DD0 (0x000078A00000+0x00011DD0) [ 0] ArmVeNorFlashDxe.dll
PC 0x00007BC9D87C (0x00007BC98000+0x0000587C) [ 1] PartitionDxe.dll
PC 0x00007BC99B3C (0x00007BC98000+0x00001B3C) [ 1] PartitionDxe.dll
PC 0x00007F362F50 (0x00007F359000+0x00009F50) [ 2] DxeCore.dll
PC 0x00007BD63BB0 (0x00007BD5B000+0x00008BB0) [ 3] BdsDxe.dll
PC 0x00007BD6EE00 (0x00007BD5B000+0x00013E00) [ 3] BdsDxe.dll
PC 0x00007BD67C70 (0x00007BD5B000+0x0000CC70) [ 3] BdsDxe.dll
PC 0x00007F3724F0 (0x00007F359000+0x000194F0) [ 4] DxeCore.dll
PC 0x00004008FC30
PC 0x000040090130
PC 0x5800F6025800F5E1
Recursive exception occurred while dumping the CPU state
which is rather unhelpful, given that this prevent the remaining debug
output from being printed (register dump, stack dump, fault related
system registers etc)
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
The class name for the "PeiResourcePublicationLib" instance is just
"ResourcePublicationLib", not "PeiResourcePublicationLib". However, no
module included in the ArmVirtPkg platforms depends on this lib class;
remove its resolution.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Julien Grall <julien.grall@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Add the IPv6 stack to ArmVirtQemu with a cumulative port of the following
OvmfPkg commits:
* 36c6413f76 "OvmfPkg: enable the IPv6 support", 2014-12-19
* 96302b80d9 "OvmfPkg: Enable Network2 Shell Commands for IPv6",
2016-03-08
* 6d0f8941bd "OvmfPkg: always resolve OpenSslLib, IntrinsicLib and
BaseCryptLib", 2017-01-17
* 32e22f20c9 "OvmfPkg: correct the IScsiDxe module included for the IPv6
stack", 2017-01-17
The IPv6-enabled IScsiDxe driver depends on BaseCryptLib, and the
"CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf" instance depends on
IntrinsicLib and OpensslLib. This is why commit 6d0f8941bd is relevant.
However, unlike in OvmfPkg, in ArmVirtPkg we'll precisely track the
firmware features that require these library classes. (The OvmfPkg
discussion was quite complex, and the OvmfPkg solution was a compromise:
<http://mid.mail-archive.com/1484569332-13440-1-git-send-email-jiaxin.wu@intel.com>.)
The ArmVirtXen platform is not extended with the relevant drivers because
currently it doesn't include any networking support.
Cc: Julien Grall <julien.grall@linaro.org>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1007
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Removing rules for Ipf sources file:
* Remove the source file which path with "ipf" and also listed in
[Sources.IPF] section of INF file.
* Remove the source file which listed in [Components.IPF] section
of DSC file and not listed in any other [Components] section.
* Remove the embedded Ipf code for MDE_CPU_IPF.
Removing rules for Inf file:
* Remove IPF from VALID_ARCHITECTURES comments.
* Remove DXE_SAL_DRIVER from LIBRARY_CLASS in [Defines] section.
* Remove the INF which only listed in [Components.IPF] section in DSC.
* Remove statements from [BuildOptions] that provide IPF specific flags.
* Remove any IPF sepcific sections.
Removing rules for Dec file:
* Remove [Includes.IPF] section from Dec.
Removing rules for Dsc file:
* Remove IPF from SUPPORTED_ARCHITECTURES in [Defines] section of DSC.
* Remove any IPF specific sections.
* Remove statements from [BuildOptions] that provide IPF specific flags.
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Julien Grall <julien.grall@linaro.org>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Chen A Chen <chen.a.chen@intel.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Switch to the new IoLib implementation that will only use KVM
safe instructions to perform MMIO memory accesses.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Consumers of status code reports may rely on a status code to be
reported when the ReadyToBoot event is signalled. For instance,
FirmwarePerformanceDxe will fail to install the FPDT ACPI table
in this case. So add the missing call.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Resolve the PciCapLib, PciCapPciSegmentLib, and PciCapPciIoLib classes to
their single respective instances under OvmfPkg. Later patches will use
those lib classes in OvmfPkg drivers, some of which are included in
ArmVirt platforms.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Virtio RNG devices are never boot devices, so in commit ff1d0fbfba we
stopped connecting them. This is a problem because an OS boot loader may
depend on EFI_RNG_PROTOCOL to seed the OS's RNG.
Connect Virtio RNG devices again. And, while commit ff1d0fbfba removed
that from PlatformBootManagerAfterConsole(), reintroduce it now to
PlatformBootManagerBeforeConsole() -- this way Driver#### options launched
between both functions may access EFI_RNG_PROTOCOL too.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Fixes: ff1d0fbfba
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1579518
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Port OvmfPkg commit 5c3481b0b6 to ArmVirtPkg. Some explanation should
be in order (because 5c3481b0b6 doesn't offer any):
- The UefiDevicePathLibDevicePathProtocol instance uses the Device Path
Utilities Protocol, produced by DevicePathDxe, for formatting and
parsing the textual device path representation. This allows for a
lighter weight lib instance that gets linked into several DXE modules.
In comparison, the more standalone UefiDevicePathLib instance includes
the formatting and parsing routines in every client module.
- The DXE core needs DevicePathLib before it dispatches DevicePathDxe, so
it needs to stick with the standalone instance.
- DevicePathDxe itself also needs the standalone instance, for
implementing the protocol.
- The DXE-phase PCD driver, "MdeModulePkg/Universal/PCD/Dxe/Pcd.inf",
depends on DevicePathLib via UefiLib and DxeServicesLib at the least; so
with this update, it inherits a dependency on the protocol. In reverse,
DevicePathDxe depends on the PCD Protocol, via PcdLib. The cycle is
broken by using BasePcdLibNull in DevicePathDxe. That restricts it to
FixedAtBuild, Patch, and FeatureFlag PCDs, but that's fine.
Example space savings (using ArmVirtQemu and the GCC5 toolchain):
- NOOPT: 187KB in FVMAIN, 12KB in FVMAIN_COMPACT
- DEBUG: 147KB in FVMAIN, 20KB in FVMAIN_COMPACT
- RELEASE: 123KB in FVMAIN, 17KB in FVMAIN_COMPACT
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Julien Grall <julien.grall@linaro.org>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=940
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Commit 411a373ed6 ("ArmPkg/TimerDxe: remove workaround for KVM timer
handling") removed the virtual timer handling quirk that cleared the
mask bit in the control register when enabling the timer, under the
assumption that only ancient KVM host implementations required it.
However, Julien reports that Xen also masks the timer interrupt in the
guest view of the timer control register, and therefore needs the same
quirk.
So let's reinstate it, but using a Xen specific implementation of the
timer support library, so that other virt platforms remain unchanged.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Julien Grall <julien.grall@arm.com>
Acked-by: Julien Grall <julien.grall@arm.com>
In spite of both ArmVirtQemu and ArmVirtQemuKernel formatting the variable
store template at build time, link NvVarStoreFormattedLib into
VariableRuntimeDxe via NULL class resolution on both platforms. This lets
us test the depexes implemented in the previous patches.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Steve Capper <steve.capper@linaro.org>
Cc: Supreeth Venkatesh <Supreeth.Venkatesh@arm.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Laszlo Ersek
Antoine Coeur
Star Zeng
Ard Biesheuvel
Fu Siyuan
Ruiyu Ni
chenc2
Gerd Hoffmann