Commit Graph

453 Commits

Author SHA1 Message Date
Laszlo Ersek a3e25cc8a1 OvmfPkg/X86QemuLoadImageLib: fix "unused variable" error in X64 DXE builds
When the MDE_CPU_IA32 macro is not defined, there is no access to the
"KernelImageHandle" local variable in QemuStartKernelImage(). This breaks
the OvmfPkgIa32X64 and OvmfPkgX64 platform builds, at least with gcc-8.

Move the local variable to the inner scope, where declaration and usage
are inseparable.

(Note that such inner-scope declarations are frowned upon in the wider
edk2 codebase, but we use them liberally in ArmVirtPkg and OvmfPkg anyway,
because they help us reason about variable lifetime and visibility.)

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Fixes: 7c47d89003
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2572
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2020-03-08 19:45:39 +00:00
Ard Biesheuvel 859b55443a OvmfPkg/PlatformBootManagerLib: switch to QemuLoadImageLib
Replace the open coded sequence to load Linux on x86 with a short and
generic sequence invoking QemuLoadImageLib, which can be provided by
a generic version that only supports the LoadImage and StartImage boot
services, and one that incorporates the entire legacy loading sequence
as well.

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
Ard Biesheuvel 7c47d89003 OvmfPkg: implement QEMU loader library for X86 with legacy fallback
Implement another version of QemuLoadImageLib that uses LoadImage and
StartImage, but falls back to the legacy Linux loader code if that
fails. The logic in the legacy fallback routines is identical to the
current QEMU linux loader for X64 and IA32.

Note the use of the OVMF_LOADED_X86_LINUX_KERNEL protocol for the legacy
loaded image: this makes it possible to expose the LoadImage/StartImage
abstraction for the legacy loader, using the EFI paradigm of identifying
a loaded image solely by a handle.

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
Ard Biesheuvel ddd2be6b00 OvmfPkg: provide a generic implementation of QemuLoadImageLib
Implement QemuLoadImageLib, and make it load the image provided by the
QEMU_EFI_LOADER_FS_MEDIA_GUID/kernel device path that we implemented
in a preceding patch in a separate DXE driver, using only the standard
LoadImage and StartImage boot services.

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 9b08c655ff OvmfPkg/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: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200304094413.19462-2-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
Laszlo Ersek 43df61878d OvmfPkg: enable SMM Monarch Election in PiSmmCpuDxeSmm
With "PcdCpuSmmEnableBspElection" set to FALSE, PiSmmCpuDxeSmm always
considers the processor with index 0 to be the SMM Monarch (a.k.a. the SMM
BSP). The SMM Monarch handles the SMI for real, while the other CPUs wait
in their SMM loops.

In a subsequent patch, we want to set "PcdCpuHotPlugSupport" to TRUE. For
that, PiCpuSmmEntry() [UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c] forces
us with an ASSERT() to set "PcdCpuSmmEnableBspElection" to TRUE as well.
To satisfy that expectation, we can simply remove our current
"PcdCpuSmmEnableBspElection|FALSE" setting, and inherit the default TRUE
value from "UefiCpuPkg.dec".

This causes "mSmmMpSyncData->BspIndex" in PiSmmCpuDxeSmm to lose its
static zero value (standing for CPU#0); instead it becomes (-1) in
general, and the SMM Monarch is elected anew on every SMI.

The default SMM Monarch Election is basically a race -- whichever CPU can
flip "mSmmMpSyncData->BspIndex" from (-1) to its own index, becomes king,
for handling that SMI. Refer to SmiRendezvous()
[UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c].

I consider this non-determinism less than ideal on QEMU/KVM; it would be
nice to stick with a "mostly permanent" SMM Monarch even with the Election
enabled. We can do that by implementing the PlatformSmmBspElection() API
in the SmmCpuPlatformHookLibQemu instance:

The IA32 APIC Base MSR can be read on each CPU concurrently, and it will
report the BSP bit as set only on the current Boot Service Processor. QEMU
marks CPU#0 as the BSP, by default.

Elect the current BSP, as reported by QEMU, for the SMM Monarch role.

(Note that the QEMU commit history is not entirely consistent on whether
QEMU/KVM may mark a CPU with nonzero index as the BSP:

- At tag v4.2.0, "target/i386/cpu.c" has a comment saying "We hard-wire
  the BSP to the first CPU". This comment goes back to commit 6cb2996cef5e
  ("x86: Extend validity of bsp_to_cpu", 2010-03-04).

- Compare commit 9cb11fd7539b ("target-i386: clear bsp bit when
  designating bsp", 2015-04-02) though, especially considering KVM.

Either way, this OvmfPkg patch is *not* dependent on CPU index 0; it just
takes the race on every SMI out of the game.)

One benefit of using a "mostly permanent" SMM Monarch / BSP is that we can
continue testing the SMM CPU synchronization by deterministically entering
the firmware on the BSP, vs. on an AP, from Linux guests:

$ time taskset -c 0 efibootmgr
$ time taskset -c 1 efibootmgr

(See
<https://github.com/tianocore/tianocore.github.io/wiki/Testing-SMM-with-QEMU,-KVM-and-libvirt#uefi-variable-access-test>.)

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Suggested-by: Igor Mammedov <imammedo@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512#c5
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200226221156.29589-5-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
2020-03-04 12:22:07 +00:00
Laszlo Ersek c69f6406b9 OvmfPkg: clone SmmCpuPlatformHookLib from UefiCpuPkg
Clone the Null instance of SmmCpuPlatformHookLib from UefiCpuPkg to
OvmfPkg. In this patch, customize the lib instance only with the following
no-op steps:

- Replace Null/NULL references in filenames and comments with Qemu/QEMU
  references.
- Update copyright notices.
- Clean up and rewrap comment blocks.
- Update INF_VERSION to the latest INF spec version (1.29).
- Update FILE_GUID.
- Drop the UNI file.

This patch is best reviewed with:

$ git show --find-copies=43 --find-copies-harder

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200226221156.29589-4-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
2020-03-04 12:22:07 +00:00
Antoine Coeur 493dde944d OvmfPkg/Xen: Fix various typos
Fix various typos in comments and documentation.

Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Julien Grall <julien@xen.org>
Signed-off-by: Antoine Coeur <coeur@gmx.fr>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Acked-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com>
Message-Id: <20200207010831.9046-61-philmd@redhat.com>
2020-02-10 22:30:07 +00:00
Antoine Coeur 9854561c08 OvmfPkg/Virtio: Fix few typos
Fix few typos in comments and documentation.

Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Antoine Coeur <coeur@gmx.fr>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com>
Message-Id: <20200207010831.9046-59-philmd@redhat.com>
2020-02-10 22:30:07 +00:00
Antoine Coeur a2e7559576 OvmfPkg/Qemu: Fix various typos
Fix various typos in comments and documentation.

When "VbeShim.asm" is modified, we have to re-run "VbeShim.sh"
to update "VbeShim.h".
The string modified by this patch is only used when the DEBUG
macro (at the top of the file) is commented out. Since the
string is not referenced, NASM eliminates it, resulting in
the same byte array content in "VbeShim.h".

Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Antoine Coeur <coeur@gmx.fr>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com>
Message-Id: <20200207010831.9046-58-philmd@redhat.com>
2020-02-10 22:30:07 +00:00
Laszlo Ersek 300aae1180 OvmfPkg/SEV: don't manage the lifecycle of the SMRAM at the default SMBASE
When OVMF runs in a SEV guest, the initial SMM Save State Map is

(1) allocated as EfiBootServicesData type memory in OvmfPkg/PlatformPei,
    function AmdSevInitialize(), for preventing unintended information
    sharing with the hypervisor;

(2) decrypted in AmdSevDxe;

(3) re-encrypted in OvmfPkg/Library/SmmCpuFeaturesLib, function
    SmmCpuFeaturesSmmRelocationComplete(), which is called by
    PiSmmCpuDxeSmm right after initial SMBASE relocation;

(4) released to DXE at the same location.

The SMRAM at the default SMBASE is a superset of the initial Save State
Map. The reserved memory allocation in InitializeRamRegions(), from the
previous patch, must override the allocating and freeing in (1) and (4),
respectively. (Note: the decrypting and re-encrypting in (2) and (3) are
unaffected.)

In AmdSevInitialize(), only assert the containment of the initial Save
State Map, in the larger area already allocated by InitializeRamRegions().

In SmmCpuFeaturesSmmRelocationComplete(), preserve the allocation of the
initial Save State Map into OS runtime, as part of the allocation done by
InitializeRamRegions(). Only assert containment.

These changes only affect the normal boot path (the UEFI memory map is
untouched during S3 resume).

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Message-Id: <20200129214412.2361-9-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2020-02-05 12:59:32 +00:00
Ard Biesheuvel 2d9950a2bf OvmfPkg: 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 c3c90d8aa7 OvmfPkg/PlatformBootManagerLib: Don't update progress if Pcd is 0
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2266

Independently of how we decide to address other aspects of the regression
introduced with commit 2de1f611be, it doesn't
make much sense to call for a progress update if PcdPlatformBootTimeOut is
zero.

PcdPlatformBootTimeOut 0, which is the cause of the bug (division by zero)
should be considered to indicate that a platform is not interested in
displaying a progress report, so we alter PlatformBootManagerWaitCallback
to behave that way.

We also change one variable name to make the code more 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-2-pete@akeo.ie>
2019-10-16 18:27:37 +02:00
Leif Lindholm 4040754daf OvmfPkg: strip trailing whitespace
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Julien Grall <julien.grall@arm.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
2019-10-04 11:18:32 +01: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 05480e2fd4 OvmfPkg/PlatformBootManagerLib: Use a Xen console for ConOut/ConIn
On a Xen PVH guest, none of the existing serial or console interface
works, so we add a new one, based on XenConsoleSerialPortLib, and
implemented via SerialDxe.

That is a simple console implementation that can work on both PVH
guest and HVM guests, even if it is rarely going to be used on HVM.

Have PlatformBootManagerLib look for the new console, when running as a
Xen guest.

Since we use VENDOR_UART_DEVICE_PATH, fix its description and coding
style.

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-32-anthony.perard@citrix.com>
2019-08-21 18:03:49 +02:00
Anthony PERARD ad256f9540 OvmfPkg/PlatformBootManagerLib: Handle the absence of PCI bus on Xen PVH
When running in a Xen PVH guest, there's nothing to do in
PciAcpiInitialization() because there isn't any PCI bus. When the Host
Bridge DID isn't recognised, simply continue. (The value of
PcdOvmfHostBridgePciDevId would be 0 because it isn't set.)

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-29-anthony.perard@citrix.com>
2019-08-21 18:03:49 +02:00
Anthony PERARD bc5df19872 OvmfPkg/PlatformBootManagerLib: Use XenDetected from XenPlatformLib
Replace the XenDetected() implementation by the one from
XenPlatformLib.

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-28-anthony.perard@citrix.com>
2019-08-21 18:03:49 +02:00
Anthony PERARD 054c3fe9b5 OvmfPkg/XenPlatformLib: Cache result for XenDetected
We are going to replace XenDetected() implementation in
PlatformBootManagerLib by the one in XenPlatformLib.
PlatformBootManagerLib's implementation does cache the result of
GetFirstGuidHob(), so we do something similar in XenPlatformLib.

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-27-anthony.perard@citrix.com>
2019-08-21 18:03:49 +02:00
Anthony PERARD 68f4599dfc OvmfPkg/XenHypercallLib: Enable it in PEIM
Allow to use Xen hypercalls earlier, during the PEIM stage, but
XenHypercallLibInit() must be called once the XenInfo HOB is created
with the HyperPage setup.

Change the return value of XenHypercallLibInit so failure can be
detected when the call shouldn't fail, but still have the constructor
always succeed.

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-17-anthony.perard@citrix.com>
2019-08-21 18:03:49 +02:00
Anthony PERARD f496443eb3 OvmfPkg/Library/XenPlatformLib: New library
The purpose of XenPlatformLib is to regroup the few functions that are
used in several places to detect if Xen is detected, and to get the
XenInfo HOB.

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-14-anthony.perard@citrix.com>
2019-08-21 18:03:49 +02:00
Anthony PERARD aaebea27da OvmfPkg/ResetSystemLib: Add missing dependency on PciLib
Add missing dependency on PciLib
and remove extra includes of OvmfPlatforms.h.

Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20190813113119.14804-2-anthony.perard@citrix.com>
2019-08-21 18:03:48 +02:00
Hao A Wu 84f736a73e OvmfPkg: Refer to Shell app via its declared GUID
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1843

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 OvmfPkg.

So instead, use the symbolic GUID in ShellPkg for this purpose, and drop
the reference to this PCD, and to the IntelFrameworkModulePkg package
entirely.

Cc: Ray Ni <ray.ni@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2019-06-17 09:27:32 +08:00
Igor Druzhinin 0c40c9c925 OvmfPkg/XenSupport: turn off address decoding before BAR sizing
On Xen, hvmloader firmware leaves address decoding enabled for
enumerated PCI device before jumping into OVMF. OVMF seems to
expect it to be disabled and tries to size PCI BARs in several places
without disabling it which causes BAR64, for example, being
incorrectly placed by QEMU.

Fix it by disabling PCI address decoding explicitly before the
first attempt to size BARs on Xen.

Signed-off-by: Igor Druzhinin <igor.druzhinin@citrix.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Anthony PERARD <anthony.perard@citrix.com>
2019-04-30 18:42:35 +02:00
Igor Druzhinin d63610df60 OvmfPkg/XenSupport: use a correct PCI host bridge aperture for BAR64
In case BAR64 is placed below 4G choose the correct aperture.
This fixes a failed assertion down the code path.

Acked-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Igor Druzhinin <igor.druzhinin@citrix.com>
2019-04-30 18:41:57 +02:00
Igor Druzhinin 27e4d6ae25 OvmfPkg/XenSupport: remove usage of prefetchable PCI host bridge aperture
This aperture doesn't exist in QEMU-XEN and hvmloader places BARs
in arbitrary order disregarding prefetchable bit. This makes
prefetchable and non-prefetchable BARs to follow each other that's
quite likely with PCI passthrough devices. In that case, the existing
code, that tries to work out aperture boundaries by reading hvmloader
BAR placement, will report a bogus prefetchable aperture which overlaps
with the regular one. It will eventually trigger an assertion in
DXE PCI initialization code.

Do the same thing as OVMF on QEMU-KVM and pass a non-existing aperture
there. It's not necessary to pass additional allocation flags as we set
ResourceAssigned flag on the root bridge which means they will be ignored.

Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Igor Druzhinin <igor.druzhinin@citrix.com>
2019-04-30 18:41:57 +02:00
Shenglei Zhang a8a8b408b7 OvmfPkg/PlatformBootManagerLib: Remove dependency on Mps.h
Mps.h is included in BdsPlatform.h but not actually used.
So remove it.

Cc: Jordan Justen <jordan.l.justen@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: Shenglei Zhang <shenglei.zhang@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
2019-04-28 09:50:13 +08:00
Zhichao Gao 84c0b80de7 OvmfPkg/ResetSystemLib: Add 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: Jordan Justen <jordan.l.justen@intel.com>
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:18 +08:00
Laszlo Ersek c2f643479e OvmfPkg/BasePciCapLib: suppress invalid "nullptr deref" warning
RH covscan reports the following "nullptr deref" warning:

> Error: CLANG_WARNING:
> edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:312:5:
> warning: Dereference of null pointer
> #    InstanceZero->NumInstancesUnion.NumInstances++;
> #    ^
> edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:509:7:
> note: Assuming 'OutCapList' is not equal to NULL
> #  if (OutCapList == NULL) {
> #      ^~~~~~~~~~~~~~~~~~
> edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:509:3:
> note: Taking false branch
> #  if (OutCapList == NULL) {
> #  ^
> edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:518:7:
> note: Assuming the condition is false
> #  if (OutCapList->Capabilities == NULL) {
> #      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:518:3:
> note: Taking false branch
> #  if (OutCapList->Capabilities == NULL) {
> #  ^
> edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:529:7:
> note: Assuming 'CapHdrOffsets' is not equal to NULL
> #  if (CapHdrOffsets == NULL) {
> #      ^~~~~~~~~~~~~~~~~~~~~
> edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:529:3:
> note: Taking false branch
> #  if (CapHdrOffsets == NULL) {
> #  ^
> edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:546:3:
> note: Taking false branch
> #  if (RETURN_ERROR (Status)) {
> #  ^
> edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:549:7:
> note: Assuming the condition is true
> #  if ((PciStatusReg & EFI_PCI_STATUS_CAPABILITY) != 0) {
> #      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:549:3:
> note: Taking true branch
> #  if ((PciStatusReg & EFI_PCI_STATUS_CAPABILITY) != 0) {
> #  ^
> edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:557:5:
> note: Taking false branch
> #    if (RETURN_ERROR (Status)) {
> #    ^
> edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:565:12:
> note: Assuming 'NormalCapHdrOffset' is > 0
> #    while (NormalCapHdrOffset > 0) {
> #           ^~~~~~~~~~~~~~~~~~~~~~
> edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:565:5:
> note: Loop condition is true.  Entering loop body
> #    while (NormalCapHdrOffset > 0) {
> #    ^
> edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:570:7:
> note: Taking false branch
> #      if (RETURN_ERROR (Status)) {
> #      ^
> edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:574:16:
> note: Calling 'InsertPciCap'
> #      Status = InsertPciCap (OutCapList, CapHdrOffsets, PciCapNormal,
> #               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:235:3:
> note: Null pointer value stored to 'InstanceZero'
> #  InstanceZero = NULL;
> #  ^~~~~~~~~~~~~~~~~~~
> edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:243:7:
> note: Assuming 'PciCap' is not equal to NULL
> #  if (PciCap == NULL) {
> #      ^~~~~~~~~~~~~~
> edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:243:3:
> note: Taking false branch
> #  if (PciCap == NULL) {
> #  ^
> edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:259:3:
> note: Taking false branch
> #  if (RETURN_ERROR (Status)) {
> #  ^
> edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:297:3:
> note: Taking false branch
> #  if (RETURN_ERROR (Status)) {
> #  ^
> edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:311:7:
> note: Assuming the condition is true
> #  if (PciCap->Key.Instance > 0) {
> #      ^~~~~~~~~~~~~~~~~~~~~~~~
> edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:311:3:
> note: Taking true branch
> #  if (PciCap->Key.Instance > 0) {
> #  ^
> edk2-89910a39dcfd/OvmfPkg/Library/BasePciCapLib/BasePciCapLib.c:312:5:
> note: Dereference of null pointer
> #    InstanceZero->NumInstancesUnion.NumInstances++;
> #    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> #  310|     //
> #  311|     if (PciCap->Key.Instance > 0) {
> #  312|->     InstanceZero->NumInstancesUnion.NumInstances++;
> #  313|     }
> #  314|     return RETURN_SUCCESS;

The warning is invalid: the flagged dereferencing of "InstanceZero" is
gated by a condition that is only satisfied if we dereference
"InstanceZero" *first*.

(Perhaps the analyzer assumes that the OrderedCollectionInsert() call,
just before line 259, can change the value of "PciCap->Key.Instance" via
the last argument:

   254    //
   255    // Add PciCap to CapList.
   256    //
   257    Status = OrderedCollectionInsert (CapList->Capabilities, &PciCapEntry,
   258               PciCap);
   259    if (RETURN_ERROR (Status)) {

That assumption is incorrect.)

Add a comment and an ASSERT().

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1710
Issue: scan-0994.txt
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2019-04-18 16:06:04 +02:00
Michael D Kinney b26f0cf9ee OvmfPkg: 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 10:58:19 -07:00
Bret Barkelew 2fe5f2f529 OvmfPkg/PlatformDebugLibIoPort: Add new APIs
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1395

Add new APIs' implementation (DebugVPrint, DebugBPrint)
in the DebugLib instance. These APIs would expose print
routines with VaList parameter and BaseList parameter.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Michael Turner <Michael.Turner@microsoft.com>
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
2019-04-02 12:49:28 +08:00
Laszlo Ersek a748817409 OvmfPkg/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: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien.grall@linaro.org>
Cc: Ray Ni <ray.ni@intel.com>
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:36 +01:00
Laszlo Ersek 77874ceebb OvmfPkg: add library to track boot option loading/starting on the console
Introduce the Platform Boot Manager Print Status Code Library (for short,
PlatformBmPrintScLib) class for catching and printing the LoadImage() /
StartImage() preparations, and return statuses, that are reported by
UefiBootManagerLib.

In the primary library instance, catch only such status codes that
UefiBootManagerLib reports from the same module that contains
PlatformBmPrintScLib. The intent is to establish a reporting-printing
channel within BdsDxe, between UefiBootManagerLib and
PlatformBmPrintScLib. Ignore status codes originating elsewhence, e.g.
from UiApp's copy of UefiBootManagerLib.

Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien.grall@linaro.org>
Cc: Ray Ni <ray.ni@intel.com>
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:22 +01:00
Hao Wu b6de92f74e OvmfPkg/LockBoxLib: Update the comments for API UpdateLockBox()
The previous commit:
MdeModulePkg/SmmLockBoxLib: Support LockBox enlarge in UpdateLockBox()

adds the support to enlarge a LockBox when using the LockBoxLib API
UpdateLockBox().

This commit is to sync the API description comment of UpdateLockBox() with
its counterparts in MdeModulePkg.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
2019-02-22 08:20:08 +08:00
Laszlo Ersek 91a5b13650 OvmfPkg/PlatformDebugLibIoPort: fix port detection for use in the DXE Core
The DXE Core is one of those modules that call
ProcessLibraryConstructorList() manually.

Before DxeMain() [MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c] calls
ProcessLibraryConstructorList(), and through it, our
PlatformDebugLibIoPortConstructor() function, DxeMain() invokes the
DEBUG() macro multiple times. That macro lands in our
PlatformDebugLibIoPortFound() function -- which currently relies on the
"mDebugIoPortFound" global variable that has (not yet) been set by the
constructor. As a result, early debug messages from the DXE Core are lost.

Move the device detection into PlatformDebugLibIoPortFound(), also caching
the fact (not just the result) of the device detection.

(We could introduce a separate DebugLib instance just for the DXE Core,
but the above approach works for all modules that currently consume the
PlatformDebugLibIoPort instance (which means "everything but SEC").)

This restores messages such as:

> CoreInitializeMemoryServices:
>   BaseAddress - 0x7AF21000 Length - 0x3CDE000 MinimalMemorySizeNeeded - 0x10F4000

Keep the empty constructor function -- OVMF's DebugLib instances have
always had constructors; we had better not upset constructor dependency
ordering by making our instance(s) constructor-less.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Fixes: c09d957130
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
[lersek@redhat.com: sanitize blank lines around "mDebugIoPortChecked"]
2018-08-06 20:56:12 +02:00
Ruiyu Ni 5f66615bb5 OvmfPkg/PlatformBds: Implement PlatformBootManagerUnableToBoot
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Julien Grall <julien.grall@linaro.org>
2018-07-27 15:47:52 +08:00
chenc2 dbf9cc87cb OvmfPkg: 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: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@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:47 +08:00
Gerd Hoffmann 04cb578d33 OvmfPkg: add QemuRamfb to platform console
Add QemuRamfbDxe device path to the list of platform console devices,
so ConSplitter will pick up the device even though it isn't a PCI GPU.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
2018-06-14 11:56:45 +02:00
Ard Biesheuvel 0a0566d5ed OvmfPkg/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
Liming Gao 2d0c6692ee OvmfPkg BasePciCapLib: Fix VS build failure
Fix VS warning C4244: 'function': conversion from 'UINT32' to 'UINT16',
possible loss of data.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Liming Gao <liming.gao@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
[lersek@redhat.com: remove whitespace after casts]
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2018-05-29 10:21:40 +02:00
Laszlo Ersek 02b9a8343f OvmfPkg: introduce PciCapPciIoLib
Add a library class, and a UEFI_DRIVER lib instance, that are layered on
top of PciCapLib, and allow clients to plug an EFI_PCI_IO_PROTOCOL backend
into PciCapLib, for config space access.

(Side note:

Although the UEFI spec says that EFI_PCI_IO_PROTOCOL_CONFIG() returns
EFI_UNSUPPORTED if "[t]he address range specified by Offset, Width, and
Count is not valid for the PCI configuration header of the PCI
controller", this patch doesn't directly document the EFI_UNSUPPORTED
error code, for ProtoDevTransferConfig() and its callers
ProtoDevReadConfig() and ProtoDevWriteConfig(). Instead, the patch refers
to "unspecified error codes". The reason is that in edk2, the
PciIoConfigRead() and PciIoConfigWrite() functions [1] can also return
EFI_INVALID_PARAMETER for the above situation.

Namely, PciIoConfigRead() and PciIoConfigWrite() first call
PciIoVerifyConfigAccess(), which indeed produces the standard
EFI_UNSUPPORTED error code, if the device's config space is exceeded.
However, if PciIoVerifyConfigAccess() passes, and we reach
RootBridgeIoPciRead() and RootBridgeIoPciWrite() [2], then
RootBridgeIoCheckParameter() can still fail, e.g. if the root bridge
doesn't support extended config space (see commit 014b472053).

For all kinds of Limit violations in IO, MMIO, and config space,
RootBridgeIoCheckParameter() returns EFI_INVALID_PARAMETER, not
EFI_UNSUPPORTED. That error code is then propagated up to, and out of,
PciIoConfigRead() and PciIoConfigWrite().

[1] MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c
[2] MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
)

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@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>
2018-05-24 21:20:42 +02:00
Laszlo Ersek 6a744d40d0 OvmfPkg: introduce PciCapPciSegmentLib
Add a library class, and a BASE lib instance, that are layered on top of
PciCapLib, and allow clients to plug a PciSegmentLib backend into
PciCapLib, for config space access.

(Side note:

The "MaxDomain" parameter is provided because, in practice, platforms
exist where a PCI Express device may show up on a root bridge such that
the root bridge doesn't support access to extended config space. Earlier
the same issue was handled for MdeModulePkg/PciHostBridgeDxe in commit
014b472053. However, that solution does not apply to the PciSegmentLib
class, because:

(1) The config space accessor functions of the PciSegmentLib class, such
    as PciSegmentReadBuffer(), have no way of informing the caller whether
    access to extended config space actually succeeds.

    (For example, in the UefiPciSegmentLibPciRootBridgeIo instace, which
    could in theory benefit from commit 014b472053, the
    EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL.Pci.Read() status code is explicitly
    ignored, because there's no way for the lib instance to propagate it
    to the PciSegmentLib caller. If the
    EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL.Pci.Read() call fails, then
    DxePciSegmentLibPciRootBridgeIoReadWorker() returns Data with
    indeterminate value.)

(2) There is no *general* way for any firmware platform to provide, or
    use, a PciSegmentLib instance in which access to extended config space
    always succeeds.

In brief, on a platform where config space may be limited to 256 bytes,
access to extended config space through PciSegmentLib may invoke undefined
behavior; therefore PciCapPciSegmentLib must give platforms a way to
prevent such access.)

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@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>
2018-05-24 21:13:11 +02:00
Laszlo Ersek 392a31467f OvmfPkg: introduce PciCapLib
Add a library class, and a BASE lib instance, to work more easily with PCI
capabilities in PCI config space. Functions are provided to parse
capabilities lists, and to locate, describe, read and write capabilities.
PCI config space access is abstracted away.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Suggested-by: Jordan Justen <jordan.l.justen@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>
2018-05-24 21:12:06 +02:00
Marc-André Lureau 8d65d3b25e OvmfPkg/PlatformBootManagerLib: process TPM PPI request
Call Tcg2PhysicalPresenceLibProcessRequest() to process pending PPI
requests from PlatformBootManagerAfterConsole().

Laszlo understanding of edk2 is that the PPI operation processing was
meant to occur *entirely* before End-Of-Dxe, so that 3rd party UEFI
drivers couldn't interfere with PPI opcode processing *at all*.

He suggested that we should *not* call
Tcg2PhysicalPresenceLibProcessRequest() from BeforeConsole(). Because,
an "auth" console, i.e. one that does not depend on a 3rd party
driver, is *in general* impossible to guarantee. Instead we could opt
to trust 3rd party drivers, and use the "normal" console(s) in
AfterConsole(), in order to let the user confirm the PPI requests. It
will depend on the user to enable Secure Boot, so that the
trustworthiness of those 3rd party drivers is ensured. If an attacker
roots the guest OS from within, queues some TPM2 PPI requests, and
also modifies drivers on the EFI system partition and/or in GPU option
ROMs (?), then those drivers will not load after guest reboot, and
thus the dependent console(s) won't be used for confirming the PPI
requests.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2018-05-22 16:30:44 +02:00
Marc-André Lureau b9777bb42e OvmfPkg: add Tcg2PhysicalPresenceLibQemu
Cloned "SecurityPkg/Library/DxeTcg2PhysicalPresenceLib" and:

- removed all the functions that are unreachable from
  Tcg2PhysicalPresenceLibProcessRequest() [called from platform BDS],
  or SubmitRequestToPreOSFunction() and
  ReturnOperationResponseToOsFunction() [called from Tcg2Dxe].

- replaced everything that's related to the
  TCG2_PHYSICAL_PRESENCE*_VARIABLE variables, with direct access to
  the QEMU structures.

This commit is based on initial experimental work from Stefan Berger.
In particular, he wrote most of QEMU PPI support, and designed the
qemu/firmware interaction. Initially, Stefan tried to reuse the
existing SecurityPkg code, but we eventually decided to get rid of the
variables and simplify the ovmf/qemu version.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
[lersek@redhat.com: clean up non-idiomatic coding style]
[lersek@redhat.com: null mPpi on invalid PPI address]
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2018-05-22 16:30:44 +02:00
Marc-André Lureau fe280ecbee OvmfPkg: add Tcg2PhysicalPresenceLibNull when !TPM2_ENABLE
This NULL library will let us call
Tcg2PhysicalPresenceLibProcessRequest() unconditionally from
BdsPlatform when building without TPM2_ENABLE.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
[lersek@redhat.com: replace MdeModulePkg.dec w/ MdePkg.dec]
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2018-05-22 16:30:43 +02:00
Laszlo Ersek 7ebad830d6 OvmfPkg/PlatformBootManagerLib: connect Virtio RNG devices again
Virtio RNG devices are never boot devices, so in commit 245c643cc8 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 245c643cc8 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>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Fixes: 245c643cc8
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:21 +02:00
Laszlo Ersek f803c03cc2 OvmfPkg/PlatformBootManagerLib: connect consoles unconditionally
If both ConIn and ConOut exist, but ConIn references none of the PS/2
keyboard, the USB wild-card keyboard, and any serial ports, then
PlatformInitializeConsole() currently allows the boot to proceed without
any input devices at all. This makes for a bad user experience -- the
firmware menu could only be entered through OsIndications, set by a guest
OS.

Do what ArmVirtQemu does already, namely connect the consoles, and add
them to ConIn / ConOut / ErrOut, unconditionally. (The underlying
EfiBootManagerUpdateConsoleVariable() function checks for duplicates.)

The issue used to be masked by the EfiBootManagerConnectAll() call that
got conditionalized in commit 245c643cc8.

This patch is best viewed with "git show -b -W".

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Fixes: 245c643cc8
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1577546
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-14 15:23:54 +02:00
Laszlo Ersek 5e0e476a95 OvmfPkg/PlatformBootManagerLib: add USB keyboard to ConIn
PlatformInitializeConsole() (called by PlatformBootManagerBeforeConsole())
adds elements of "gPlatformConsole" to ConIn / ConOut / ErrOut (as
requested per element) if at boot at least one of ConIn and ConOut doesn't
exist. This typically applies to new VMs, and VMs with freshly recreated
varstores.

Add a USB keyboard wildcard to ConIn via "gPlatformConsole", so that we
not only bind the PS/2 keyboard. (The PS/2 keyboard is added in
PrepareLpcBridgeDevicePath()). Explicitly connecting the USB keyboard is
necessary after commit 245c643cc8.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@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>
2018-04-16 21:45:25 +02:00
Laszlo Ersek ba9c8a8ccb OvmfPkg/TlsAuthConfigLib: configure trusted cipher suites for HTTPS boot
Read the list of trusted cipher suites from fw_cfg and to store it to
EDKII_HTTP_TLS_CIPHER_LIST_VARIABLE.

The fw_cfg file will be formatted by the "update-crypto-policies" utility
on the host side, so that the host settings take effect in guest HTTPS
boot as well. QEMU forwards the file intact to the firmware. The contents
are forwarded by NetworkPkg/HttpDxe (in TlsConfigCipherList()) to
NetworkPkg/TlsDxe (TlsSetSessionData()) and TlsLib (TlsSetCipherList()).

Note: the development of the "update-crypto-policies" feature is underway
at this time. Meanwhile the following script can be used to generate the
binary file for fw_cfg:

  export LC_ALL=C
  openssl ciphers -V \
  | sed -r -n \
      -e 's/^ *0x([0-9A-F]{2}),0x([0-9A-F]{2}) - .*$/\\\\x\1 \\\\x\2/p' \
  | xargs -r -- printf -- '%b' > ciphers.bin

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Gary Ching-Pang Lin <glin@suse.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Gary Lin <glin@suse.com>
Tested-by: Gary Lin <glin@suse.com>
Reviewed-by: Long Qin <qin.long@intel.com>
Reviewed-by: Jiaxin Wu <jiaxin.wu@intel.com>
[lersek@redhat.com: update commit msg and add script as requested by Gary]
[lersek@redhat.com: update commit msg as requested by Jiaxin]
2018-04-13 14:05:10 +02:00
Laszlo Ersek 9c7d0d4992 OvmfPkg/TlsAuthConfigLib: configure trusted CA certs for HTTPS boot
Introduce TlsAuthConfigLib to read the list of trusted CA certificates
from fw_cfg and to store it to EFI_TLS_CA_CERTIFICATE_VARIABLE.

The fw_cfg file is formatted by the "p11-kit" and "update-ca-trust"
utilities on the host side, so that the host settings take effect in guest
HTTPS boot as well. QEMU forwards the file intact to the firmware. The
contents are sanity-checked by NetworkPkg/HttpDxe code that was added in
commit 0fd13678a6.

Link TlsAuthConfigLib via NULL resolution into TlsAuthConfigDxe. This sets
EFI_TLS_CA_CERTIFICATE_VARIABLE in time for both
NetworkPkg/TlsAuthConfigDxe (for possible HII interaction with the user)
and for NetworkPkg/HttpDxe (for the effective TLS configuration).

The file formatted by "p11-kit" can be large. On a RHEL-7 host, the the
Mozilla CA root certificate bundle -- installed with the "ca-certificates"
package -- is processed into a 182KB file. Thus, create
EFI_TLS_CA_CERTIFICATE_VARIABLE as a volatile & boot-time only variable.
Also, in TLS_ENABLE builds, set the cumulative limit for volatile
variables (PcdVariableStoreSize) to 512KB, and the individual limit for
the same (PcdMaxVolatileVariableSize) to 256KB.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Gary Ching-Pang Lin <glin@suse.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Gary Lin <glin@suse.com>
Tested-by: Gary Lin <glin@suse.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2018-03-30 21:18:35 +02:00
Dandan Bi 699a2c30cb OvmfPkg:Fix VS2012 build failure
Initialize local variable to suppress warning C4701/C4703:
potentially uninitialized local variable/pointer variable.

1.In VirtualMemory.c:
Read of "PageMapLevel4Entry" in SetMemoryEncDe() is only
reached when "PageMapLevel4Entry" is got correctly.

2.In VirtioBlk.c:
Reads (dereferences) of "BufferMapping" and "BufferDeviceAddress"
in SynchronousRequest() are only reached if "BufferSize > 0" *and*
we map the data buffer successfully.

3.In VirtioScsi.c:
Reads (dereferences) of "InDataMapping" and "InDataDeviceAddress",
in VirtioScsiPassThru() are only reached if
"Packet->InTransferLength > 0" on input, *and* we map the
input buffer successfully. The similar reason for "OutDataMapping"
and "OutDataDeviceAddress".

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2018-03-28 09:58:49 +08:00
Laszlo Ersek a34a886962 OvmfPkg/PlatformBootManagerLib: process "-kernel" before boot devices
This improves the UEFI boot time for VMs that have "-kernel", many disks
or NICs, and no "bootindex" properties.

(Unlike in ArmVirt commit 23d04b58e2, in OvmfPkg commit 52fba28994 we
introduced TryRunningQemuKernel() right from the start *after*
BdsLibConnectAll(). Therefore, unlike in patch
'ArmVirtPkg/PlatformBootManagerLib: return to "-kernel before boot
devices"', we adopt the logic as new in this patch.)

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@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>
Tested-by: Gabriel Somlo <gsomlo@gmail.com>
2018-03-16 19:58:30 +01:00
Laszlo Ersek 5942ea61de OvmfPkg/PlatformBootManagerLib: hoist PciAcpiInitialization()
PlatformBootManagerAfterConsole()
                              <--------------------------------+
    PlatformBdsConnectSequence()                               |
      ConnectDevicesFromQemu() / EfiBootManagerConnectAll()    |
      PciAcpiInitialization() ---------------------------------+
    TryRunningQemuKernel()

Functionally this is a no-op:

- PciAcpiInitialization() iterates over PciIo protocol instances, which
  are available just the same at the new call site.

- The PCI interrupt line register exists only to inform system software
  (it doesn't affect hardware) and UEFI drivers don't use PCI interrupts
  anyway.

(More background in commits 2e70cf8ade and 5218c27950c4.)

This change will let us move TryRunningQemuKernel() between
PciAcpiInitialization() and PlatformBdsConnectSequence() in the next
patch.

Cc: "Gabriel L. Somlo" <gsomlo@gmail.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Gabriel Somlo <gsomlo@gmail.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Gabriel Somlo <gsomlo@gmail.com>
2018-03-16 19:58:27 +01:00
Laszlo Ersek fe1b9e8e08 OvmfPkg/PlatformBootManagerLib: rejuvenate old-style function comments
The old-style "Routine Description: ..." comments use the leftmost column
and are placed between the parameter list and the function body. Therefore
they cause git-diff to produce bogus hunk headers that fail to name the
function being patched.

Convert these comment blocks to the current edk2 style. While at it, clean
them up too.

For PlatformBootManagerBeforeConsole() and
PlatformBootManagerAfterConsole(), copy the descriptions from the call
sites in "MdeModulePkg/Universal/BdsDxe/BdsEntry.c". They are more
detailed than the comments in the lib class header
"MdeModulePkg/Include/Library/PlatformBootManagerLib.h"; ArmVirtPkg
already uses these comments.

No functional changes.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@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>
Tested-by: Gabriel Somlo <gsomlo@gmail.com>
2018-03-16 19:58:23 +01:00
Laszlo Ersek 1806451073 OvmfPkg/PlatformBootManagerLib: wrap overlong lines in "BdsPlatform.c"
No functional changes.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@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>
Tested-by: Gabriel Somlo <gsomlo@gmail.com>
2018-03-16 19:58:19 +01:00
Heyi Guo e33305ea6c OvmfPkg/PciHostBridgeLib: clear PCI aperture vars for (re)init
Use ZeroMem() to initialize (or re-initialize) all fields in temporary
PCI_ROOT_BRIDGE_APERTURE variables to zero. This is not mandatory but
is helpful for future extension: when we add new fields to
PCI_ROOT_BRIDGE_APERTURE and the default value of these fields can
safely be zero, this code will not suffer from an additional
change.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Heyi Guo <heyi.guo@linaro.org>
Signed-off-by: Yi Li <phoenix.liyi@huawei.com>
Reviewed-by: Ni Ruiyu <ruiyu.ni@intel.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2018-03-15 08:26:05 +00:00
Laszlo Ersek 245c643cc8 OvmfPkg/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:28 +01:00
Laszlo Ersek 51bd1f7699 OvmfPkg/QemuBootOrderLib: add ConnectDevicesFromQemu()
QemuBootOrderLib expects PlatformBootManagerLib to call the following
triplet:

(1) EfiBootManagerConnectAll(),
(2) EfiBootManagerRefreshAllBootOption(),
(3) SetBootOrderFromQemu().

This leads to bad performance, when many devices exist such that the
firmware can drive them, but they aren't marked for booting in the
"bootorder" fw_cfg file. Namely,

(1) EfiBootManagerConnectAll() talks to all hardware, which takes long.
    Plus some DriverBindingStart() functions write NV variables, which is
    also slow. (For example, the IP config policy for each NIC is stored
    in an NV var that is named after the MAC).

(2) EfiBootManagerRefreshAllBootOption() generates boot options from the
    protocol instances produced by (1). Writing boot options is slow.

(3) Under the above circumstances, SetBootOrderFromQemu() removes most of
    the boot options produced by (2). Erasing boot options is slow.

Introduce ConnectDevicesFromQemu() as a replacement for (1): only connect
devices that the QEMU user actually wants to boot off of.

(There's a slight loss of compatibility when a platform switches from
EfiBootManagerConnectAll() to ConnectDevicesFromQemu().
EfiBootManagerConnectAll() may produce UEFI device paths that are unknown
to QemuBootOrderLib (that is, for neither PCI- nor virtio-mmio-based
devices). The BootOrderComplete() function lets such unmatched boot
options survive at the end of the boot order. With
ConnectDevicesFromQemu(), these options will not be auto-generated in the
first place. They may still be produced by other means.

SetBootOrderFromQemu() is not modified in any way; reordering+filtering
boot options remains a separate task.)

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:24 +01:00
Laszlo Ersek 90f0918846 OvmfPkg/QemuBootOrderLib: clean up translation of virtio-net over MMIO
The "/MAC(" suffix of the translated UEFI devpath prefix is unnecessary
for matching, because the virtio-mmio base address in VenHwString is
unique anyway. Furthermore, the partial string "MAC(" cannot be processed
by ConvertTextToDevicePath(), which will become relevant later in this
series. Remove "/MAC(".

While at it, remove a bogus comment on PCI.

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:22 +01:00
Laszlo Ersek 5851b8253a OvmfPkg/QemuBootOrderLib: add missing EFIAPI specifiers
Public library APIs should be declared as EFIAPI.

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:19 +01:00
Laszlo Ersek dcb85e31fc OvmfPkg/QemuBootOrderLib: wrap overlong line
81 characters is too many.

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:23:38 +01:00
Laszlo Ersek 4120bb498f OvmfPkg/VirtioMmioDeviceLib: improve style of mMmioDeviceProtocolTemplate
In edk2, we spell "static" "STATIC", plus objects with static storage
duration (esp. protocol templates) should be const-qualified (spelled
"CONST") whenever possible.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@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:31:05 +01:00
Laszlo Ersek a3d7ae2ed8 OvmfPkg/VirtioMmioDeviceLib: list "VirtioMmioDevice.h" in the INF file
Among other things, the header file declares the functions that implement
the VIRTIO_DEVICE_PROTOCOL members over virtio-mmio. The functions are
defined in "VirtioMmioDeviceFunctions.c", and referenced in the
initialization of "mMmioDeviceProtocolTemplate", in "VirtioMmioDevice.c".

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
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:31:03 +01:00
Laszlo Ersek e29f9f1409 OvmfPkg/SerializeVariablesLib: list "SerializeVariablesLib.h" in INF file
The header file defines macros and types for "SerializeVariablesLib.c".

Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
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>
2018-03-13 14:30:59 +01:00
Laszlo Ersek 2d94e8f72a OvmfPkg/QemuBootOrderLib: list "ExtraRootBusMap.h" in the INF file
The header file declares the CreateExtraRootBusMap(),
DestroyExtraRootBusMap(), and MapRootBusPosToBusNr() functions. They are
defined in "ExtraRootBusMap.c", and called from "QemuBootOrderLib.c".

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
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:30:58 +01:00
Laszlo Ersek 1dd46be315 OvmfPkg/QemuBootOrderLib: sort [Sources*] sections in the INF file
This makes it easier to insert future source files. No functional changes.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@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:30:56 +01:00
Laszlo Ersek 8fe388d993 OvmfPkg/PlatformDebugLibIoPort: list "DebugLibDetect.h" in the INF files
Among other things, "DebugLibDetect.h" declares the
PlatformDebugLibIoPortFound() function. The function is called from
"DebugLib.c", which is included in both library instances. The function is
defined separately per library instance, in "DebugLibDetectRom.c" and
"DebugLibDetect.c", respectively.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
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:30:54 +01:00
Laszlo Ersek 332de9a3b0 OvmfPkg/NvVarsFileLib: list "NvVarsFileLib.h" in the INF file
The header file declares LoadNvVarsFromFs() and SaveNvVarsToFs(), which
are defined in "FsAccess.c" and called from "NvVarsFileLib.c".

Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
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>
2018-03-13 14:30:52 +01:00
Laszlo Ersek 235aa246a4 OvmfPkg/LockBoxLib: list "LockBoxLib.h" in the INF files
Among other things, the header file declares the AllocateAcpiNvsPool()
function. This function is called from the "LockBoxLib.c" source file (in
the implementation of the SaveLockBox() library API), which is built into
both library instances. AllocateAcpiNvsPool() is implemented separately
per library instance, in "LockBoxBase.c" and "LockBoxDxe.c", respectively.

(In the LockBoxBaseLib instance, the AllocateAcpiNvsPool() function is
never expected to be called -- the public SaveLockBox() API should never
be called before the DXE phase --, we just have to provide a stub for
linking purposes.)

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
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:30:43 +01:00
Laszlo Ersek c63bcc2e4b OvmfPkg/LoadLinuxLib: list "LoadLinuxLib.h" in the INF file
The header file declares the InitLinuxDescriptorTables() and
SetLinuxDescriptorTables() functions, which are called from "Linux.c" and
implemented in "LinuxGdt.c".

The header file also declares the JumpToKernel() and JumpToUefiKernel()
functions, which are similarly called from "Linux.c". They are implemented
(dependent on architecture) in "Ia32/JumpToKernel.nasm" and
"X64/JumpToKernel.nasm".

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
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:30:41 +01:00
Laszlo Ersek c02a2f2559 OvmfPkg/BaseMemEncryptSevLib: list "X64/VirtualMemory.h" in the INF file
Among other things, the header file declares the
InternalMemEncryptSevSetMemoryDecrypted() and
InternalMemEncryptSevSetMemoryEncrypted() functions. The functions are
called from "X64/MemEncryptSevLib.c", and defined in
"X64/VirtualMemory.c".

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
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:30:39 +01:00
Laszlo Ersek ecf25cb5c2 OvmfPkg/AcpiTimerLib: list "AcpiTimerLib.h" in the INF files
The header file declares the InternalAcpiGetTimerTick() function. The
function is called from "AcpiTimerLib.c", which is built into all three
library instances. The function is defined individually per library
instance, in "BaseRomAcpiTimerLib.c", "BaseAcpiTimerLib.c", and
"DxeAcpiTimerLib.c" (enumerated in increasing firmware phase order).

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
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:30:37 +01:00
Laszlo Ersek 5ef3b66fec OvmfPkg/SmmCpuFeaturesLib: SEV: encrypt+free pages of init. save state map
Based on the following patch from Brijesh Singh <brijesh.singh@amd.com>:

  [PATCH v2 1/2] OvmfPkg/AmdSevDxe: Clear the C-bit from SMM Saved State
  http://mid.mail-archive.com/20180228161415.28723-2-brijesh.singh@amd.com
  https://lists.01.org/pipermail/edk2-devel/2018-February/022016.html

Once PiSmmCpuDxeSmm relocates SMBASE for all VCPUs, the pages of the
initial SMRAM save state map can be re-encrypted (including zeroing them
out after setting the C-bit on them), and they can be released to DXE for
general use (undoing the allocation that we did in PlatformPei's
AmdSevInitialize() function).

The decryption of the same pages (which will occur chronologically
earlier) is implemented in the next patch; hence the "re-encryption" part
of this patch is currently a no-op. The series is structured like this in
order to be bisection-friendly. If the decryption patch preceded this
patch, then an info leak would be created while standing between the
patches.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
2018-03-06 13:30:35 +01:00
Laszlo Ersek 61a044c6c1 OvmfPkg/MemEncryptSevLib: find pages of initial SMRAM save state map
In the next three patches, we're going to modify three modules under
OvmfPkg. When OVMF is built with -D SMM_REQUIRE and runs in an SEV guest,
each affected module will have to know the page range that covers the
initial (pre-SMBASE relocation) SMRAM save state map. Add a helper
function to MemEncryptSevLib that calculates the "base address" and
"number of pages" constants for this page range.

(In a RELEASE build -- i.e., with assertions disabled and optimization
enabled --, the helper function can be compiled to store two constants
determined at compile time.)

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
2018-03-06 13:30:30 +01:00
Laszlo Ersek e1e0428615 OvmfPkg/SmmCpuFeaturesLib: remove unneeded #includes and LibraryClasses
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
2018-03-06 13:30:22 +01:00
Laszlo Ersek 4a9b250bca OvmfPkg/SmmCpuFeaturesLib: sort #includes, and entries in INF file sections
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
2018-03-06 13:30:20 +01:00
Laszlo Ersek ea992760ff OvmfPkg/SmmCpuFeaturesLib: upper-case the "static" keyword
In edk2, the "static" keyword is spelled "STATIC". Also let "STATIC" stand
alone on a line in function definitions.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
2018-03-06 13:30:18 +01:00
Laszlo Ersek b1bfdd6597 OvmfPkg/SmmCpuFeaturesLib: rewrap to 79 columns
There are many overlong lines; it's hard to work with the library like
this. Rewrap all files to 79 columns.

(

The rewrapping of the "mSmmCpuRegisterRanges" and "mSmmCpuWidthOffset"
arrays was verified by hexdumping the arrays in
SmmCpuFeaturesLibConstructor(), both before and after the patch, and
comparing the dumps.

Contents of "mSmmCpuRegisterRanges", IA32 build:

> mSmmCpuRegisterRanges: {
> mSmmCpuRegisterRanges: 000000 04 00 00 00 0A 00 00 00 07 00 00 00 14 00 00 00
> mSmmCpuRegisterRanges: 000010 2E 00 00 00 1B 00 00 00 33 00 00 00 36 00 00 00
> mSmmCpuRegisterRanges: 000020 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> mSmmCpuRegisterRanges: }

Contents of "mSmmCpuRegisterRanges", X64 build:

> mSmmCpuRegisterRanges: {
> mSmmCpuRegisterRanges: 000000 04 00 00 00 0A 00 00 00 07 00 00 00 00 00 00 00
> mSmmCpuRegisterRanges: 000010 14 00 00 00 2E 00 00 00 1B 00 00 00 00 00 00 00
> mSmmCpuRegisterRanges: 000020 33 00 00 00 36 00 00 00 04 00 00 00 00 00 00 00
> mSmmCpuRegisterRanges: 000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> mSmmCpuRegisterRanges: }

Contents of "mSmmCpuWidthOffset", both IA32 and X64 builds:

> mSmmCpuWidthOffset: {
> mSmmCpuWidthOffset: 000000 00 00 00 00 00 00 00 00 00 00 00 08 00 00 68 02
> mSmmCpuWidthOffset: 000010 6C 02 00 00 00 08 00 00 88 02 8C 02 00 00 00 08
> mSmmCpuWidthOffset: 000020 00 00 78 02 7C 02 00 00 00 00 00 00 64 02 68 02
> mSmmCpuWidthOffset: 000030 00 00 00 00 00 00 84 02 88 02 00 00 00 00 00 00
> mSmmCpuWidthOffset: 000040 74 02 78 02 00 00 00 00 00 00 00 00 04 00 00 00
> mSmmCpuWidthOffset: 000050 04 04 A8 03 00 02 00 00 00 00 04 04 AC 03 10 02
> mSmmCpuWidthOffset: 000060 00 00 00 00 04 04 B0 03 20 02 00 00 00 00 04 04
> mSmmCpuWidthOffset: 000070 B4 03 30 02 00 00 00 00 04 04 B8 03 40 02 00 00
> mSmmCpuWidthOffset: 000080 00 00 04 04 BC 03 50 02 00 00 00 00 00 04 00 00
> mSmmCpuWidthOffset: 000090 70 02 00 00 00 00 04 04 C4 03 90 02 00 00 00 00
> mSmmCpuWidthOffset: 0000A0 04 08 C8 03 60 03 64 03 00 00 04 08 CC 03 68 03
> mSmmCpuWidthOffset: 0000B0 6C 03 00 00 00 08 00 00 B8 03 BC 03 01 00 00 08
> mSmmCpuWidthOffset: 0000C0 00 00 B0 03 B4 03 01 00 00 08 00 00 A8 03 AC 03
> mSmmCpuWidthOffset: 0000D0 01 00 00 08 00 00 A0 03 A4 03 01 00 00 08 00 00
> mSmmCpuWidthOffset: 0000E0 98 03 9C 03 01 00 00 08 00 00 90 03 94 03 01 00
> mSmmCpuWidthOffset: 0000F0 00 08 00 00 88 03 8C 03 01 00 00 08 00 00 80 03
> mSmmCpuWidthOffset: 000100 84 03 01 00 04 08 D0 03 F8 03 FC 03 01 00 04 08
> mSmmCpuWidthOffset: 000110 DC 03 E0 03 E4 03 01 00 04 08 D4 03 F0 03 F4 03
> mSmmCpuWidthOffset: 000120 01 00 04 08 D8 03 E8 03 EC 03 01 00 04 08 E0 03
> mSmmCpuWidthOffset: 000130 D8 03 DC 03 01 00 04 08 E4 03 D0 03 D4 03 01 00
> mSmmCpuWidthOffset: 000140 04 08 E8 03 C8 03 CC 03 01 00 04 08 EC 03 C0 03
> mSmmCpuWidthOffset: 000150 C4 03 01 00 04 08 F0 03 78 03 7C 03 01 00 04 08
> mSmmCpuWidthOffset: 000160 F4 03 70 03 74 03 01 00 04 08 FC 03 58 03 5C 03
> mSmmCpuWidthOffset: 000170 00 00 04 08 F8 03 50 03 54 03 00 00 00 04 00 00
> mSmmCpuWidthOffset: 000180 48 03 4C 03 00 00
> mSmmCpuWidthOffset: }

)

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
2018-03-06 13:30:14 +01:00
Laszlo Ersek bd13ecf355 OvmfPkg/MemEncryptSevLib: sort #includes, and entries in INF file sections
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
2018-03-06 13:30:10 +01:00
Laszlo Ersek 68e60a388d OvmfPkg/MemEncryptSevLib: clean up InternalMemEncryptSevSetMemoryEncrypted() decl
The declaration and the definition(s) of the function should have
identical leading comments and/or identical parameter lists. Document the
"Cr3BaseAddress" parameter, and correct several parameter references.
Replace a "clear" reference to the C-bit with a "set" reference.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
2018-03-06 13:30:09 +01:00
Laszlo Ersek 1532e5d5ed OvmfPkg/MemEncryptSevLib: clean up InternalMemEncryptSevSetMemoryDecrypted() decl
The declaration and the definition(s) of the function should have
identical leading comments and/or identical parameter lists. Document the
"Cr3BaseAddress" parameter, and correct several parameter references.
Replace a "set" reference to the C-bit with a "clear" reference.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
2018-03-06 13:30:07 +01:00
Laszlo Ersek cde8c56809 OvmfPkg/MemEncryptSevLib: clean up SetMemoryEncDec() comment block
Document the "Cr3BaseAddress" parameter, and correct several parameter
references.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
2018-03-06 13:30:05 +01:00
Laszlo Ersek 154dcd6c58 OvmfPkg/MemEncryptSevLib: clean up MemEncryptSevSetPageEncMask() decl
The declaration and the definition(s) of the function should have
identical leading comments and/or identical parameter lists. Replace any
leftover "clear" references to the C-bit with "set" references. Also
remove any excess space in the comment block, and unindent the trailing
"**/" if necessary. Correct several parameter references.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
2018-03-06 13:30:03 +01:00
Laszlo Ersek 5b5028e67b OvmfPkg/MemEncryptSevLib: clean up MemEncryptSevClearPageEncMask() decl
The declaration and the definition(s) of the function should have
identical leading comments and/or identical parameter lists. Also remove
any excess space in the comment block, and unindent the trailing "**/" if
necessary. Correct several parameter references.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
2018-03-06 13:30:01 +01:00
Laszlo Ersek d4dd22c7bc OvmfPkg/MemEncryptSevLib: clean up MemEncryptSevIsEnabled() decl
The declaration and the definition(s) of the function should have
identical leading comments and/or identical parameter lists. Also remove
any excess space in the comment block, and unindent the trailing "**/" if
necessary.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
2018-03-06 13:29:58 +01:00
Laszlo Ersek 4bd6bf317e OvmfPkg/MemEncryptSevLib: rewrap to 79 characters width
There are many overlong lines; it's hard to work with the library like
this. Rewrap all files to 79 columns.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
2018-03-06 13:29:37 +01:00
Brijesh Singh b721aa749b OvmfPkg/BaseMemEncryptSevLib: Enable protection for newly added page table
Commit 2ac1730bf2 (MdeModulePkg/DxeIpl: Mark page table as read-only)
sets the memory pages used for page table as read-only after paging is
setup and sets CR0.WP to protect CPU modifying the read-only pages.
The commit causes #PF when MemEncryptSevClearPageEncMask() or
MemEncryptSevSetPageEncMask() tries to change the page-table attributes.

This patch takes the similar approach as Commit 147fd35c3e
(UefiCpuPkg/CpuDxe: Enable protection for newly added page table).
When page table protection is enabled, we disable it temporarily before
changing the page table attributes.

This patch makes use of the same approach as Commit 2ac1730bf2
(MdeModulePkg/DxeIpl: Mark page table as read-only)) for allocating
page table memory from reserved memory pool, which helps to reduce a
potential "split" operation.

The patch duplicates code from commit 147fd35c3e. The code duplication
will be removed after we implement page table manipulation library. See
bugzilla https://bugzilla.tianocore.org/show_bug.cgi?id=847.

Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@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: Brijesh Singh <brijesh.singh@amd.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
2018-01-15 21:18:50 +01:00
Laszlo Ersek dc32e820f0 OvmfPkg/QemuBootOrderLib: let an OFW devpath match multiple UEFI boot opts
This means that SetBootOrderFromQemu() will preserve all UEFI boot options
matched by any given OFW devpath, such as PXEv4, HTTPv4, PXEv6 and HTTPv6
boot options for the same NIC. Currently we stop the matching / appending
for the OFW devpath coming from the outer loop whenever we find the first
UEFI boot option match in the inner loop.

(The previous patch was about multiple OFW devpaths matching a single UEFI
boot option (which should never happen). This patch is about a single OFW
devpath matching multiple UEFI boot options. With the "break" statement
removed here, the small optimization from the last patch becomes a bit
more relevant, because now the inner loop always counts up to
ActiveCount.)

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2017-11-28 21:37:11 +01:00
Laszlo Ersek a0e761b153 OvmfPkg/QemuBootOrderLib: skip already matched / appended UEFI boot opts
The SetBootOrderFromQemu() function implements a nested loop where

- the outer loop iterates over all OpenFirmware (OFW) device paths in the
  QEMU boot order, and translates each to a UEFI device path prefix;

- the inner loop matches the current (translated) prefix against all
  active UEFI boot options in turn;

- if the UEFI boot option is matched by the translated prefix, the UEFI
  boot option is appended to the "new" UEFI boot order, and marked as
  "has been appended".

This patch adds a micro-optimization where already matched / appended UEFI
boot options are skipped in the inner loop. This is not a functional
change. A functional change would be if, as a consequence of the patch,
some UEFI boot options would no longer be *doubly* matched.

For a UEFI boot option to be matched by two translated prefixes, one of
those prefixes would have to be a (proper, or equal) prefix of the other
prefix. The PCI and MMIO OFW translation routines output such only in the
following cases:

- When the original OFW device paths are prefixes of each other. This is
  not possible from the QEMU side. (Only leaf devices are bootable.)

- When the translation rules in the routines are incomplete, and don't
  look at the OFW device paths for sufficient length (i.e., at nodes where
  they would already differ, and the difference would show up in the
  translation output).

  This would be a shortcoming of the translation routines and should be
  fixed in TranslatePciOfwNodes() and TranslateMmioOfwNodes(), whenever
  identified.

Even in the second case, this patch would replace the double appending of
a single UEFI boot option (matched by two different OFW device paths) with
a correct, or cross-, matching of two different UEFI boot options. Again,
this is not expected, but arguably it would be more correct than duplicate
boot option appending, should it occur due to any (unexpected, unknown)
lack of detail in the translation routines.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2017-11-28 21:36:53 +01:00
Paolo Bonzini c09d957130 OvmfPkg: save on I/O port accesses when the debug port is not in use
When SEV is enabled, every debug message printed by OVMF to the
QEMU debug port traps from the guest to QEMU character by character
because "REP OUTSB" cannot be used by IoWriteFifo8.  Furthermore,
when OVMF is built with the DEBUG_VERBOSE bit (value 0x00400000)
enabled in "gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel", then the
OvmfPkg/IoMmuDxe driver, and the OvmfPkg/Library/BaseMemEncryptSevLib
library instance that is built into it, produce a huge amount of
log messages.  Therefore, in SEV guests, the boot time impact is huge
(about 45 seconds _additional_ time spent writing to the debug port).

While these messages are very useful for analyzing guest behavior,
most of the time the user won't be capturing the OVMF debug log.
In fact libvirt does not provide a method for configuring log capture;
users that wish to do this (or are instructed to do this) have to resort
to <qemu:arg>.

The debug console device provides a handy detection mechanism; when read,
it returns 0xE9 (which is very much unlike the 0xFF that is returned by
an unused port).  Use it to skip the possibly expensive OUT instructions
when the debug I/O port isn't plugged anywhere.

For SEC, the debug port has to be read before each full message.
However:

- if the debug port is available, then reading one byte before writing
a full message isn't tragic, especially because SEC doesn't print many
messages

- if the debug port is not available, then reading one byte instead of
writing a full message is still a win.

Contributed-under: TianoCore Contribution Agreement 1.0
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen (Intel address) <jordan.l.justen@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2017-11-17 18:35:12 +01:00
Paolo Bonzini c9eb56e5fd OvmfPkg: create a separate PlatformDebugLibIoPort instance for SEC
The next patch will want to add a global variable to
PlatformDebugLibIoPort, but this is not suitable for the SEC
phase, because SEC runs from read-only flash.  The solution is
to have two library instances, one for SEC and another
for all other firmware phases.  This patch adds the "plumbing"
for the SEC library instance, separating the INF files and
moving the constructor to a separate C source file.

Contributed-under: TianoCore Contribution Agreement 1.1
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen (Intel address) <jordan.l.justen@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2017-11-17 18:35:08 +01:00
Paolo Bonzini 6dead8d5af OvmfPkg: make PlatformDebugLibIoPort a proper BASE library
Remove Uefi.h, which includes UefiSpec.h, and change the
return value to match the RETURN_STATUS type.

Contributed-under: TianoCore Contribution Agreement 1.1
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen (Intel address) <jordan.l.justen@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2017-11-17 18:34:56 +01:00
Ard Biesheuvel 12c6484058 OvmfPkg/XenHypercallLib: enable virt extensions for ARM
XenHypercallLib uses the 'hvc' instruction, which is not implemented
on all ARMv7 CPUs, and so we need to explicitly specify a CPU that
has the virtualization extensions.

This override used to be set at the platform level, but this was removed
in commit 0d36a219c7
('ArmPlatformPkg/PL031RealTimeClockLib: drop ArmPlatformSysConfigLib
reference), under the assumption that all users of the 'hvc' instruction
had already been fixed.

So fix this for GNU binutils by adding the 'virt' arch extension
directive, and for RVCT by setting the --cpu command line option to a
CPU that is virt capable.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
2017-11-17 09:56:50 +00:00
Laszlo Ersek f9c59fa44a OvmfPkg/QemuBootOrderLib: recognize "usb-storage" devices in XHCI ports
The feature is primarily useful for modern AARCH64 guests that have no
built-in virtio block / SCSI drivers; as on "qemu-system-aarch64 -M virt",
there are no IDE or AHCI controllers that could be used as fallback. XHCI
is available in "-M virt" however, and because XHCI predates AARCH64 by
several years, said guests are expected to have built-in drivers for it.

Other device models ("usb-uas", "usb-bot") are out of scope for now,
similarly to USB1.x (UHCI) and USB2 (EHCI) host controllers, and similarly
to USB hubs (which are USB1.1 only). In particular, port mapping between
EHCI and companion UHCI controllers is very complex; it even leads to PCI
slot/function differences between the OpenFirmware device paths exported
by QEMU and the the UEFI device paths generated by edk2.

The number of ports on the XHCI controller defaults to 4, but it can be
raised via the "p3" property to 15. In addition, several XHCI controllers
can be grouped into a single-slot, multi-function PCI device. These allow
for a good number of usb-storage devices, while their desired boot order
remains recognizable to this patch.

In the example below, we create two XHCI controllers, grouped into PCI
slot 00:02 as functions 0 and 1. Both controllers are given 15 ports. We
attach a "usb-storage" device to controller 1 at port 3 (ports are 1-based
in QEMU, 0-based in edk2), and attach another "usb-storage" device to
controller 2 at port 9.

QEMU command line options (NB. they apply equally to aarch64/virt and
x86_64/{i440fx,q35}):

  -device qemu-xhci,id=xhci1,p3=15,addr=02.0,multifunction=on \
  -device qemu-xhci,id=xhci2,p3=15,addr=02.1 \
  \
  -drive id=disk1,if=none,format=qcow2,$DISK1_OPTIONS \
  -drive id=disk2,if=none,format=qcow2,$DISK2_OPTIONS \
  \
  -device usb-storage,drive=disk1,bus=xhci1.0,port=3,bootindex=1 \
  -device usb-storage,drive=disk2,bus=xhci2.0,port=9,bootindex=2 \

Libvirt domain XML fragment:

  <controller type='usb' index='1' model='qemu-xhci' ports='15'>
    <address type='pci'
     domain='0x0000' bus='0x00' slot='0x02' function='0x0'
     multifunction='on'/>
  </controller>
  <controller type='usb' index='2' model='qemu-xhci' ports='15'>
    <address type='pci'
     domain='0x0000' bus='0x00' slot='0x02' function='0x1'/>
  </controller>

  <disk type='file' device='disk'>
    <driver name='qemu' type='qcow2'/>
    <source file='...'/>
    <target dev='sda' bus='usb'/>
    <boot order='1'/>
    <address type='usb' bus='1' port='3'/>
  </disk>
  <disk type='file' device='disk'>
    <driver name='qemu' type='qcow2'/>
    <source file='...'/>
    <target dev='sdb' bus='usb'/>
    <boot order='2'/>
    <address type='usb' bus='2' port='9'/>
  </disk>

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2017-09-22 14:54:35 +02:00
Laszlo Ersek 837d9eea7d OvmfPkg/PlatformBootManagerLib: log informative message at DEBUG_INFO lvl
"Boot Mode:%x" is an informative message, not an error report. Set its
debug mask to DEBUG_INFO.

Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
2017-09-11 22:39:32 +02:00
Laszlo Ersek 80886a6953 OvmfPkg/PlatformDebugLibIoPort: write messages with IoWriteFifo8()
Since commit 19c6d9feaa ("MdePkg: Expand BaseIoLibIntrinsic (IoLib
class) library", 2017-01-14), IoWriteFifo8() has been widely available to
modules. Use it to print debug messages and assertion failures to the QEMU
debug port, rather than open-coded loops.

In the general case this speeds up logging, because debug messages will
now trap to QEMU once per message (as opposed to once per character), due
to "REP OUTSB" in "MdePkg/Library/BaseIoLibIntrinsic/*/IoFifoSev.nasm".

In SEV guests, there is no speedup (SEV doesn't support the REP prefix).
SEV is detected internally to BaseIoLibIntrinsic.

Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Brijesh Singh <brijesh.singh@amd.com>
2017-09-11 22:28:25 +02:00
Laszlo Ersek d8d33741e8 OvmfPkg/BaseMemEncryptSevLib: fix typos in DEBUG messages
Replace "spliting" with "splitting".

Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
2017-09-01 14:20:37 +02:00
Laszlo Ersek 5597edfa8b OvmfPkg/BaseMemEncryptSevLib: clean up upper-case / lower-case in DEBUGs
Debug messages that start as natural (English) language phrases (after the
debug prefix) should uniformly begin with lower-case or upper-case. In
SetMemoryEncDec() we have a mixture now. Stick with lower-case.
(Upper-case is better for full sentences that also end with punctuation.)

Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
2017-09-01 14:20:35 +02:00
Laszlo Ersek 3728ea5a95 OvmfPkg/BaseMemEncryptSevLib: promote DEBUG_WARN levels to DEBUG_ERROR
In SetMemoryEncDec(), we have four locations where we (a) log a message on
the DEBUG_WARN level that says "ERROR", (b) return the status code
RETURN_NO_MAPPING right after.

These messages clearly describe actual errors (bad PML4, PDPE, PDE, PTE).
Promote their debug levels to DEBUG_ERROR, and remove the word "ERROR"
from the messages.

Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
2017-09-01 14:20:33 +02:00