Commit Graph

123 Commits

Author SHA1 Message Date
Ard Biesheuvel f52b30e73d ArmVirtPkg/PlatformPeiLib: add dummy assignment to work around older GCC
Older GCC (<= 4.9) fail to infer that Parent is never used unless it
has been assigned before, and may throw an error like

  /work/git/edk2/ArmVirtPkg/Library/PlatformPeiLib/PlatformPeiLib.c:
      In function ‘PlatformPeim’:
  /work/git/edk2/ArmVirtPkg/Library/PlatformPeiLib/PlatformPeiLib.c:132:24:
      error: ‘Parent’ may be used uninitialized in this function
                                                [-Werror=maybe-uninitialized]
             RangesProp = fdt_getprop (Base, Parent, "ranges", &RangesLen);

Set Parent to 0 at the start of the sequence to work around this.

Link: https://bugzilla.tianocore.org/show_bug.cgi?id=2601
Fixes: 82662a3b5f ("ArmVirtPkg/PlatformPeiLib: discover the TPM base ...")
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2020-03-26 08:09:53 +00:00
Leif Lindholm 01ce872739 ArmVirtPkg: fix ASSERT in ArmVirtGicArchLib with virtualization=on
ArmVirtGicArchLib was originally implemented before virtualization
emulation was implemented in QEMU, and the GICv2 model implemented only
the physical copy of control registers.

Enabling virtualization emulation to QEMU adds also the virtual copy,
doubling the RegSize returned by FindCompatibleNodeReg () in
ArmVirtGicArchLibConstructor (). This triggered an ASSERT when running
QEMU with -M virt,virtualization=on. Address this by testing for both
possible valid values of RegSize.

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2588

Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Leif Lindholm <leif@nuviainc.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2020-03-17 15:06:11 +00:00
Ard Biesheuvel 364e0b4cda ArmVirtPkg/PlatformBootManagerLib: switch to separate QEMU loader
Drop the QEMU loader file system implementation inside this library,
and switch to the separate QemuLoadImageLib library and the associated
driver to expose the kernel and initrd passed via the QEMU command line.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2566
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2020-03-05 19:45:05 +00:00
Laszlo Ersek 7288ff4095 ArmVirtPkg/PlatformBootManagerLib: sync Timeout with PcdPlatformBootTimeOut
Set the Timeout global variable to the same value as
PcdPlatformBootTimeOut. This way the "setvar" command in the UEFI shell,
and the "efibootmgr" command in a Linux guest, can report the front page
timeout that was requested on the QEMU command line (see
GetFrontPageTimeoutFromQemu()).

A DEBUG_VERBOSE message is logged on success too, for our QE team's sake.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200304094413.19462-3-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
2020-03-05 08:55:21 +00:00
Ard Biesheuvel 39c503f155 ArmVirtPkg: implement ArmVirtPsciResetSystemPeiLib
Implement a ArmVirtPkg specific version of the PSCI ResetSystemLib that
is usable in the PEI phase, as the existing one relies on the FDT client
protocol, making it unsuitable.

Note that accessing the device tree passed by QEMU via its initial base
address is guaranteed to be safe at any time during the PEI phase, so we
can defer discovery of the PSCI method until the time the reset library
is actually invoked (which is rarely)

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2560
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
2020-03-04 08:48:09 +00:00
Ard Biesheuvel 82662a3b5f ArmVirtPkg/PlatformPeiLib: discover the TPM base address from the DT
Introduce a boolean PCD that tells us whether TPM support is enabled
in the build, and if it is, record the TPM base address in the existing
routine that traverses the device tree in the platform PEIM.

If a TPM is found, install the gOvmfTpmDiscoveredPpiGuid signalling PPI
that will unlock the dispatch of OvmfPkg's Tcg2ConfigPei. If TPM2
support is enabled in the build but no TPM2 device is found, install the
gPeiTpmInitializationDonePpiGuid PPI, which is normally installed by
Tcg2ConfigPei if no TPM2 is found, but in our case Tcg2ConfigPei will
never run so let's do it here instead.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2560
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
2020-03-04 08:48:09 +00:00
Ard Biesheuvel fdb3f06b82 ArmVirtPkg/PlatformPeiLib: make PcdLib dependency explicit in .INF
We currently include PcdLib.h in PlatformPeiLib, without declaring
this dependency in its .INF description. Since all the PCDs we use
resolve to fixed type in practice, this does not really matter at
the moment, but since we will be adding dynamic PCD references in
a subsequent patch, let's make the PcdLib dependency explicit, so
that its dispatch is guaranteed to be ordered correctly with respect
to the provider of the dynamic PCD PPI.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2560
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2020-03-04 08:48:09 +00:00
Ard Biesheuvel 9d1c9d0379 ArmVirtPkg: remove EnterS3WithImmediateWake () from ResetSystemLib
EnterS3WithImmediateWake () no longer has any callers, so remove it
from ResetSystemLib.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2020-01-10 07:00:51 +00:00
Pete Batard 23ab8df01a ArmVirtPkg/PlatformBootManagerLib: Don't update progress if Pcd is 0
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2266

Similar to what we now do for OVMF, we need to consider the possibility
that PlatformBootManagerWaitCallback () may be called with a
PcdPlatformBootTimeOut that was set to zero, in which case the call should
simply return.

We also change the initial timeout variable name to make the code explicit.

Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Message-Id: <20191014150311.16740-3-pete@akeo.ie>
2019-10-16 18:27:42 +02:00
Laszlo Ersek ae9f12058d ArmVirtPkg/PlatformBootManagerLib: unload image on EFI_SECURITY_VIOLATION
The LoadImage() boot service is a bit unusual in that it allocates
resources in a particular failure case; namely, it produces a valid
"ImageHandle" when it returns EFI_SECURITY_VIOLATION. This is supposed to
happen e.g. when Secure Boot verification fails for the image, but the
platform policy for the particular image origin (such as "fixed media" or
"removable media") is DEFER_EXECUTE_ON_SECURITY_VIOLATION. The return code
allows platform logic to selectively override the verification failure,
and launch the image nonetheless.

ArmVirtPkg/PlatformBootManagerLib does not override EFI_SECURITY_VIOLATION
for the kernel image loaded from fw_cfg -- any LoadImage() error is
considered fatal. When we simply treat EFI_SECURITY_VIOLATION like any
other LoadImage() error, we leak the resources associated with
"KernelImageHandle". From a resource usage perspective,
EFI_SECURITY_VIOLATION must be considered "success", and rolled back.

Implement this rollback, without breaking the proper "nesting" of error
handling jumps and labels.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1992
Fixes: 23d04b58e2
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
2019-09-05 19:22:43 +02:00
Anthony PERARD 4870639f55 OvmfPkg: Move XenRealTimeClockLib from ArmVirtPkg
Move XenRealTimeClockLib from ArmVirtPkg to OvmfPkg so it can be used
from the OvmfPkg by the following patch, "OvmfPkg/OvmfXen: use
RealTimeClockRuntimeDxe from EmbeddedPkg"

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20190813113119.14804-35-anthony.perard@citrix.com>
2019-08-21 18:03:50 +02:00
Anthony PERARD 4ff31c083e ArmVirtPkg/PlatformBootManagerLib: Use EDKII_SERIAL_PORT_LIB_VENDOR_GUID
SERIAL_DXE_FILE_GUID is now defined in MdeModulePkg as
EDKII_SERIAL_PORT_LIB_VENDOR_GUID, simply use it.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Message-Id: <20190606131459.1464-3-anthony.perard@citrix.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
[lersek@redhat.com: drop "from MdeModulePkg" from the subject]
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
2019-06-14 21:26:35 +02:00
Zhichao Gao d943e5ad3b ArmVirtPkg/ArmVirtPsciResetSystemLib: Add a new API ResetSystem
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1460

Add a new API ResetSystem to this ResetSystemLib instance.
It only adds the basic functions from ResetSystemRuntimeDxe.
Lacking of this interface may cause link error, if some drivers
use this new API and link to this library instance.
Notes:
This library API only provide a basic function of reset. Full
function should use the instance in the MdeModulePkg and make
sure the depex driver is dispatched.

Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2019-04-28 09:40:20 +08:00
Michael D Kinney 9792fb0e65 ArmVirtPkg: Replace BSD License with BSD+Patent License
https://bugzilla.tianocore.org/show_bug.cgi?id=1373

Replace BSD 2-Clause License with BSD+Patent License.  This change is
based on the following emails:

  https://lists.01.org/pipermail/edk2-devel/2019-February/036260.html
  https://lists.01.org/pipermail/edk2-devel/2018-October/030385.html

RFCs with detailed process for the license change:

  V3: https://lists.01.org/pipermail/edk2-devel/2019-March/038116.html
  V2: https://lists.01.org/pipermail/edk2-devel/2019-March/037669.html
  V1: https://lists.01.org/pipermail/edk2-devel/2019-March/037500.html

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>
2019-04-09 09:10:21 -07:00
Laszlo Ersek 1797f32e0a ArmVirtPkg/PlatformBootManagerLib: display boot option loading/starting
Consume PlatformBmPrintScLib, added earlier in this series. When
BdsDxe+UefiBootManagerLib report LoadImage() / StartImage() preparations
and return statuses, print the reports to the UEFI console. This allows
end-users better visibility into the boot process.

Cc: Ard Biesheuvel <ard.biesheuvel@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>
2019-02-25 11:51:37 +01:00
Antoine Coeur 7a90895306 ArmVirtPkg: Fix various typos
Fix various typos in ArmVirtPkg.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Coeur <coeur@gmx.fr>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
2019-02-07 14:31:16 +01:00
Ard Biesheuvel 4a1500db2b ArmVirtPkg/MemoryInitPeiLib: split memory HOB based on MAX_ALLOC_ADDRESS
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>
2018-12-20 11:02:40 +01:00
Ard Biesheuvel 51bb05c795 ArmVirtPkg/QemuVirtMemInfoLib: trim the MMIO region mapping
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>
2018-12-03 15:56:39 +01:00
Ard Biesheuvel 5e27deed43 ArmVirtPkg/NorFlashQemuLib: disregard our primary FV
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>
2018-12-03 15:56:10 +01:00
Ard Biesheuvel 2f9b248af8 ArmVirtPkg/XenVirtMemInfoLib: refactor reading of the PA space size
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>
2018-11-29 18:54:36 +01:00
Ard Biesheuvel 364eed8479 ArmVirtPkg/QemuVirtMemInfoLib: remove 1:1 mapping of top of PA range
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>
2018-11-29 18:52:54 +01:00
Ard Biesheuvel 66e06a72bf ArmVirtPkg/FdtPciHostBridgeLib: map ECAM and I/O spaces in GCD memory map
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>
2018-11-29 18:52:22 +01:00
Ard Biesheuvel 72e514c907 ArmVirtPkg/NorFlashQemuLib: discover NOR flash banks dynamically
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>
2018-11-26 17:57:41 +01:00
Ruiyu Ni 8d1b281af3 ArmVirtPkg/PlatformBDS: Implement PlatformBootManagerUnableToBoot
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Julien Grall <julien.grall@linaro.org>
2018-07-27 15:47:55 +08:00
chenc2 e9421e0ae4 ArmVirtPkg: Removing ipf which is no longer supported from edk2.
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>
2018-06-29 16:19:36 +08:00
Ard Biesheuvel 97399f2d6f ArmVirtPkg/PlatformBootManagerLib: add missing report status code call
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>
2018-05-29 10:43:42 +02:00
Laszlo Ersek c4add6b6e9 ArmVirtPkg/PlatformBootManagerLib: connect Virtio RNG devices again
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>
2018-05-18 13:51:04 +02:00
Ard Biesheuvel ef42ef7e6d ArmVirtPkg: reinstate timer unmask quirk for Xen
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>
2018-04-26 08:31:40 +02:00
Laszlo Ersek 34711bf198 ArmVirtPkg/PlatformBootManagerLib: return to "-kernel before boot devices"
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>
2018-03-16 19:57:32 +01:00
Laszlo Ersek ff1d0fbfba ArmVirtPkg/PlatformBootManagerLib: minimize the set of connected devices
Prefer ConnectDevicesFromQemu() to EfiBootManagerConnectAll().

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Shannon Zhao <zhaoshenglong@huawei.com>
Cc: Xiang Zheng <xiang.zheng@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> # ArmVirtQemu
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Xiang Zheng <xiang.zheng@linaro.org>
2018-03-14 11:24:30 +01:00
Laszlo Ersek 9c4ed79c94 ArmVirtPkg/PlatformBootManagerLib: list "PlatformBm.h" in INF file
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>
2018-03-13 14:29:12 +01:00
Ard Biesheuvel 3d544c564b ArmVirtPkg: remove ArmPlatformLib implementations
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>
2017-11-23 16:53:29 +00:00
Ard Biesheuvel 39da48614a ArmVirtPkg/ArmVirtMemoryInitPeiLib: move to ArmVirtMemInfoLib
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>
2017-11-23 16:53:29 +00:00
Ard Biesheuvel 048651260b ArmVirtPkg: create QemuVirtMemInfoLib version for ArmVirtQemu
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>
2017-11-23 16:53:26 +00:00
Ard Biesheuvel 3043603401 ArmVirtPkg/ArmVirtQemu: add ArmVirtMemInfoLib implementation
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>
2017-11-23 16:52:55 +00:00
Ard Biesheuvel 496cf19ac2 ArmVirtPkg/ArmVirtXen: add ArmVirtMemInfoLib implementation
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>
2017-11-23 16:05:28 +00:00
Ard Biesheuvel dc1235c148 ArmVirtPkg/ArmVirtPlatformLib: remove support for uncached mappings
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>
2017-11-23 16:05:04 +00:00
Ard Biesheuvel 1195b85787 ArmVirtPkg: switch to new PL011UartLib implementation
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>
2017-11-17 10:02:36 +00:00
Ard Biesheuvel f311e5d8b5 ArmVirtPkg: remove ArmPlatformSysConfigLib dependency
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>
2017-11-16 16:22:55 +00:00
Star Zeng 234dbceff1 ArmVirtPkg ArmVirtDxeHobLib: Implement BuildFv3Hob
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2017-10-10 20:54:48 +08:00
Laszlo Ersek 5f0f5e90ae ArmVirtPkg/FdtPL011SerialPortLib: call PL011UartLib in all SerialPortLib APIs
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>
2017-08-17 14:13:23 +02:00
Ard Biesheuvel 7b1dc6c569 ArmVirtPkg: switch to generic ResetSystemRuntimeDxe
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>
2017-07-03 18:49:56 +01:00
Ard Biesheuvel 83ae7589b0 ArmVirtPkg/PlatformPeiLib: honor DT node 'status' property
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>
2017-04-04 15:25:19 +01:00
Ard Biesheuvel b1f3e48ed8 ArmVirtPkg/FdtPL011SerialPortLib: honor DT node 'status' property
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>
2017-04-04 15:25:16 +01:00
Ard Biesheuvel c81c2c0fc4 ArmVirtPkg/ArmVirtQemu: refer to Shell app via its declared GUID
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>
2017-03-22 15:34:59 +00:00
Laszlo Ersek 687f7521ea ArmVirtPkg, OvmfPkg: retire QemuFwCfgS3Enabled() from QemuFwCfgLib
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>
2017-03-14 21:49:16 +01:00
Ard Biesheuvel d5256ba932 ArmVirtPkg/ArmVirtPL031FdtClientLib: unconditionally disable DT node
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>
2017-03-09 18:37:04 +01:00
Laszlo Ersek 7fcb735412 ArmVirtPkg/QemuFwCfgLib: implement QemuFwCfgSkipBytes() API
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>
2017-01-31 00:14:41 +01:00
Laszlo Ersek e8ae381f60 ArmVirtPkg/QemuFwCfgLib: use DMA for QemuFwCfgWriteBytes() if available
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>
2017-01-31 00:14:39 +01:00
Laszlo Ersek 4175356fb4 ArmVirtPkg/QemuFwCfgLib: extract generic DmaTransferBytes() function
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>
2017-01-31 00:14:37 +01:00