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>
PlatformHasAcpiDtDxe consumes the DynamicHii PCD called
"gArmVirtTokenSpaceGuid.PcdForceNoAcpi". The PcdGetBool() library call
terminates in gRT->GetVariable(), in the MdeModulePkg/Universal/PCD/Dxe
driver. Put "gEfiVariableArchProtocolGuid" on PlatformHasAcpiDtDxe's DEPEX
so that we not attempt the call before the PCD driver can successfully
read non-volatile variables.
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>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Move the TryRunningQemuKernel() call back to its original place. This
improves the UEFI boot time for VMs that have "-kernel", many disks or
NICs, and no "bootindex" properties. A well-known example is
guestfish/libguestfs.
For more info on the TryRunningQemuKernel() location, see the following
commits: 23d04b58e2, a78c4836ea, 158990b941.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Xiang Zheng <xiang.zheng@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Richard W.M. Jones <rjones@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Among other things, the header file declares the ArchInitialize()
function, which is called from "PrePi.c", and implemented (dependent on
architecture) in "AArch64/ArchPrePi.c" and "Arm/ArchPrePi.c".
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Julien Grall <julien.grall@linaro.org>
Suggested-by: Michael Kinney <michael.d.kinney@intel.com>
Ref: http://mid.mail-archive.com/E92EE9817A31E24EB0585FDF735412F56327F7D3@ORSMSX113.amr.corp.intel.com
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
The header file declares TryRunningQemuKernel(), defined in "QemuKernel.c"
and called from "PlatformBm.c".
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Suggested-by: Michael Kinney <michael.d.kinney@intel.com>
Ref: http://mid.mail-archive.com/E92EE9817A31E24EB0585FDF735412F56327F7D3@ORSMSX113.amr.corp.intel.com
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Switch all users of ArmVirt.dsc.inc to the new DebugLib implementation
that was created especially for DXE_RUNTIME_DRIVER modules, ensuring
that DEBUG() calls do not touch the UART at runtime.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=800
Based on content from the following branch/commits:
https://github.com/Microsoft/MS_UEFI/tree/share/MsCapsuleSupport33bab4031aca516b1a612b9f111f2e
The BootGraphicsResourceTableDxe module uses the BmpSupportLib
and SafeIntLib to convert a GOP BLT buffer to a BMP graphics image.
Add library mappings for these new library classes.
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Bret Barkelew <Bret.Barkelew@microsoft.com>
ArmVirt.dsc.inc sets gEmbeddedTokenSpaceGuid.PcdCacheEnable,
which is unused and about to be deleted. Drop it.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
In order to allow the ArmVirtPkg platforms to be built using the
NOOPT target, add it explicitly to the BUILD_TARGETS define.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
ArmVirtXen is the only remaining consumer of ArmPlatformPkg's
PlatformIntelBdsLib implementation, which is tightly coupled to the
deprecated Intel BDS. So move ArmVirtXen to the generic BDS as well,
allowing us to get rid of PlatformIntelBdsLib entirely.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Julien Grall <julien.grall@linaro.org>
The TFTP command was converted from a NULL class library instance to a
dynamic shell command in commit 0961002352.
The ShellLib and FileHandleLib resolutions are moved from
[LibraryClasses.common.UEFI_APPLICATION] to [LibraryClasses.common]
because dynamic shell commands are implemented as DXE_DRIVER modules.
PcdShellLibAutoInitialize must be set to FALSE for both the shell app
itself and the dynamic shell command modules.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
[lersek@redhat.com: extend commit message]
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Build-tested-by: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Julien Grall <julien.grall@linaro.org>
The PrePi code we inherited from ArmPlatformPkg contains a rather
obscure optimization, where entry points of the PE/COFF and LZMA
handling routines are recorded in special HOBs, allowing DXE core
to call into that code directly rather than carry its own copy of
these libraries.
Given that no ArmVirtPkg platforms actually include the library
resolutions* that take advantage of these optimizations, let's not
bother with them, and remove the associated code.
* EmbeddedPkg/Library/LzmaHobCustomDecompressLib/LzmaHobCustomDecompressLib.inf
EmbeddedPkg/Library/DxeHobPeCoffLib/DxeHobPeCoffLib.inf
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
These libraries are no longer used, so remove them from the tree.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Move to the new ArmVirtMemInfoLib library to retrieve DRAM information
from the platform, so that we can phase out ArmPlatformLib going forward.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
The QemuVirtMemInfoLib ArmVirtMemInfoLib implementation created for
ArmVirtQemuKernel does exactly what we need for ArmVirtQemu, the only
difference being that the latter is PrePeiCore based, and so it uses
a different method to ensure that PcdSystemMemorySize is set when
ArmVirtGetMemoryMap() is called.
On ArmVirtQemu, we currently abuse the implied ordering guarantees
provided by ArmPlatformLib, by implementing this as follows:
ArmPlatformPkg/MemoryInitPei/MemoryInitPeim.inf [ArmVirtPkg/ArmVirtQemu.dsc]
InitializeMemory() [ArmPlatformPkg/MemoryInitPei/MemoryInitPeim.c]
ArmPlatformInitializeSystemMemory() [ArmVirtPkg/Library/ArmVirtPlatformLib/Virt.c]
//
// set PcdSystemMemorySize from the DT
//
MemoryPeim() [ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.c]
InitMmu() [ArmVirtPkg/Library/ArmVirtMemoryInitPeiLib/ArmVirtMemoryInitPeiLib.c]
ArmPlatformGetVirtualMemoryMap() [ArmVirtPkg/Library/ArmVirtPlatformLib/VirtMem.c]
//
// consume PcdSystemMemorySize
//
Given that we are trying to get rid of ArmPlatformLib, or at least remove
some of these API functions that are never used for their original purpose
by any platforms, we need to move the PCD assignment elsewhere.
So create a PEIM-only version of QemuVirtMemInfoLib especially for
ArmVirtQemu, and add the PCD assignment code to its constructor.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Create a new ArmVirtMemInfoLib for ArmVirtQemuKernel by cloning the
existing ArmPlatformGetVirtualMemoryMap () for this platform,
(ArmQemuRelocatablePlatformLib *not* ArmVirtPlatformLib), and cleaning
it up:
- remove support for uncached DRAM mappings
- replace EFI_D_xxx with DEBUG_xxx throughout
- use a temp variable to hold the top of the physical address space
- use AllocatePool () instead of AllocatePages (), given that we use
160 bytes only, and the memory is never freed.
In a future patch, we will add this library to the ordinary ArmVirtQemu
platform as well.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Clone the existing ArmPlatformGetVirtualMemoryMap () for this platform,
clean it up slightly (by using a static buffer rather than a heap
allocation, and removing the support for uncached DRAM mappings), and
turn it into a new ArmVirtMemInfoLib implementation.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Julien Grall <julien.grall@linaro.org>
As part of the effort to get rid of ArmPlatformLib (which incorporates
far too many duties in a single library), introduce ArmVirtMemInfoLib
which will be invoked by our ArmVirtMemoryInitPeiLib implementation to
get a description of the virtual address space. This will allow us to
remove this functionality from ArmPlatformLib later, or, in the case of
ArmVirtXen and ArmVirtQemuKernel, drop ArmPlatformLib altogether.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
QEMU/KVM has very little tolerance for using anything except writeback
cacheable mappings of DRAM, so let's remove the 'feature' that allows
us to select uncached mappings at build time.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
PrePi doesn't use anything defined by this package so drop the bogus
dependency.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
ArmPlatformStackLib has hooks into primary/secondary core PCDs and
other ArmPlatformLib related junk, so let's simply set the stack
pointer directly. This is trivial given that our PrePi is unicore
only.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Remove the pointless dependency on ArmPlatformLib: none of the code we
call from it actually does anything useful.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
ArmVirtQemuKernel and ArmVirtXen use essentially the same code to
retrieve DRAM information from the DT /memory node at early boot,
and invoke it via the ArmPlatformPeiBootAction () hook exposed by
ArmPlatformLib. Let's move this code into the PrePi implementation
these platforms share between them (and not with any other platforms)
so we can eliminate another dependency on the messy ArmPlatformLib.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
QEMU and KVM based ARM/AARCH64 virtual machines only enter UEFI on
a single core, so ArmPlatformIsPrimaryCore() always returns true.
And even if it didn't, our code does absolutely nothing meaningful
based on its return value, so don't bother calling it, and remove
another frivolous dependency on ArmPlatformLib.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Remove GetPlatformPpi() from PrePi: it is not used anywhere.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Instead of invoking the library constructors of some libraries by
hand, invoke the generated function ProcessLibraryConstructorList
in AutoGen.c so all constructors are executed.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Switch to the new, cleaned up PL011UartLib implementation so we will
be able to remove the old one.
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>
Now that the PL031 RTC driver library no longer depends on the ARM
platform specific ArmPlatformSysConfigLib, we no longer need to
implement ArmPlatform.h or have a resolution for that library.
This allows us to get rid of a rather dodgy practice of including
platform headers using compiler flags, which is a bad idea at various
levels.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
The VariableRuntimeDxe driver may use CopyMem () on NOR flash regions,
assuming such regions always have full memory semantics. Given that
those regions cannot be mapped as ordinary memory on ARM (due to the
fact that the NOR flash requires device semantics while in write mode)
this prevents us from using BaseMemoryLibOptDxe in VariableRuntimeDxe,
since it may use unaligned accesses and/or DC ZVA instructions, both
of which are incompatible with mappings using device semantics.
Note that there is no way we can work around this by changing the
mapping type between 'memory' and 'device' when switching from read to
write mode and back, because the runtime mapping is created by the OS,
and cannot be changed at will.
So let's just switch to the unaccelerated version of BaseMemoryLib which
does not have the same problem.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Shannon Zhao <zhaoshenglong@huawei.com>
"ArmVirtXen.fdf" pulls in none of the drivers from
"MdeModulePkg/Universal/Network", therefore building them in
"ArmVirtXen.dsc", via "ArmVirt.dsc.inc", is wasted work.
Move the "MdeModulePkg/Universal/Network" drivers from "ArmVirt.dsc.inc"
to "ArmVirtQemu.dsc" and "ArmVirtQemuKernel.dsc".
Place the new block between the "Bds" and "SCSI Bus and Disk Driver"
blocks, similarly to its context in "ArmVirtQemuFvMain.fdf.inc".
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>
The virt targets never use non-coherent DMA, so there is no point
in having a shared DmaLib library class resolution pointing to
ArmDmaLib. So drop it.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
A block of settings has been copied around ARM platforms for years.
These are consumed only by Ebl, and since none of the ArmVirtPkg
platforms use that, drop them.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
One of the reasons for introducing virtio-gpu support to OvmfPkg and
ArmVirtpkg was the fact that under KVM virtualization on ARM, the
legacy VGA cannot be used reliably. This is due to an implementation
detail of QEMU+KVM, which remaps cached host memory into the guest
address space as a framebuffer behind a PCI BAR. Given that the purpose
of a memory mapped framebuffer is its side effects, such BARs should
never be mapped cacheable in the guest, and the mismatched attributes
between host and guest result in a loss of coherency, visible as
corruption in the framebuffer image.
This issue does not occur under TCG emulation, nor did we expect it to
actually bring down the guest under KVM, and so it was deemed harmless
to keep support for the VGA device as well. However, as it turns out,
the fact that the framebuffer BAR is mapped using device semantics by
default may result in unalignment faults when we use the ordinary string
copy routines on the contents. In theory, we could work around this by
remapping the BAR as write combining, but it appears the generic PCI
bus driver does not actually implement this.
So let's remove the QemuVideoDxe driver altogether. This may result
in loss of functionality for use cases that rely on the framebuffer
to be directly addressable (such as EFIFB), but given that this never
worked reliably under KVM in the first place, let's not let that stop
us from dropping support for it.
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: Leif Lindholm <leif.lindholm@linaro.org>
With the SerialDxe change in commit 4cf3f37c87 ("MdeModulePkg SerialDxe:
Process timeout consistently in SerialRead", 2017-07-18), setting
EFI_SERIAL_INPUT_BUFFER_EMPTY in the "Control" output parameter, in the
GetControl() SerialPortLib function, is no longer a "small optimization".
Namely, due to the SerialDxe change, the GetOneKeyFromSerial() call in
TerminalDxe's TerminalConInTimerHandler() can take very long if the input
queue is empty, even if GetOneKeyFromSerial()'s return value causes the
loop to be exited right after, in the first iteration.
This issue causes a boot hang in ArmVirtQemu: with the input queue empty,
TerminalConInTimerHandler() takes so long to return that, by the time it
returns, there's another execution queued already (due to the associated
timer event being signaled meanwhile). The boot process is stuck in the
timer event handler.
Therefore even the first GetOneKeyFromSerial() iteration must be prevented
in TerminalConInTimerHandler() if the input queue is empty, and that
requires implementing GetControl() for real.
Implement the SetAttributes(), SetControl() and GetControl() APIs (of
SerialPortExtLib origin) in FdtPL011SerialPortLib with calls to matching
PL011UartLib functions. This follows the example of
"ArmPlatformPkg/Library/PL011SerialPortLib" and also matches Star's
original idea under [1].
The patch can be considered a continuation of commit ad7f6bc2e1
("ArmVirtPkg: Use SerialDxe in MdeModulePkg instead of EmbeddedPkg",
2015-11-26), based on the mailing list threads [1] [2] [3].
[1] http://mid.mail-archive.com/1447752930-32880-12-git-send-email-star.zeng@intel.com
[2] http://mid.mail-archive.com/1448243067-1880-12-git-send-email-star.zeng@intel.com
[3] http://mid.mail-archive.com/b748580c-cb51-32c9-acf9-780841ef15da@redhat.com
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Heyi Guo <guoheyi@huawei.com>
Cc: Star Zeng <star.zeng@intel.com>
Originally-suggested-by: Star Zeng <star.zeng@intel.com>
Reported-by: Brijesh Singh <brijesh.singh@amd.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=642
Add top level License.txt file with the BSD 2-Clause
License that is used by the majority of the EKD II open
source project content. Merge copyright statements
from the BSD 2-Clause License files in each package
directory and remove the duplication License.txt
file from package directories.
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Andrew Fish <afish@apple.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
https://bugzilla.tianocore.org/show_bug.cgi?id=629
Move Contributions.txt that contains the TianoCore
Contribution Agreement 1.0 to the root of the edk2
repository and remove the duplicate Contributions.txt
files from all packages.
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Andrew Fish <afish@apple.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Commit 7b1dc6c569 'ArmVirtPkg: switch to generic ResetSystemRuntimeDxe'
replaced all references in ArmVirtPkg to the deprecated ResetRuntimeDxe
from EmbeddedPkg with the well maintained generic alternative that lives
in MdeModulePkg.
However, as it turns out, the generic driver has a dependency on the
library class ReportStatusCodeLib, whose default resolution is an
implementation that is not safe for use at runtime, resulting in crashes
when trying to invoke it from the OS.
Since we have no use for status codes in any of the ArmVirtPkg
platforms, let's replace all resolutions with a common one to the NULL
implementation.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
For obscure reasons, ARM platforms use a different implementation of
the ResetSystem() runtime service call than other platforms. So let's
switch all ArmVirtPkg platforms to the generic version instead.
Given that all platforms use an implementation of EfiResetSystemLib [as
consumed by the ResetRuntimeDxe in EmbeddedPkg that we are replacing]
which is unlikely to be depended upon by out of tree platforms, let's
simply modify this library into an implementation of ResetSystemLib
instead [which is what the generic driver in MdeModulePkg consumes]
This does mean we need to update all clients at the same time, which
is why all changes are part of the same patch.
As before, warm reset and platform specific reset are mapped onto
cold reset (which is the only thing PSCI implements, at least the
version we depend on). The new library function EnterS3WithImmediateWake()
is left unimplemented, as permitted by the ResetSystemLib library class.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Remove the functions now provided by TimeBaseLib from
PL031RealTimeClockLib. Add TimeBaseLib resolution to ArmVirtPkg
in same commit to prevent breakage.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Include XenPlatformHasAcpiDtDxe and PlatformHasAcpiDtDxe in the 32-bit
builds too.
Please see https://bugzilla.tianocore.org/show_bug.cgi?id=524
why it is needed. With this patch my arm uefi VM boots.
Fixes: 3a2c1548fe
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Nerijus Baliūnas <nerijus@users.sourceforge.net>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
[lersek@redhat.com: move long subj to commit msg body, add short subj]
[lersek@redhat.com: add Fixes reference]
[lersek@redhat.com: keep ACPI DXE modules grouped in QEMU DSCs]
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Remove the library class resolution for ARM's BdsLib: no included
module actually depends on it, and it will be removed shortly.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Given the agreement on the edk2-devel regarding the fact that the
notion whether or not a 'platform has ACPI' is a universal one, move
the PlatformHasAcpi GUID to MdeModulePkg.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: "Zeng, Star" <star.zeng@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
The relocatable build of ArmVirtQemuKernel is designed to be executed
from RAM, and contains some scratch memory at the start of the image
to use as a stack very early on, and to preserve the DTB image received
from QEMU while it discovers and initializes memory.
It turns out that 8 KB is a bit on the small side here, especially when
executing with secure world emulation enabled, in which case there are
additional nodes present.
So increase the slack space to 32 KB.
While at it, remove a stale Xen reference that was copy/pasted when this
file was created.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
In some cases, (e.g., when running QEMU with TrustZone emulation), the
DT may contain DT nodes whose status is set to 'secure'. Similarly, the
status may be set to 'disabled' if the consumer of the DT image is
expected to treat it as if it weren't there.
So check whether a 'status' property is present, and if so, ignore the
node if the status is not 'okay'.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
In some cases, (e.g., when running QEMU with TrustZone emulation), the
DT may contain DT nodes whose status is set to 'secure'. Similarly, the
status may be set to 'disabled' if the consumer of the DT image is
expected to treat it as if it weren't there.
So check whether a 'status' property is present, and if so, ignore the
node if the status is not 'okay'.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
In some cases, (e.g., when running QEMU with TrustZone emulation), the
DT may contain memory nodes whose status is set to 'secure'. Similarly,
the status may be set to 'disabled' if the consumer of the DT image is
expected to treat it as if it weren't there.
So check whether a 'status' property is present, and if so, ignore the
node if the status is not 'okay'.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
In general, we should not present two separate (and inevitably different)
hardware descriptions to the OS, in the form of ACPI tables and a device
tree blob. For this reason, we recently added the logic to ArmVirtQemu to
only expose the ACPI 2.0 entry point if no DT binary is being passed, and
vice versa.
However, this is arguably a regression for those who relied on DT
descriptions being available, even if the former behavior can be
restored by passing the -no-acpi switch to QEMU.
So allow a secret handshake with the UEFI Shell, to set a variable that
will result in ACPI to be disabled on subsequent boots even if -no-acpi
was not passed on the QEMU command line.
setvar -nv -bs -guid 50bea1e5-a2c5-46e9-9b3a-59596516b00a ForceNoAcpi =01
To delete the variable and revert to the old situation, simply omit the
value after the =
setvar -nv -bs -guid 50bea1e5-a2c5-46e9-9b3a-59596516b00a ForceNoAcpi =
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Marc Zyngier <marc.zyngier@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
ArmCpuLib is never used anywhere, and is about to be removed. So remove
any references from our .DSC files.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
The build flag and the FeaturePCD have no effect any longer, remove them.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
This will let QEMU's "-no-acpi" option exclusively expose DT vs. ACPI to
the guest. Showing both is never needed (it is actually detrimental to the
adoption of standards, such as SBSA / SBBR).
* Without "-no-acpi", the firmware logs (from PlatformHasAcpiDtDxe)
> Found FwCfg @ 0x9020008/0x9020000
> Found FwCfg DMA @ 0x9020010
> InstallProtocolInterface: [EdkiiPlatformHasAcpi] 0
plus the usual messages. Later the guest kernel logs
> [ 0.000000] efi: SMBIOS 3.0=0x13bdb0000 ACPI 2.0=0x138440000
> MEMATTR=0x13a675018
before it lists the ACPI tables one by one.
In addition, in the guest, the "/sys/firmware/devicetree/*" shell pattern
matches no files, while the "/sys/firmware/acpi/tables/*" pattern matches
the ACPI tables.
* With "-no-acpi", the firmware logs:
> PlatformHasAcpiDtDxe | Found FwCfg @ 0x9020008/0x9020000
> PlatformHasAcpiDtDxe | Found FwCfg DMA @ 0x9020010
> PlatformHasAcpiDtDxe | InstallProtocolInterface:
> PlatformHasAcpiDtDxe | [EdkiiPlatformHasDeviceTree] 0
> FdtClientDxe | OnPlatformHasDeviceTree: exposing DTB @
> FdtClientDxe | 0x13FFBF000 to OS
> ...
> DXE_CORE | Driver [AcpiTableDxe] was discovered but not
> DXE_CORE | loaded!!
> DXE_CORE | Driver [QemuFwCfgAcpiPlatform] was discovered but
> DXE_CORE | not loaded!!
> ...
> RamDiskDxe | RamDiskAcpiCheck: Cannot locate the EFI ACPI
> RamDiskDxe | Table Protocol, unable to publish RAM disks to
> RamDiskDxe | NFIT.
(BootGraphicsResourceTableDxe's ReadyToBoot callback --
InstallBootGraphicsResourceTable() -- handles the lack of
EFI_ACPI_TABLE_PROTOCOL silently.) Later the guest kernel logs
> [ 0.000000] efi: SMBIOS 3.0=0x13bdb0000 MEMATTR=0x138caa018
In addition, in the guest, the "/sys/firmware/devicetree/*" shell pattern
matches the directory "/sys/firmware/devicetree/base", which contains a
large number of DT nodes, while the "/sys/firmware/acpi/tables/*" pattern
matches no files.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1430262
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Replace the dependency on PcdPureAcpiBoot with a Platform Has Device Tree
notification callback. Move the sysconfig table installation from the
entry point function to the callback.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
In this patch, the ACPI protocol / driver chain is enabled dynamically,
when appropriate. This is being done in one larger patch, because
ArmVirt.dsc.inc, where AcpiTableDxe is built, is used by all the platform
DSCs.
No change in behavior should be observable after this patch on any
ArmVirtPkg platform.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
This driver produces the EDKII Platform Has ACPI and Platform Has Device
Tree protocols, exactly matching the current ACPI / DT exposure on Xen,
according to ARM vs. AARCH64. At this point it differs from the QEMU
driver PlatformHasAcpiDtDxe in that this one always installs the DT.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
This driver produces the EDKII Platform Has ACPI and Platform Has Device
Tree protocols, exactly matching the current ACPI / DT exposure on QEMU,
according to ARM vs. AARCH64, and (in the latter case) to PcdPureAcpiBoot.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
This reverts commit 18f6d4df9e.
We realized that DXE drivers that are independent of AcpiPlatformDxe (that
is, independent of QEMU's ACPI generation), such as RamDiskDxe and
BootGraphicsResourceTableDxe, may produce and/or manipulate ACPI tables,
at driver dispatch or even at Ready To Boot.
This makes it unsafe for us to check for ACPI presence in the UEFI system
config table in a Ready To Boot callback, in order to decide about
exposing the DT.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
This reverts commit 78c41ff519.
We realized that DXE drivers that are independent of AcpiPlatformDxe (that
is, independent of QEMU's ACPI generation), such as RamDiskDxe and
BootGraphicsResourceTableDxe, may produce and/or manipulate ACPI tables,
at driver dispatch or even at Ready To Boot.
This makes it unsafe for us to check for ACPI presence in the UEFI system
config table in a Ready To Boot callback, in order to decide about
exposing the DT.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Currently, the file GUID reference of the UEFI Shell app is indirected
via the PCD gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdShellFile,
which is set to a fixed value for our platforms.
So instead, use the new symbolic GUID added for this purpose, and drop
the reference to this PCD, and to the IntelFrameworkModulePkg package
entirely.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Instead of looking at the PCD gArmTokenSpaceGuid.PcdSystemMemoryBase
to decide which DT node covers the memory we are already using, query
the GCD memory space map, which is the authoritative source for this
kind of information
This fixes a problem observed by Michael on platforms where this PCD
is of the 'Patchable' type, which means updates to its value do not
propagate to other modules.
Reported-by: Michael Zimmermann <sigmaepsilon92@gmail.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Instead of invoking gDS->SetMemorySpaceAttributes to set the EFI_MEMORY_XP
attribute on newly added regions, which is guaranteed to fail if the same
attribute was not declared as a capability of the region when it as added,
invoke the CPU arch protocol directly to set the EFI_MEMORY_XP attribute
if our memory protection policy demands it.
Reported-by: Michael Zimmermann <sigmaepsilon92@gmail.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
At this point we're ready to retire QemuFwCfgS3Enabled() from the
QemuFwCfgLib class, together with its implementations in:
- ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c
- OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c
Extend all modules that call the function with a new QemuFwCfgS3Lib class
dependency. Thanks to the previously added library class, instances, and
class resolutions, we can do this switch now as tightly as possible.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=394
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
QemuFwCfgS3Enabled() in "ArmVirtPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c"
returns constant FALSE.
The same implementation is now available factored-out in
"OvmfPkg/Library/QemuFwCfgS3Lib/QemuFwCfgS3Base.c".
Resolve QemuFwCfgS3Lib to BaseQemuFwCfgS3LibNull.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=394
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Instead of having a build time switch to prevent the FDT configuration
table from being installed, make this behavior dependent on whether we
are passing ACPI tables to the OS. This is done by looking for the
ACPI 2.0 configuration table, and only installing the FDT one if the
ACPI one cannot be found.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Defer FDT configuration table installation until ReadyToBoot is signaled.
This allows any driver to make modifications in the mean time, and will
also allow us to defer the decision of whether to install it in the first
place to later on in the boot.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Disable the PL031 RTC DT node unconditionally rather than only when
the DT will be exposed to the OS. This allows us to defer the decision
whether to expose it to the OS to a later time without creating an
additional dependency on the FDT client code by the RTC driver.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Include DXE_CORE in the BuildOptions that are set to force 4 KB section
alignment for PE/COFF images in order to allow them to be mapped with
strict memory permissions.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Now that ARM has grown support for managing memory permissions in
ArmMmuLib, we can enable the non-executable DXE stack for all virt
platforms. Note that this includes the AARCH64 Xen platform as well.
Note that this is not [entirely] redundant: the non-executable stack
is configured before DxeCore is invoked. The image and memory protection
features configured during DXE only take affect when the CPU arch
protocol implementation is registered.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Like for AARCH64, enable PE/COFF image and NX memory protection for all
32-bit ARM virt platforms.
Note that this does not [yet] protect EfiLoaderData regions, due to
compatibility issues with GRUB.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
This sets the recently introduced PCD PcdDxeNxMemoryProtectionPolicy to
a value that protects all memory regions except code regions against
inadvertent execution.
Note that this does not [yet] protect EfiLoaderData regions, due to
compatibility issues with shim and GRUB.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
Recent changes to ShellPkg require a resolution for UefiBootManagerLib
for all platforms in ArmVirtPkg. So move the resolution to the shared
include ArmVirt.dsc.inc.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Using DxeServices::SetMemorySpaceAttributes to set cacheability
attributes has the side effect of stripping permission attributes,
given that those are bits in the same bitfield, and so setting the
Attributes argument to EFI_MEMORY_WB implies not setting EFI_MEMORY_XP
or EFI_MEMORY_RO attributes.
In fact, the situation is even worse, given that the descriptor returned
by DxeServices::GetMemorySpaceDescriptor does not reflect the permission
attributes that may have been set by the preceding call to
DxeServices::AddMemorySpace if PcdDxeNxMemoryProtectionPolicy has been
configured to map EfiConventionalMemory with non-executable permissions.
Note that this applies equally to the non-executable stack and to PE/COFF
sections that may have been mapped with R-X or RW- permissions. This is
due to the ambiguity in the meaning of the EFI_MEMORY_RO/EFI_MEMORY_XP
attributes when used in the GCD memory map, i.e., between signifying
that an underlying RAM region has the controls to be configured as
read-only or non-executable, and signifying that the contents of a
certain UEFI memory region allow them to be mapped with certain
restricted permissions.
So let's check the policy in PcdDxeNxMemoryProtectionPolicy directly,
and set the EFI_MEMORY_XP attribute if appropriate for
EfiConventionalMemory regions.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
This removes the PCD PcdArmUncachedMemoryMask from ArmPkg, along with
any remaining references to it in various platform .DSC files. It is
no longer used now that we removed the virtual uncached pages protocol
and the associated DebugUncachedMemoryAllocationLib library instance.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
The only observeable effect of having PcdPerformanceLibraryPropertyMask
set to 1 is that a EfiReservedMemory region of 4 pages is allocated right
below the 4 GB mark. This region is out of bounds for the OS, which means
it is not even allowed to map it, to avoid speculative loads from it.
On Linux, this may prevent the kernel from using a 1 GB block mapping for
this region, and instead it has to carve up the block as follows:
0xffffffff80000000-0xffffffffbe000000 992M PMD CON BLK
0xffffffffbe000000-0xffffffffbfe00000 30M PMD BLK
0xffffffffbfe00000-0xffffffffbfff0000 1984K PTE CON
0xffffffffbfff0000-0xffffffffbfffc000 48K PTE
where it would otherwise use a single 1 GB mapping (*), i.e.,
0xffffffff80000000-0xffffffffc0000000 1G PGD
To clarify, the latter is a single 8 byte entry in the top level page
table, whereas in the former case, we have two additional levels of
paging, requiring two extra 4 KB pages (on a 4 KB pagesize kernel).
The real cost, however, is the TLB footprint, which goes up from a
single entry to a number between 90 and 1020, depending on whether
contiguous hints are honoured by the hardware.
So let's remove PcdPerformanceLibraryPropertyMask until we find a reason
why we need it.
(*) provided that no other allocations were deliberately located right
below the 4 GB mark, and that we are running with more than 3 GB of
memory, in which case most allocations will be over 4 GB, given EDK2's
default top-down allocation policy.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
The OpensslLibCrypto library instance (which does not contain libssl
functions) is sufficient for the Secure Boot feature. It would not be
sufficient for HTTPS booting (which requires TLS), but in ArmVirtPkg, we
don't even enable plaintext HTTP booting for the time being.
Ease security analysis by excluding libssl functionality from the
OpensslLib instance we use.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Tomas Hoger <thoger@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Enable the new DXE image protection for all image, i.e., FV images but
also external images that originate from disk or the network, such as
OS loaders.
This complements work that is underway on the arm64/Linux kernel side,
to emit the OS loader with 4 KB section alignment, and a suitable split
between code and data.
http://marc.info/?l=linux-arm-kernel&m=148655557227819
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
The debug implementation of the UncachedMemoryAllocationLib library
class relies on the creation of an uncached alias of a memory range,
while keeping the original cached mapping, but with read-only attributes
to trap inadvertent write accesses.
This is not a terribly good idea, given that the ARM architecture does
not allow mismatched attributes, and so creating them deliberately is
not something we should encourage by doing it in reference code.
So remove the library, and replace all references to it with a reference
to the non-debug version (unless the platform does not require a resolution
for it in the first place, in which case all UncachedMemoryAllocationLib
references can be removed altogether).
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
We are now sufficiently equipped to implement the new QemuFwCfgSkipBytes()
API.
The previous patch and this one enable ArmVirtPkg/QemuFwCfgLib to
overwrite part of a writeable fw_cfg file, which will be particularly
useful for the upcoming QEMU_LOADER_WRITE_POINTER command in
OvmfPkg/AcpiPlatformDxe.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=359
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
We use the "InternalQemuFwCfgReadBytes" static function pointer to
dispatch the reading of fw_cfg bytes between MMIO and DMA. This pointer is
initialized to MMIO, and we set it to DMA in the library constructor if
DMA is available.
Unlike the above, we write fw_cfg bytes only with MMIO at the moment.
Extend the write functionality so that it follows the read pattern:
- introduce the new function typedef WRITE_BYTES_FUNCTION,
- extract the current (MMIO-only) write internals from
QemuFwCfgWriteBytes() to MmioWriteBytes(),
- provide a DMA-based implementation in DmaWriteBytes() -- a thin wrapper
around DmaTransferBytes(),
- set the new static function pointer "InternalQemuFwCfgWriteBytes"
according to the DMA feature provided by QEMU,
- In QemuFwCfgWriteBytes(), call the best available method through
"InternalQemuFwCfgWriteBytes".
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=359
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
The DmaReadBytes() function that we currently use only for reading --
through the InternalQemuFwCfgReadBytes function pointer, in case the DMA
interface is available -- is suitable with minimal changes for two more
operations provided by the DMA interface, WRITE and SKIP. Expose the
Control parameter in the function prototype, rename the function to
DmaTransferBytes(), and rebase DmaReadBytes() to it.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=359
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
While debugging OS for ACPI BGRT support (especially on VMs),
it is very useful to have the EFI firmware to export the
ACPI BGRT table.
This patch tries to add this support in ArmVirtPkg.
Cc: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
InternalQemuFwCfgIsAvailable() is an API that is incorrectly exposed by
the "OvmfPkg/Include/Library/QemuFwCfgLib.h" library class header; the API
is meant to be used internally to library instances (if it's needed at
all). ArmVirtPkg's instance has no use for it actually, so simplify the
code and remove the function definition.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Laszlo Ersek
chenc2
Gerd Hoffmann
Ard Biesheuvel
Michael D Kinney
Leif Lindholm
Ruiyu Ni
Star Zeng
Paulo Alcantara
Nerijus Baliūnas
Bhupesh Sharma