Activate the default console when user interaction is required for
the processing of TPM 2 physical presence interface opcodes.
Background:
TPM 2 physical presence interface (PPI) opcodes need to be handled before
the TPM 2 platform hierarchy is disabled. Due to this requirement we will
move the function call to handle the PPI opcodes into
PlatformBootManagerBeforeConsole() which runs before the initialization
of the consoles. However, since for interaction with the user we need
the console to be available, activate it now before displaying any message
to the user.
Cc: Rebecca Cran <rebecca@bsdio.com>
Cc: Peter Grehan <grehan@freebsd.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Min Xu <min.m.xu@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Now with everything in place for virtio 1.0 devices we can let
VirtioMmioInit() return SUCCESS.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Use QueueNumMax as QueueNum default for drivers which do not
explicitly call VIRTIO_DEVICE_PROTOCOL->SetQueueSize().
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Virtio 1.0 allows a more flexible virtio ring layout, so we have to set
addresses for descriptors avail flags and use flags separately. We
continue to use a ring layout compatible with virtio 0.9.5 though, so no
other changes are needed to setup the virtio queues.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Add #defines for the Version field. Read and store the version,
log the version found as info message.
Continue to return UNSUPPORTED for now, we need some more patches
to complete virtio 1.0 support first.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
The "OvmfPkg/Library/PciHostBridgeLibScan/PciHostBridgeLibScan.inf"
instance is used in the following platforms in edk2:
OvmfPkg/Bhyve/BhyveX64.dsc
OvmfPkg/OvmfXen.dsc
Both platforms define "PcdPciDisableBusEnumeration" with Fixed-at-Build
access method, and TRUE value. Remove the PCD from the
PciHostBridgeLibScan instance, and everything else that is useful only
when the PCD is FALSE.
In practice, this removes the PciHostBridgeUtilityGetRootBridges()
function call, which is based on fw-cfg; see
"OvmfPkg/Library/PciHostBridgeUtilityLib/PciHostBridgeUtilityLib.c".
(Note that the dependency on PciHostBridgeUtilityLib remains in place,
given that the PciHostBridgeLibScan instance continues using lower-level
functions from the library that do not depend on fw-cfg.)
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien@xen.org>
Cc: Peter Grehan <grehan@freebsd.org>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Rebecca Cran <rebecca@bsdio.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210526201446.12554-34-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
The "OvmfPkg/Library/PciHostBridgeLib/PciHostBridgeLib.inf" instance is
used by the following platforms in edk2:
OvmfPkg/AmdSev/AmdSevX64.dsc
OvmfPkg/OvmfPkgIa32.dsc
OvmfPkg/OvmfPkgIa32X64.dsc
OvmfPkg/OvmfPkgX64.dsc
All these platforms statically inherit PcdPciDisableBusEnumeration=FALSE
from "MdeModulePkg.dec". Remove the the PCD and everything that depends on
it from the PciHostBridgeLib instance. Namely, remove the logic that
determines the root bridge apertures by (a) scanning the entire bus,
device and function number space, and (b) parsing the BAR values that were
pre-set by the Bhyve or Xen machinery.
"XenSupport.c" used to be listed explicitly in "Maintainers.txt", remove
it from that spot too.
Cc: Andrew Fish <afish@apple.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2122
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20210526201446.12554-33-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Leif Lindholm <leif@nuviainc.com>
This error was found while compiling VirtioMmioDeviceLib for X64
with the GCC5 toolchain, where EFIAPI makes a difference.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Message-Id: <20210602045935.762211-1-kraxel@redhat.com>
[lersek@redhat.com: prepend module name to subject, trim subject back to
allowed length]
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
The CommandLine and InitrdData may be set to NULL if the provided
size is too large. Because the zero page is mapped, this would not
cause an immediate crash but can lead to memory corruption instead.
This patch just adds validation and returns error if either allocation
has failed.
Signed-off-by: Martin Radev <martin.b.radev@gmail.com>
Message-Id: <YFPJsaGzVWQxoEU4@martin-ThinkPad-T440p>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Acked-by: Tom Lendacky <thomas.lendacky@amd.com>
[lersek@redhat.com: drop unnecessary empty line from code; remove personal
(hence likely unstable) repo reference from commit message]
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Extend parameter list of PciHostBridgeUtilityGetRootBridges() with BusMin/
BusMax, so that the utility function could be compatible with ArmVirtPkg
who uses mutable bus range [BusMin, BusMax] insteand of [0, PCI_MAX_BUS].
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3059
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Signed-off-by: Jiahui Cen <cenjiahui@huawei.com>
Message-Id: <20210119011302.10908-10-cenjiahui@huawei.com>
[lersek@redhat.com: fix logging of UINTN values BusMin, BusMax]
[lersek@redhat.com: keep zeroing of (*Count) centralized]
[lersek@redhat.com: fix typos in ExtraRootBridges comment]
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3108
In order to be able to issue messages or make interface calls that cause
another #VC (e.g. GetLocalApicBaseAddress () issues RDMSR), add support
for nested #VCs.
In order to support nested #VCs, GHCB backup pages are required. If a #VC
is received while currently processing a #VC, a backup of the current GHCB
content is made. This allows the #VC handler to continue processing the
new #VC. Upon completion of the new #VC, the GHCB is restored from the
backup page. The #VC recursion level is tracked in the per-vCPU variable
area.
Support is added to handle up to one nested #VC (or two #VCs total). If
a second nested #VC is encountered, an ASSERT will be issued and the vCPU
will enter CpuDeadLoop ().
For SEC, the GHCB backup pages are reserved in the OvmfPkgX64.fdf memory
layout, with two new fixed PCDs to provide the address and size of the
backup area.
For PEI/DXE, the GHCB backup pages are allocated as boot services pages
using the memory allocation library.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Message-Id: <ac2e8203fc41a351b43f60d68bdad6b57c4fb106.1610045305.git.thomas.lendacky@amd.com>
This patch fixes an issue with the current programming of the i440fx
PCI Interrupt routing assignment.
Explanation by Laszlo Ersek:
(1) The rotating pattern is a map:
(slot, function) --> (interrupt link) [LNKA..LNKD]
(more precisely, it is a pattern from (slot, pin) to (interrupt link),
but function<->pin is an identity mapping in the QEMU hardware, so we
can just use (slot, function) rather than (slot, pin) on the left hand
side. But I digress.)
The ACPI _PRT object is generated by QEMU; it describes this map.
(2) Another map is
(interrupt link) --> { set of possible interrupt numbers,
for this link }
This map is given by the LNK[A..D] ACPI objects, also given by QEMU.
(3) What the firmware is expected to do is:
(3a) for each interrupt link, select an *actual* interrupt from the set
that's possible for that link, yielding a deterministic map
(interrupt link) --> (actual interrupt number)
and
(3b) for each PCI device/function with an interrupt pin, resolve the
(slot, function) --> (interrupt link) --> (actual interrupt number)
functional composition, and program the result into the Interrupt Line
register of the device.
In OVMF, we do not parse the rotating map described under (1) from
QEMU's _PRT object. Instead, we duplicate the code. This is not a
problem.
In OVMF, we also do not parse the map described under (2) from QEMU's
ACPI content. Instead, we pick a specific selection (3a) that we
"apriori" know satisfies (2). This is also not a problem. OVMF's
particular selection is the PciHostIrqs table.
(
Table (2) from QEMU is
LNKA -> { 5, 10, 11 }
LNKB -> { 5, 10, 11 }
LNKC -> { 5, 10, 11 }
LNKD -> { 5, 10, 11 }
and our specific pick in OVMF, in the PciHostIrqs table, is
LNKA -> 10
LNKB -> 10
LNKC -> 11
LNKD -> 11
)
In OVMF, we also cover step (3b), in the SetPciIntLine() function.
What's missing in OVMF -- and what this patch corrects -- is that we
currently fail to program our selection for table (3) into the hardware.
We pick a specific LNKx->IRQ# mapping for each interrupt link, and we
correctly program the PCI Interrupt Line registers through those
link-to-IRQ mappings -- but we don't tell the hardware about the
link-to-IRQ mappings. More precisely, we program such a link-to-IRQ
mapping table into the hardware that is then not matched by the mapping
we use for programming the PCI device/function interrupt lines. As a
result, some PCI Interrupt Line registers will have impossible values --
a given (slot, function) may use a particular link, but also report an
interrupt number that was never picked for that link.
Output of Linux PCI Interrupt Links for i440fx before the patch:
[ 0.327305] ACPI: PCI Interrupt Link [LNKA] (IRQs 5 10 *11)
[ 0.327944] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 10 *11)
[ 0.328582] ACPI: PCI Interrupt Link [LNKC] (IRQs 5 *10 11)
[ 0.329208] ACPI: PCI Interrupt Link [LNKD] (IRQs 5 *10 11)
[ 0.329807] ACPI: PCI Interrupt Link [LNKS] (IRQs *9)
after the patch:
[ 0.327292] ACPI: PCI Interrupt Link [LNKA] (IRQs 5 *10 11)
[ 0.327934] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *10 11)
[ 0.328564] ACPI: PCI Interrupt Link [LNKC] (IRQs 5 10 *11)
[ 0.329195] ACPI: PCI Interrupt Link [LNKD] (IRQs 5 10 *11)
[ 0.329785] ACPI: PCI Interrupt Link [LNKS] (IRQs *9)
Output of Linux PCI Interrupt Links for q35 before the patch:
[ 0.307474] ACPI: PCI Interrupt Link [LNKA] (IRQs 5 *10 11)
[ 0.308027] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *10 11)
[ 0.308764] ACPI: PCI Interrupt Link [LNKC] (IRQs 5 10 *11)
[ 0.309310] ACPI: PCI Interrupt Link [LNKD] (IRQs 5 10 *11)
[ 0.309853] ACPI: PCI Interrupt Link [LNKE] (IRQs 5 *10 11)
[ 0.310508] ACPI: PCI Interrupt Link [LNKF] (IRQs 5 *10 11)
[ 0.311051] ACPI: PCI Interrupt Link [LNKG] (IRQs 5 10 *11)
[ 0.311589] ACPI: PCI Interrupt Link [LNKH] (IRQs 5 10 *11)
after the patch:
[ 0.301991] ACPI: PCI Interrupt Link [LNKA] (IRQs 5 *10 11)
[ 0.302833] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *10 11)
[ 0.303354] ACPI: PCI Interrupt Link [LNKC] (IRQs 5 10 *11)
[ 0.303873] ACPI: PCI Interrupt Link [LNKD] (IRQs 5 10 *11)
[ 0.304399] ACPI: PCI Interrupt Link [LNKE] (IRQs 5 *10 11)
[ 0.304918] ACPI: PCI Interrupt Link [LNKF] (IRQs 5 *10 11)
[ 0.305436] ACPI: PCI Interrupt Link [LNKG] (IRQs 5 10 *11)
[ 0.305954] ACPI: PCI Interrupt Link [LNKH] (IRQs 5 10 *11)
Signed-off-by: Hendrik Borghorst <hborghor@amazon.de>
Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>
Message-Id: <8dbedc4c7a1c3fd390aca915270814e3b35e13a5.camel@amazon.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
This is used to package up the grub bootloader into a firmware volume
where it can be executed as a shell like the UEFI Shell. Grub itself
is built as a minimal entity into a Fv and then added as a boot
option. By default the UEFI shell isn't built but for debugging
purposes it can be enabled and will then be presented as a boot option
(This should never be allowed for secure boot in an external data
centre but may be useful for local debugging). Finally all other boot
options except grub and possibly the shell are stripped and the boot
timeout forced to 0 so the system will not enter a setup menu and will
only boot to grub. This is done by copying the
Library/PlatformBootManagerLib into Library/PlatformBootManagerLibGrub
and then customizing it.
Boot failure is fatal to try to prevent secret theft.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3077
Signed-off-by: James Bottomley <jejb@linux.ibm.com>
Message-Id: <20201130202819.3910-4-jejb@linux.ibm.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
[lersek@redhat.com: replace local variable initialization with assignment]
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
[lersek@redhat.com: squash 'OvmfPkg: add "gGrubFileGuid=Grub" to
GuidCheck.IgnoreDuplicates', reviewed stand-alone by Phil (msgid
<e6eae551-8563-ccfb-5547-7a97da6d46e5@redhat.com>) and Ard (msgid
<10aeda37-def6-d9a4-6e02-4c66c1492f57@arm.com>)]
