Dating back to commits f5cb376703 and ddd34a8183, the
"ArmVirtPkg/ArmVirtQemu.dsc" platform includes the
"OvmfPkg/Tcg/Tcg2Config/Tcg2ConfigPei.inf" module when the TPM2_ENABLE
build flag is defined.
This was regressed in commit 8923699291, which added a Tpm12DeviceLib
dependency to Tcg2ConfigPei. "ArmVirtQemu.dsc" does not resolve that class
to any instance, so now we get a build failure:
> build.py...
> ArmVirtPkg/ArmVirtQemu.dsc(...): error 4000: Instance of library class
> [Tpm12DeviceLib] is not found
> in [OvmfPkg/Tcg/Tcg2Config/Tcg2ConfigPei.inf] [AARCH64]
> consumed by module [OvmfPkg/Tcg/Tcg2Config/Tcg2ConfigPei.inf]
The TPM-1.2 code in OvmfPkg/Tcg2ConfigPei is limited to a special use case
(a kind of physical TPM-1.2 assignment), and that has never applied to
"ArmVirtQemu.dsc".
Short-circuit the TPM-1.2 detection in the ARM/AARCH64 builds of
OvmfPkg/Tcg2ConfigPei, removing the Tpm12DeviceLib dependency.
Functionally, this patch is a no-op on IA32 / X64.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Eric Auger <eric.auger@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Simon Hardy <simon.hardy@itdev.co.uk>
Cc: Stefan Berger <stefanb@linux.ibm.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2728
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200520225841.17793-4-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Any new OVMF binary (containing commit d42fdd6f83, and built with
SMM_REQUIRE) is likely to reboot during its first boot, regardless of
whether the variable store is logically empty, or it contains a
MemoryTypeInformation variable from an earlier OVMF binary.
This "reboot on first boot after OVMF upgrade" occurs despite having
eliminated BS Code/Data tracking in earlier parts of this series. Meaning
that we've outgrown the bins of those memory types too that matter for SMM
security.
Eliminating said reboot will make an upgrade to edk2-stable202005 more
comfortable for users. Increase the defaults empirically. (The total
doesn't exceed 3MB by much.)
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2706
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200508121651.16045-5-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
The previous patch has no effect -- i.e., it cannot stop the tracking of
BS Code/Data in MemTypeInfo -- if the virtual machine already has a
MemoryTypeInformation UEFI variable.
In that case, our current logic allows the DXE IPL PEIM to translate the
UEFI variable to the HOB, and that translation is verbatim. If the
variable already contains records for BS Code/Data, the issues listed in
the previous patch persist for the virtual machine.
For this reason, *always* install PlatformPei's own MemTypeInfo HOB. This
prevents the DXE IPL PEIM's variable-to-HOB translation.
In PlatformPei, consume the records in the MemoryTypeInformation UEFI
variable as hints:
- Ignore all memory types for which we wouldn't by default install records
in the HOB. This hides BS Code/Data from any existent
MemoryTypeInformation variable.
- For the memory types that our defaults cover, enable the records in the
UEFI variable to increase (and *only* to increase) the page counts.
This lets the MemoryTypeInformation UEFI variable function as designed,
but it eliminates a reboot when such a new OVMF binary is deployed (a)
that has higher memory consumption than tracked by the virtual machine's
UEFI variable previously, *but* (b) whose defaults also reflect those
higher page counts.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2706
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200508121651.16045-3-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
OVMF booting stops with the assert if built with Xcode on macOS:
Loading driver at 0x0001FAB8000 EntryPoint=0x0001FABF249 LinuxInitrdDynamicShellCommand.efi
InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 1F218398
ProtectUefiImageCommon - 0x1F218140
- 0x000000001FAB8000 - 0x0000000000008A60
ASSERT_EFI_ERROR (Status = Unsupported)
ASSERT LinuxInitrdDynamicShellCommand.c(378): !EFI_ERROR (Status)
The assert comes from InitializeHiiPackage() after an attempt to
retrieve HII package list from ImageHandle.
Xcode still doesn't support HII resource section and
LinuxInitrdDynamicShellCommand depends on it. Likewise 277a3958d9
("OvmfPkg: Don't include TftpDynamicCommand in XCODE5 tool chain"),
disable initrd command if built with Xcode toolchain
Fixes: ec41733cfd ("OvmfPkg: add the 'initrd' dynamic shell command")
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Andrew Fish <afish@apple.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com>
Message-Id: <20200514134820.62047-1-r.bolshakov@yadro.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
The controller supports up to 8 targets in practice (Not reported by the
controller, but based on the implementation of the virtual device),
report them in GetNextTarget and GetNextTargetLun. The firmware will
then try to communicate with them and create a block device for each one
that responds.
Support for multiple LUNs will be implemented in another series.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2390
Signed-off-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200504210607.144434-7-nikita.leshchenko@oracle.com>
Add a minimal, NULL class library called "PxeBcPcdProducerLib" for setting
the "PcdIPv4PXESupport" and "PcdIPv6PXESupport" PCDs of NetworkPkg, from
fw_cfg.
These PCDs control whether the UefiPxeBcDxe driver supports PXEv4 / PXEv6
boot. If a PXE version is disabled, the corresponding LoadFile protocol
instance is not produced by UefiPxeBcDxe, and so
EfiBootManagerRefreshAllBootOption() in UefiBootManagerLib does not
generate corresponding *new* boot options either. (Existent boot options
are not deleted.)
Hook the library into the UefiPxeBcDxe driver. (The driver is already
included from "NetworkComponents.dsc.inc", but we can list it again in the
DSC file, for providing <LibraryClasses> overrides.)
In OVMF, the PCDs could be set in PlatformPei too, but ArmVirtQemu does
not have fw_cfg access in the PEI phase. Hence a NULL class library that
can be linked into UefiPxeBcDxe.
When listing the PCDs under [PcdsDynamicDefault], stick with the DEC
default values.
QEMU switches:
-fw_cfg name=opt/org.tianocore/IPv4PXESupport,string=[yn]
-fw_cfg name=opt/org.tianocore/IPv6PXESupport,string=[yn]
The "opt/org.tianocore" prefix follows the "opt/RFQDN/" recommendation
from QEMU's "docs/specs/fw_cfg.txt".
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Per Sundstrom <per_sundstrom@yahoo.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2681
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200424075353.8489-6-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Introduce DEBUG_ON_HYPERVISOR_CONSOLE build flag to enable logging
debug output to the Xen console.
This will work with both Xen HVM guest and Xen PVH guest whereas the
default PlatformDebugLibIoPort works only in HVM when QEMU is present.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Message-Id: <20200423095358.2518197-6-anthony.perard@citrix.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Remove support for DEBUG_ON_SERIAL_PORT because OvmfXen can't be build
with it due to a circular dependency:
DebugLib : BaseDebugLibSerialPort ->
SerialPortLib : XenConsoleSerialPortLib ->
XenHypercallLib : XenHypercallLib ->
DebugLib
Also, if that dependency is fixed, I think it would be harder to find
which console the debug is sent to when running an HVM guest. The xen
console isn't the serial console used by default. Furthermore,
XenHypercallLib isn't initialised early enough, so we would loose
debug output from the SEC phase and early PEI phase.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200423095358.2518197-2-anthony.perard@citrix.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
The BaseResetSystemLib instance is not suitable for OS runtime, because
its ResetShutdown() implementation calls PciRead16 (OVMF_HOSTBRIDGE_DID).
On q35, this boils down to a memory-mapped config space access -- but we
never ask the OS to map MMCONFIG for runtime.
There are at least three alternatives to approach this:
(1) Investigate "MdePkg/Library/DxeRuntimePciExpressLib", which offers
some kind of runtime mapping for MMCONFIG.
(2) Consume PciCf8Lib directly, rather than PciLib, in ResetSystemLib.
Then we'll read OVMF_HOSTBRIDGE_DID from the config space with IO port
accesses on q35 too, not just on i440fx. IO ports don't depend on page
tables.
(3) In the lib constructor, cache "mAcpiPmBaseAddress" based on
"PcdOvmfHostBridgePciDevId" (which is set by PlatformPei). Then the
host bridge type will be known at runtime without PCI config space
accesses.
This patch follows approach (3), in order to mirror AcpiTimerLib.
Notes:
* This patch is best viewed with "git show --find-copies-harder -C43".
* PCDs are not usable in the DXE_CORE, as the PCD PPI is gone, and the PCD
protocol is not available yet. (The DXE_CORE does consume ResetSystemLib
in practice, when OVMF is built with -D SOURCE_DEBUG_ENABLE.)
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien@xen.org>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Rebecca Cran <rebecca@bsdio.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2675
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200417153751.7110-7-lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
[lersek@redhat.com: move third Note (with repro info) to BZ comment]
Move the ResetShutdown() definition to its own file. This will help us
introduce:
- a new library instance that is not broken in runtime modules (the
current library instance is broken in runtime modules),
- another new library instance for bhyve support.
While at it, squash AcpiPmControl() into ResetShutdown(), open-coding
SuspendType=0. This is justified because we've had no other callers for
AcpiPmControl() since commit 2d9950a2bf ("OvmfPkg: remove
EnterS3WithImmediateWake () from ResetSystemLib", 2020-01-10).
Tested with the "reset -s" UEFI shell command, on both i440fx and q35.
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Rebecca Cran <rebecca@bsdio.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2675
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200417153751.7110-5-lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
Annotate the #include directives with the interfaces that this lib
instance needs from the included lib class headers. This will help us keep
the #include set minimal, when we move code around later.
While at it, synchronize the [LibraryClasses] section with the #include
directives -- list BaseLib.
Also #include the ResetSystemLib class header, which declares the
interfaces that this lib instance implements.
This forces us to spell out the "MdeModulePkg.dec" dependency too, under
[Packages].
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Rebecca Cran <rebecca@bsdio.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2675
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200417153751.7110-3-lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
Previous to this change, PvScsiFreeRings() was not undoing all
operations that was done by PvScsiInitRings().
This is because PvScsiInitRings() was both preparing rings (Allocate
memory and map it for device DMA) and setup the rings against device by
issueing a device command. While PvScsiFreeRings() only unmaps the rings
and free their memory.
Driver do not have a functional error as it makes sure to reset device
before every call site to PvScsiFreeRings(). However, this is not
intuitive.
Therefore, prefer to refactor the setup of the ring against device to a
separate function than PvScsiInitRings().
Signed-off-by: Liran Alon <liran.alon@oracle.com>
Message-Id: <20200331225637.123318-1-liran.alon@oracle.com>
[lersek@redhat.com: rename FreeDMACommBuffer label to FreeDmaCommBuffer]
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
