When the Xen PVH entry point has been used, hvmloader hasn't run and
hasn't prepared an E820 table. The only way left to get an E820 table
is to ask Xen via an hypercall. We keep the result cached to avoid
making a second hypercall which would give the same result.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20190813113119.14804-23-anthony.perard@citrix.com>
The informations to make a XENMEM_memory_map hypercall is copied over
from the public header of the Xen Project, with the type name modified
to build on OVMF.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20190813113119.14804-22-anthony.perard@citrix.com>
XenPvhDetected() can be used to figure out if OVMF has started via the
Xen PVH entry point.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20190813113119.14804-21-anthony.perard@citrix.com>
We are going to need to make an hypercall in order to retreive the E820
table from the hypervisor before been able to setup the memory.
Calling XenConnect earlier will allow to setup the XenHypercallLib
earlier to allow to make hypercalls.
While here, add some comments in XenConnect().
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20190813113119.14804-20-anthony.perard@citrix.com>
This new XenHvmloaderDetected() return true if the hvmloader firmware
has runned before OVMF.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20190813113119.14804-19-anthony.perard@citrix.com>
The XenPlatformPei needs to make hypercalls, but the XenHypercallLib was
initialised before the HyperPage was ready. Now that XenPlatformPei has
initialised the HyperPage, reinitialise the XenHypercallLib.
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-18-anthony.perard@citrix.com>
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>
If the firmware have been started via the Xen PVH entry point, a RSDP
pointer would have been provided. Use it.
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-16-anthony.perard@citrix.com>
This patch replace the XenDetected() function by the one 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-15-anthony.perard@citrix.com>
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>
Check if there's a start of the day struct provided to PVH guest, save
the ACPI RSDP address for later.
This patch import import arch-x86/hvm/start_info.h from xen.git.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20190813113119.14804-13-anthony.perard@citrix.com>
Use the already checked pointer mXenHvmloaderInfo to retrieve the E820
table produced by hvmloader.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20190813113119.14804-12-anthony.perard@citrix.com>
EFI_XEN_OVMF_INFO is only useful to retrieve the E820 table. The
mXenHvmloaderInfo isn't used yet, but will be use in a further patch to
retrieve the E820 table.
Also remove the unused pointer from the XenInfo HOB as that information
is only useful in the XenPlatformPei.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20190813113119.14804-11-anthony.perard@citrix.com>
The ACPI Timer isn't present in a PVH guest, but local APIC works on
both PVH and HVM.
Note that the use of SecPeiDxeTimerLibCpu might be an issue with a
driver of type DXE_RUNTIME_DRIVER. I've attempted to find out which of
the DXE_RUNTIME_DRIVER uses the TimerLib at runtime. I've done that by
replacing the TimerLib evaluation in
[LibraryClasses.common.DXE_RUNTIME_DRIVER] by a different one and
checking every module that uses it (with the --report-file=report
build option).
ResetSystemRuntimeDxe is calling the TimerLib API at runtime to do the
operation "EfiResetCold", so this may never complete if the OS have
disabled the Local APIC Timer.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20190813113119.14804-10-anthony.perard@citrix.com>
This patch allows the ResetVector to be run indenpendently from build
time addresses.
The goal of the patch is to avoid having to create RAM just below 4G
when creating a Xen PVH guest while being compatible with the way
hvmloader currently load OVMF, just below 4G.
Only the new PVH entry point will do the calculation.
The ResetVector will figure out its current running address by creating
a temporary stack, make a call and calculate the difference between the
build time address and the address at run time.
This patch copies and make the necessary modification to some other asm
files:
- copy of UefiCpuPkg/.../Flat32ToFlat64.asm:
Allow Transition32FlatTo64Flat to be run from anywhere in memory
- copy of UefiCpuPkg/../SearchForBfvBase.asm:
Add a extra parameter to indicate where to start the search for the
boot firmware volume.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20190813113119.14804-9-anthony.perard@citrix.com>
As described in the Xen PVH documentation [1], "ebx: contains the
physical memory address where the loader has placed the boot start info
structure". To have this pointer saved to be able to use it later in the
PEI phase, we allocate some space in the MEMFD for it. We use 'XPVH' as
a signature (for "Xen PVH").
[1] https://xenbits.xenproject.org/docs/unstable/misc/pvh.html
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20190813113119.14804-8-anthony.perard@citrix.com>
Add a new entry point for Xen PVH that enter directly in 32bits.
Information on the expected state of the machine when this entry point
is used can be found at:
https://xenbits.xenproject.org/docs/unstable/misc/pvh.html
Also, compare to the original file [1], the two `nop' of the "resetVector"
entry point are removed. There were introduced by 8332983e2e
("UefiCpuPkg: Replace the un-necessary WBINVD instruction at the reset
vector with two NOPs in VTF0.", 2011-08-04), but don't seems to be
useful. This is the entry point used by HVM guest (hvmloader).
[1] UefiCpuPkg/ResetVector/Vtf0/Ia16/ResetVectorVtf0.asm
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20190813113119.14804-7-anthony.perard@citrix.com>
This patch changes the flash device image of OvmfXen to make it look
like it's an ELF. For this, we replace the empty embedded variable store
by a binary array, which is a ELF file header.
The ELF header explain to a loader to load the binary at the address
1MB, then jump to the PVH entry point which will be created in a later
patch. The header also includes a Xen ELF note that is part of the
PVH ABI.
That patch include OvmfXenElfHeaderGenerator.c which can be use to
regenerate the ELF header, but this will be a manual step.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20190813113119.14804-6-anthony.perard@citrix.com>
Introduce XenPlatformPei, a copy of OvmfPkg/PlatformPei without some
of QEMU specific initialization, Xen does not support QemuFwCfg.
This new module will be adjusted to accommodate Xen PVH.
fw_cfg dependents that have been removed, which are dynamically skipped
when running PlatformPei on Xen:
- GetFirstNonAddress(): controlling the 64-bit PCI MMIO aperture via the
(experimental) "opt/ovmf/X-PciMmio64Mb" file
- GetFirstNonAddress(): honoring the hotplug DIMM area
("etc/reserved-memory-end") in the placement of the 64-bit PCI MMIO
aperture
- NoexecDxeInitialization() is removed, so PcdPropertiesTableEnable and
PcdSetNxForStack are left constant FALSE (not set dynamically from
fw_cfg "opt/ovmf/PcdXxxx")
- MaxCpuCountInitialization(), PublishPeiMemory(): the max CPU count is
not taken from the QemuFwCfgItemSmpCpuCount fw_cfg key;
PcdCpuMaxLogicalProcessorNumber is used intact and
PcdCpuApInitTimeOutInMicroSeconds is never changed or used.
- InitializeXenPlatform(), S3Verification(): S3 is assumed disabled (not
consulting "etc/system-states" via QemuFwCfgS3Enabled()).
- InstallFeatureControlCallback(): the feature control MSR is not set
from "etc/msr_feature_control"
(also removed FeatureControl.c as there is nothing been executed)
Also removed:
- SMRAM/TSEG-related low mem size adjusting (PcdSmmSmramRequire is
assumed FALSE) in PublishPeiMemory(),
- QemuInitializeRam() entirely,
Xen related changes:
- Have removed the module variable mXen, as it should be always true.
- Have the platform PEI initialization fails if Xen has not been
detected.
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-5-anthony.perard@citrix.com>
Introduce XenResetVector, a copy of OvmfPkg/ResetVector, with one
changes:
- SEC_DEFAULT_CR0: enable cache (bit 30 or CD set to 0)
Xen copies the OVMF code to RAM, there is no need to disable cache.
This new module will later be modified to add a new entry point, more
detail in a following commit "OvmfPkg/XenResetVector: Add new entry point
for Xen PVH"
Value FILE_GUID of XenResetVector have not changed compare to ResetVector
because it is a special value (gEfiFirmwareVolumeTopFileGuid).
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-4-anthony.perard@citrix.com>
OvmfXen is a copy of OvmfX64, removing VirtIO and some SMM.
This new platform will be changed to make it works on two types of Xen
guest: HVM and PVH.
Compare to OvmfX64, this patch:
- changed: PLATFORM_GUID, OUTPUT_DIRECTORY, FLASH_DEFINITION
- removed: VirtioLib class resolution
- removed: all UEFI_DRIVER modules for virtio devices
- removed: DXE_SMM_DRIVER and SMM_CORE lib class resolutions
- removed: DXE_SMM_DRIVER and SMM_CORE FDF rules
- removed: Everything related to SMM_REQUIRE==true
- removed: Everything related to SECURE_BOOT_ENABLE==true
- removed: Everything related to TPM2_ENABLE==true
- changed: PcdPciDisableBusEnumeration dynamic default flipped to TRUE
- changed: default FD_SIZE_IN_KB to 2M.
- reverted d272449d9e, "OvmfPkg: raise DXEFV size to 11 MB"
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-3-anthony.perard@citrix.com>
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>
Change referenced MSR name to avoid later build failure.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Specify the firmware to use via the newer '-drive if=pflash' syntax
which allows specifying the raw format parameter. This
avoids warnings with newer version of QEMU.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
$ADD_QEMU_HDA was added because QEMU used to refuse to run without a
disk. Since newer versions run without any disks, remove it.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Enable multithreaded builds by default when building OvmfPkg
using build.sh.
This can drastically reduce build times. For example, on a
modern ThreadRipper system the time required to build decreases
from 3 minutes to 1 minute.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1781
GITHUB: https://github.com/idesai/edk2/tree/enable_sm3_measured_boot_v6
EDK2 Support for SM3 digest algorithm is needed to enable TPM with SM3 PCR
banks. This digest algorithm is part of the China Crypto algorithm suite.
This integration has dependency on the openssl_1_1_1b integration into
edk2.
This patch links SM3 support into Tcg2Pei and Tcg2Dxe.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Cc: Stefan Berger <stefanb@linux.ibm.com>
Signed-off-by: Imran Desai <imran.desai@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20190718225326.40839-5-imran.desai@intel.com>
Acked-by: Jiewen Yao <jiewen.yao@intel.com>
This reverts commit a7c7d21ffa.
The reason is that said commit had not been reviewed by OvmfPkg
maintainers/reviewers, before it was pushed.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Imran Desai <imran.desai@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Cc: Stefan Berger <stefanb@linux.ibm.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1781
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
(a) OvmfPkg first had to resolve the TpmMeasurementLib class -- for
SECURE_BOOT_ENABLE only -- when the DxeImageVerificationLib instance
became dependent on TpmMeasurementLib. For details, refer to commit
0d28d286bf ("OvmfPkg: resolve TpmMeasurementLib dependency
introduced in r14687", 2013-09-21).
(b) At the time, only one instance of TpmMeasurementLib existed, namely
DxeTpmMeasurementLib. This lib instance didn't do anything -- like it
was desirable for OVMF --, because OVMF didn't include any Tcg / TrEE
protocol implementations.
(c) In commit 308521b133 ("MdeModulePkg: Move TpmMeasurementLib
LibraryClass from SecurityPkg", 2015-07-01), TpmMeasurementLibNull was
introduced.
(d) In commit 285542ebbb ("OvmfPkg: Link AuthVariableLib for following
merged variable driver deploy", 2015-07-01), a TpmMeasurementLib
resolution became necessary regardless of SECURE_BOOT_ENABLE. And so
TpmMeasurementLib was resolved to TpmMeasurementLibNull in OVMF, but
only in the non-SECURE_BOOT_ENABLE case. This step -- possibly, the
larger series containing commit 285542ebbb -- missed an opportunity
for simplification: given (b), the DxeTpmMeasurementLib instance
should have been simply replaced with the TpmMeasurementLibNull
instance, regardless of SECURE_BOOT_ENABLE.
(e) In commit 1abfa4ce48 ("Add TPM2 support defined in trusted computing
group.", 2015-08-13), the TrEE dependency was replaced with a Tcg2
dependency in DxeTpmMeasurementLib.
(f) Starting with commit 0c0a50d6b3 ("OvmfPkg: include Tcg2Dxe module",
2018-03-09), OVMF would include a Tcg2 protocol implementation,
thereby satisfying DxeTpmMeasurementLib's dependency. With
TPM2_ENABLE, it would actually make sense to consume
DxeTpmMeasurementLib -- however, DxeTpmMeasurementLib would never be
used without SECURE_BOOT_ENABLE.
Therefore, we have the following four scenarios:
- TPM2_ENABLE + SECURE_BOOT_ENABLE: works as expected.
- Neither enabled: works as expected.
- Only TPM2_ENABLE: this build is currently incorrect, because
Variable/RuntimeDxe consumes TpmMeasurementLib directly, but
TpmMeasureAndLogData() will never reach the TPM because we link
TpmMeasurementLibNull into the variable driver. This is a problem from
the larger series containing (f).
- Only SECURE_BOOT_ENABLE: this build works as expected, but it is
wasteful -- given that the protocol database will never contain Tcg2
without TPM2_ENABLE, we should simply use TpmMeasurementLibNull. This is
a problem from (d).
Resolving TpmMeasurementLib to DxeTpmMeasurementLib as a function of
*only* TPM2_ENABLE, we can fix / optimize the last two cases.
v2:
- Amend the title and description suggested by Laszlo
- Move TpmMeasurementLib to the existed TPM2_ENABLE block
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Cc: Stefan Berger <stefanb@linux.ibm.com>
Signed-off-by: Gary Lin <glin@suse.com>
Message-Id: <20190704040731.5303-1-glin@suse.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1781
EDK2 Support for SM3 digest algorithm is needed to enable TPM with SM3 PCR
banks. This digest algorithm is part of the China Crypto algorithm suite.
This integration has dependency on the openssl_1_1_1b integration into
edk2.
This patch links SM3 support into Tcg2Pei and Tcg2Dxe.
Signed-off-by: Imran Desai <imran.desai@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Cc: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: jiewen.yao@intel.com
Calling DisconnectController() on children isn't part of the job of
EFI_DRIVER_BINDING_PROTOCOL.Stop() as it only needs to deallocate
resources allocated in Start(). The disconnection will happen when
both DevicePath and XenBus protocols gets uninstalled.
Reported-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Message-Id: <20190701111403.7007-1-anthony.perard@citrix.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
In XenBusDxe, the XenBusAddDevice() opens the gXenIoProtocolGuid on
behalf of child controllers. It is never closed and prevents us from
uninstalling the protocol.
Close it where we stop all the children in XenBusDxe->Stop().
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20190701105012.25758-1-anthony.perard@citrix.com>
Mostly, this is only necessary for devices that the CSM might have
native support for, such as VirtIO and NVMe; PciBusDxe will already
degrade devices to 32-bit if they have an OpROM.
However, there doesn't seem to be a generic way of requesting PciBusDxe
to downgrade specific devices.
There's IncompatiblePciDeviceSupportProtocol but that doesn't provide
the PCI class information or a handle to the device itself, so there's
no simple way to just match on all NVMe devices, for example.
Just leave gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Size set to zero for
CSM builds, until/unless that can be fixed.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20190626113742.819933-5-dwmw2@infradead.org>
QemuVideoDxe installs its own legacy INT 10h handler for the benefit of
systems like Windows 2008r2 which attempt to use INT 10h even when booted
via EFI.
This interacts extremely badly with a CSM actually attempting to install
a real video BIOS.
The last thing done before invoking a legacy OpROM is to call INT 10h to
set a plain text mode. In the case where it's the video BIOS OpROM being
loaded, INT 10h will normally point to an iret stub in the CSM itself.
Unless QemuVideoDxe has changed INT10h to point to a location in the
0xC0000 segment that it didn't allocate properly, so the real OpROM has
been shadowed over them top of it, and the INT 10h vector now points to
some random place in the middle of the newly-shadowed OpROM.
Don't Do That Then. QemuVideoDxe doesn't do any acceleration and just
sets up a linear framebuffer, so we don't lose much by just
unconditionally using BiosVideoDxe instead when CSM is present.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20190626113742.819933-4-dwmw2@infradead.org>
Iterate over the available block devices in much the same way as
BdsLibEnumerateAllBootOption() does, but limiting to those devices
which are PCI-backed, which can be represented in the BbsTable.
One day we might need to extend the BbsTable to allow us to distinguish
between different NVMe namespaces on a device.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20190626113742.819933-3-dwmw2@infradead.org>
This is hard-coded in the IntThunk structure, and the additional entries
will be needed for other devices like VirtIO and NVMe disks. So admit
that they exist.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20190626113742.819933-2-dwmw2@infradead.org>
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>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1843
This commit will update the INF file of the CsmSupportLib to drop its
dependency on IntelFrameworkPkg:
gEfiLegacyBiosPlatformProtocolGuid
gEfiLegacyBiosProtocolGuid
gEfiLegacyInterruptProtocolGuid
The above dependencies have already been addressed by the duplication of
these definitions from IntelFrameworkPkg to OvmfPkg.
Cc: Ray Ni <ray.ni@intel.com>
Cc: David Woodhouse <dwmw2@infradead.org>
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>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1843
This commit will drop the driver's dependency on the IntelFrameworkPkg:
gEfiLegacyBiosProtocolGuid
Such dependency has already been addressed by the duplication of the above
definition from IntelFrameworkPkg into the OvmfPkg.
Cc: Ray Ni <ray.ni@intel.com>
Cc: David Woodhouse <dwmw2@infradead.org>
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>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1843
For the driver's INF file, this commit will remove the redundant reference
to 'IntelFrameworkModulePkg/IntelFrameworkModulePkg.dec'.
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>
The DX register is supposed to contain the required alignment for the
allocation. It was zero, and SeaBIOS doesn't (well, didn't) cope well
with that. Set it appropriately.
Also set BX to indicate the regions it's OK to allocate in too. That
wasn't being initialised and was just using whatever the previous user
of the structure had left there.
Finally, actually return an error if the allocation fails. Instead of
going all the way through into the CSM and just letting it have a bogus
pointer to the E820 data.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1811
This commit updates the OVMF DSC/FDF files to consume the copied CSM
components within OvmfPkg.
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: David Woodhouse <dwmw2@infradead.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1811
This commit will update the library's INF file to:
A) Assign a new file GUID;
B) Remove the IntelFramework[Module]Pkg DEC file dependency.
Please note that a subsequent commit (final patch of the series) will:
Replace the use of LegacyBootManagerLib in IntelFrameworkModulePkg with
the one copied in OvmfPkg within DSC files.
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: David Woodhouse <dwmw2@infradead.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1811
This commit will update the library's INF file to:
A) Assign a new file GUID;
B) Remove the IntelFramework[Module]Pkg DEC file dependency.
Please note that a subsequent commit (final patch of the series) will:
Replace the use of LegacyBootMaintUiLib in IntelFrameworkModulePkg with
the one copied in OvmfPkg within DSC files.
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: David Woodhouse <dwmw2@infradead.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1811
This commit will update the driver's INF file to:
A) Assign a new file GUID;
B) Consume the PCDs duplicated in OvmfPkg DEC file;
C) Remove the IntelFramework[Module]Pkg DEC file dependency.
Please note that a subsequent commit (final patch of the series) will:
Replace the use of LegacyBiosDxe in IntelFrameworkModulePkg with the one
copied in OvmfPkg within DSC/FDF files.
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: David Woodhouse <dwmw2@infradead.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1811
This commit will update the driver's INF file to:
A) Assign a new file GUID;
B) Consume the PCDs duplicated in OvmfPkg DEC file;
C) Remove the IntelFramework[Module]Pkg DEC file dependency.
Please note that a subsequent commit (final patch of the series) will:
Replace the use of VideoDxe in IntelFrameworkModulePkg with the one copied
in OvmfPkg within DSC/FDF files.
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: David Woodhouse <dwmw2@infradead.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1811
This commit will add the PCD definitions consumed by the duplicated
drivers:
* VideoDxe
* LegacyBiosDxe
into the OvmfPkg DEC file.
Please note that, instead of adding these PCDs under section:
[PcdsFixedAtBuild, PcdsDynamic, PcdsDynamicEx, PcdsPatchableInModule]
as in IntelFrameworkModulePkg.dec file, they are added in section:
[PcdsFixedAtBuild]
in OvmfPkg.dec instead.
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: David Woodhouse <dwmw2@infradead.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1811
The previous file-duplication commit has put all the CSM related header
files within folder: OvmfPkg/Csm/Inclue.
This commit will update the DEC file to add that folder under the
'[Include]' section.
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: David Woodhouse <dwmw2@infradead.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1811
This commit will add the Guid definitions of the duplicated CSM-related
Guids and Protocols from IntelFramework[Module]Pkg.
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: David Woodhouse <dwmw2@infradead.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
The following network build flags changed due to the inclusion of
NetworkPkg/Network.fdf.inc.
HTTP_BOOT_ENABLE -> NETWORK_HTTP_BOOT_ENABLE
TLS_ENABLE -> NETWORK_TLS_ENABLE
This commit also adds NETWORK_ALLOW_HTTP_CONNECTIONS to reflect the
change in OvmfPkg/OvmfPkg*.dsc.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1884
Signed-off-by: Gary Lin <glin@suse.com>
Message-Id: <20190610065509.19573-1-glin@suse.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1842
According to the discussion at:
https://edk2.groups.io/g/devel/topic/30918343#38093
For OVMF, we keep both ISA stacks:
* The legacy one in PcAtChipsetPkg/IntelFrameworkModulePkg
* The Sio bus based OVMF-specified one introduced by commit a5cc178aeb
for a period of time (includes 1 stable tag: edk2-stable201905). And we
also keep the Sio bus based OVMF-specified stack as the default one (via a
build option 'USE_LEGACY_ISA_STACK') to validate its stability.
This commit will propose to drop the legacy ISA stack from OVMF and remove
the usage of the build flag 'USE_LEGACY_ISA_STACK' at the same time. This
is considered as a preparation for the removal of
PcAtChipsetPkg/IsaAcpiDxe & IntelFrameworkModulePkg.
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>
Query the supported attributes firstly, then bitwise AND (&) both VGA_IO
and VGA_IO_16. Since the supported attributes should only have one of
VGA_IO or VGA_IO_16 set, the result of bitwise AND (&) is either VGA_IO
or IO_16. Then the result can be passed to PciIo->Attributes() to set the
attributes.
Device driver should consider both since the mReserveVgaAliases in
PciBusDxe driver is default FALSE(implies that device driver can only set
VGA_IO_16 to PCI_ROOT_BRIDGE), and Platform code may not return
EFI_RESERVE_VGA_IO_ALIAS in GetPlatformPolicy of PciPlatformProtocol to
make mReserveVgaAliases become TRUE(implies that device driver can only
set VGA_IO to PCI_ROOT_BRIDGE), Currently OvmfPkg doesn't have problem
due to it has hard code value for PCI_ROOT_BRIDGE's attributes field, so
an IO access by PciIoProtocol will be successed due to
RootBridgeIoCheckParameter of PciRootBridgeIo.c will always get pass
result for legacy IO access.
Usually the attributes field of PCI_ROOT_BRIDGE should be 0, in that case
it will have issue since the VGA_IO may not be able to be enabled, then
IO access by PciIoProtocol will be failed, hence the QemuVideoDxe driver
will not work fine.
Signed-off-by: Marc Chen <marc.w.chen@intel.com>
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: Marc-André Lureau <marcandre.lureau@redhat.com>
Cc: Stefan Berger <stefanb@linux.ibm.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1880
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20190606074237.81492-1-marc.w.chen@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
(This is a replacement for commit 39b9a5ffe6 ("OvmfPkg/PlatformPei: fix
MTRR for low-RAM sizes that have many bits clear", 2019-05-16).)
Reintroduce the same logic as seen in commit 39b9a5ffe6 for the pc
(i440fx) board type.
For q35, the same approach doesn't work any longer, given that (a) we'd
like to keep the PCIEXBAR in the platform DSC a fixed-at-build PCD, and
(b) QEMU expects the PCIEXBAR to reside at a lower address than the 32-bit
PCI MMIO aperture.
Therefore, introduce a helper function for determining the 32-bit
"uncacheable" (MMIO) area base address:
- On q35, this function behaves statically. Furthermore, the MTRR setup
exploits that the range [0xB000_0000, 0xFFFF_FFFF] can be marked UC with
just two variable MTRRs (one at 0xB000_0000 (size 256MB), another at
0xC000_0000 (size 1GB)).
- On pc (i440fx), the function behaves dynamically, implementing the same
logic as commit 39b9a5ffe6 did. The PciBase value is adjusted to the
value calculated, similarly to commit 39b9a5ffe6. A further
simplification is that we show that the UC32 area size truncation to a
whole power of two automatically guarantees a >=2GB base address.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1859
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
(This is a replacement for commit 75136b2954, "OvmfPkg/PlatformPei:
reorder the 32-bit PCI window vs. the PCIEXBAR on q35", 2019-05-16).
Commit 7b8fe63561 ("OvmfPkg: PlatformPei: enable PCIEXBAR (aka MMCONFIG
/ ECAM) on Q35", 2016-03-10) claimed that,
On Q35 machine types that QEMU intends to support in the long term, QEMU
never lets the RAM below 4 GB exceed 2 GB.
Alas, this statement came from a misunderstanding that occurred while we
worked out the interface contract. In fact QEMU does allow the 32-bit RAM
extend up to 0xB000_0000 (exclusive), in case the RAM size falls in the
range (0x8000_0000, 0xB000_0000) (i.e., the RAM size is greater than
2048MB and smaller than 2816MB).
In turn, such a RAM size (justifiedly) triggers
ASSERT (TopOfLowRam <= PciExBarBase);
in MemMapInitialization(), because we placed the 256MB PCIEXBAR at
0x8000_0000 (2GB) exactly, relying on the interface contract. (And, the
32-bit PCI window would follow the PCIEXBAR, covering the [0x9000_0000,
0xFC00_0000) range.)
In order to fix this, place the PCIEXBAR at 2816MB (0xB000_0000), and
start the 32-bit PCI window at 3 GB (0xC000_0000). This shrinks the 32-bit
PCI window to
0xFC00_0000 - 0xC000_0000 = 0x3C00_0000 = 960 MB.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1859
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
This reverts commit 60e95bf509.
The original fix for <https://bugzilla.tianocore.org/show_bug.cgi?id=1814>
triggered a bug / incorrect assumption in QEMU.
QEMU assumes that the PCIEXBAR is below the 32-bit PCI window, not above
it. When the firmware doesn't satisfy this assumption, QEMU generates an
\_SB.PCI0._CRS object in the ACPI DSDT that does not reflect the
firmware's 32-bit MMIO BAR assignments. This causes OSes to re-assign
32-bit MMIO BARs.
Working around the problem in the firmware looks less problematic than
fixing QEMU. Revert the original changes first, before implementing an
alternative fix.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1859
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
This reverts commit 9a2e8d7c65.
The original fix for <https://bugzilla.tianocore.org/show_bug.cgi?id=1814>
triggered a bug / incorrect assumption in QEMU.
QEMU assumes that the PCIEXBAR is below the 32-bit PCI window, not above
it. When the firmware doesn't satisfy this assumption, QEMU generates an
\_SB.PCI0._CRS object in the ACPI DSDT that does not reflect the
firmware's 32-bit MMIO BAR assignments. This causes OSes to re-assign
32-bit MMIO BARs.
Working around the problem in the firmware looks less problematic than
fixing QEMU. Revert the original changes first, before implementing an
alternative fix.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1859
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
This reverts commit 75136b2954.
The original fix for <https://bugzilla.tianocore.org/show_bug.cgi?id=1814>
triggered a bug / incorrect assumption in QEMU.
QEMU assumes that the PCIEXBAR is below the 32-bit PCI window, not above
it. When the firmware doesn't satisfy this assumption, QEMU generates an
\_SB.PCI0._CRS object in the ACPI DSDT that does not reflect the
firmware's 32-bit MMIO BAR assignments. This causes OSes to re-assign
32-bit MMIO BARs.
Working around the problem in the firmware looks less problematic than
fixing QEMU. Revert the original changes first, before implementing an
alternative fix.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1859
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
This reverts commit 39b9a5ffe6.
The original fix for <https://bugzilla.tianocore.org/show_bug.cgi?id=1814>
triggered a bug / incorrect assumption in QEMU.
QEMU assumes that the PCIEXBAR is below the 32-bit PCI window, not above
it. When the firmware doesn't satisfy this assumption, QEMU generates an
\_SB.PCI0._CRS object in the ACPI DSDT that does not reflect the
firmware's 32-bit MMIO BAR assignments. This causes OSes to re-assign
32-bit MMIO BARs.
Working around the problem in the firmware looks less problematic than
fixing QEMU. Revert the original changes first, before implementing an
alternative fix.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1859
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Assume that we boot OVMF in a QEMU guest with 1025 MB of RAM. The
following assertion will fire:
> ASSERT_EFI_ERROR (Status = Out of Resources)
> ASSERT OvmfPkg/PlatformPei/MemDetect.c(696): !EFI_ERROR (Status)
That's because the range [1025 MB, 4 GB) that we try to mark as
uncacheable with MTRRs has size 3071 MB:
0x1_0000_0000
-0x0_4010_0000
--------------
0x0_BFF0_0000
The integer that stands for the uncacheable area size has 11 (eleven) bits
set to 1. As a result, covering this size requires 11 variable MTRRs (each
MTRR must cover a naturally aligned, power-of-two sized area). But, if we
need more variable MTRRs than the CPU can muster (such as 8), then
MtrrSetMemoryAttribute() fails, and we refuse to continue booting (which
is justified, in itself).
Unfortunately, this is not difficult to trigger, and the error message is
well-hidden from end-users, in the OVMF debug log. The following
mitigation is inspired by SeaBIOS:
Truncate the uncacheable area size to a power-of-two, while keeping the
end fixed at 4 GB. Such an interval can be covered by just one variable
MTRR.
This may leave such an MMIO gap, between the end of low-RAM and the start
of the uncacheable area, that is marked as WB (through the MTRR default).
Raise the base of the 32-bit PCI MMIO aperture accordingly -- the gap will
not be used for anything.
On Q35, the minimal 32-bit PCI MMIO aperture (triggered by RAM size 2815
MB) shrinks from
0xE000_0000 - 0xAFF0_0000 = 769 MB
to
0xE000_0000 - 0xC000_0000 = 512 MB
On i440fx, the minimal 32-bit PCI MMIO aperture (triggered by RAM size
3583 MB) shrinks from
0xFC00_0000 - 0xDFF0_0000 = 449 MB
to
0xFC00_0000 - 0xE000_0000 = 448 MB
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1814
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1666941
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1701710
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Commit 7b8fe63561 ("OvmfPkg: PlatformPei: enable PCIEXBAR (aka MMCONFIG
/ ECAM) on Q35", 2016-03-10) claimed that,
On Q35 machine types that QEMU intends to support in the long term, QEMU
never lets the RAM below 4 GB exceed 2 GB.
Alas, this statement came from a misunderstanding that occurred while we
worked out the interface contract. In fact QEMU does allow the 32-bit RAM
extend up to 0xB000_0000 (exclusive), in case the RAM size falls in the
range (0x8000_0000, 0xB000_0000) (i.e., the RAM size is greater than
2048MB and smaller than 2816MB).
In turn, such a RAM size (justifiedly) triggers
ASSERT (TopOfLowRam <= PciExBarBase);
in MemMapInitialization(), because we placed the 256MB PCIEXBAR at
0x8000_0000 (2GB) exactly, relying on the interface contract. (And, the
32-bit PCI window would follow the PCIEXBAR, covering the [0x9000_0000,
0xFC00_0000) range.)
In order to fix this, reorder the 32-bit PCI window against the PCIEXBAR,
as follows:
- start the 32-bit PCI window where it starts on i440fx as well, that is,
at 2GB or TopOfLowRam, whichever is higher;
- unlike on i440fx, where the 32-bit PCI window extends up to 0xFC00_0000,
stop it at 0xE000_0000 on q35,
- place the PCIEXBAR at 0xE000_0000.
(We cannot place the PCIEXBAR at 0xF000_0000 because the 256MB MMIO area
that starts there is not entirely free.)
Before this patch, the 32-bit PCI window used to only *end* at the same
spot (namely, 0xFC00_0000) between i440fx and q35; now it will only
*start* at the same spot (namely, 2GB or TopOfLowRam, whichever is higher)
between both boards.
On q35, the maximal window shrinks from
0xFC00_0000 - 0x9000_0000 = 0x6C00_0000 == 1728 MB
to
0xE000_0000 - 0x8000_0000 == 1536 MB.
We lose 192 MB of the aperture; however, the aperture is now aligned at
1GB, rather than 256 MB, and so it could fit a 1GB BAR even.
Regarding the minimal window (triggered by RAM size 2815MB), its size is
0xE000_0000 - 0xAFF0_0000 = 769 MB
which is not great, but probably better than a failed ASSERT.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1814
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1666941
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1701710
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
In the MemMapInitialization() function, we currently assign PciBase
different values, on both branches of the board type check. Hoist the
PciBase assignment from the i440fx branch in front of the "if". This is a
no-op for the i440fx branch. On the q35 branch, we overwrite this value,
hence the change is a no-op on q35 as well.
This is another refactoring for simplifying the rest of this series.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1814
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1666941
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1701710
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
In the MemMapInitialization() function, we currently have a common
PciSize assignment, shared between i440fx and q35. In order to simplify
the rest of this series, lift and duplicate the assignment identically to
both board-specific branches.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1814
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1666941
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1701710
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
This patch updates the platform DSC/FDF files to use the include fragment
files provided by NetworkPkg.
The feature enabling flags in [Defines] section have been updated to use
the NetworkPkg's terms, and the value has been overridden with the original
default value on this platform.
v2:1.Make the comments before Network definition align other parts.
2.Set NETWORK_ALLOW_HTTP_CONNECTIONS true.
3.Remove TcpIoLib in lib classes section.
4.Withdraw the removal of [PcdsFixedAtBuild.X64].
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@linaro.org>
Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com>
Message-Id: <20190516081810.27840-2-shenglei.zhang@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1293
[lersek@redhat.com: add TianoCore Bugzilla reference]
For QA test and development, we may need to test Secure Boot with a
devel key instead of UEFI CA.
This commit adds an argument, "--no-default", to EnrollDefaultKeys.efi.
With the argument, the key from SMBIOS Type 11 will also be enrolled
into db. Besides, the keys in AuthData.c, i.e. Microsoft KEK CA,
Microsoft PCA, and Microsoft UEFI CA will be excluded, so the developer
can easily create a varstore template for a specific key.
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Signed-off-by: Gary Lin <glin@suse.com>
Message-Id: <20190516030834.12203-1-glin@suse.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
NetLib,IpIoLib,UdpIoLib and DpcLib already exist in [LibraryClasses].
So the ones in [LibraryClasses.common.DXE_DRIVER] are duplicated,
which should be removed.
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@linaro.org>
Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com>
Message-Id: <20190515072419.23792-1-shenglei.zhang@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1293
[lersek@redhat.com: add TianoCore BZ reference]
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Update the QemuVideoDxe driver to not depend on the
OptionRomPkg to support moving OptionRomPkg to the
edk2-platforms repository.
The only dependency on the OptionRomPkg is the use of
PcdDriverSupportedEfiVersion to set the version value in the
EFI Driver Supported EFI Version Protocol.
Quoting the UEFI-2.8 spec, "This protocol is required for EFI
drivers that are *on* PCI and other plug in cards" (emphasis ours).
However, QemuVideoDxe is always part of the OVMF platform firmware,
and is never read by PciBusDxe from the PCI ROM BAR of QEMU's
emulated graphics cards.
Since this protocol does not apply to QEMU environment, remove
both the PCD and the installation of the EFI Driver Supported EFI
Version Protocol.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
When building OvmfPkg/EnrollDefaultKeys for IA32 with gcc-4.8 for the
DEBUG target (and possibly under other build configurations too), the
compiler incorrectly reports,
> OvmfPkg/EnrollDefaultKeys/EnrollDefaultKeys.c: In function
> 'ShellAppMain':
> OvmfPkg/EnrollDefaultKeys/EnrollDefaultKeys.c:631:10: error:
> 'SizeOfPkKek1' may be used uninitialized in this function
> [-Werror=maybe-uninitialized]
> Status = EnrollListOfCerts (
> ^
> OvmfPkg/EnrollDefaultKeys/EnrollDefaultKeys.c:703:12: error: 'PkKek1'
> may be used uninitialized in this function [-Werror=maybe-uninitialized]
> FreePool (PkKek1);
> ^
> cc1: all warnings being treated as errors
Suppress this warning, in the style suggested under
<https://bugzilla.tianocore.org/show_bug.cgi?id=607>.
Reported-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Fixes: be9470b3c9
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
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>
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>
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>
Disconnect the certificate that is enrolled as both Platform Key and first
Key Exchange Key from Red Hat: expect the hypervisor to specify it, as
part of SMBIOS.
Example usage with QEMU:
* Generate self-signed X509 certificate:
openssl req \
-x509 \
-newkey rsa:2048 \
-outform PEM \
-keyout PkKek1.private.key \
-out PkKek1.pem
(where "PEM" simply means "DER + base64 + header + footer").
* Strip the header, footer, and newline characters; prepend the
application prefix:
sed \
-e 's/^-----BEGIN CERTIFICATE-----$/4e32566d-8e9e-4f52-81d3-5bb9715f9727:/' \
-e '/^-----END CERTIFICATE-----$/d' \
PkKek1.pem \
| tr -d '\n' \
> PkKek1.oemstr
* Pass the certificate to EnrollDefaultKeys with the following QEMU
option:
-smbios type=11,value="$(< PkKek1.oemstr)"
(Note: for the above option to work correctly, a QEMU version is needed
that includes commit 950c4e6c94b1 ("opts: don't silently truncate long
option values", 2018-05-09). The first upstream release with that commit
was v3.0.0.
Once <https://bugs.launchpad.net/qemu/+bug/1826200> is fixed, QEMU will
learn to read the file directly; passing the blob on the command will be
necessary no more.)
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@arm.com>
Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1747
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Gary Lin <glin@suse.com>
For the EnrollDefaultKeys application, the hypervisor is expected to add a
string entry to the "OEM Strings" (Type 11) SMBIOS table, with the
following format:
4e32566d-8e9e-4f52-81d3-5bb9715f9727:<Base64 X509 cert for PK and first KEK>
The string representation of the GUID at the front is the "application
prefix", in terms of QEMU commit
<https://git.qemu.org/?p=qemu.git;a=commit;h=2d6dcbf93fb0>.
Introduce this GUID in the usual manner.
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@arm.com>
Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1747
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Gary Lin <glin@suse.com>
The entry point function of EnrollDefaultKeys finishes with a sanity
check, verifying the values of the Secure Boot-related "control"
variables. Add a diagram to explain why we expect the values we do.
While at it, write comments on the rest of the entry point function.
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@arm.com>
Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1747
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Gary Lin <glin@suse.com>
The GetExact(), GetSettings(), PrintSettings(), and ShellAppMain()
functions lack leading comment blocks. Supply those.
While at it, make sure that every such comment block is preceded by two
blank lines.
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@arm.com>
Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1747
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Gary Lin <glin@suse.com>
The GUID
77FA9ABD-0359-4D32-BD60-28F4E78F784B
is specified in MSDN, at
<https://msdn.microsoft.com/en-us/ie/dn932805(v=vs.94)>, therefore it
deserves an entry in the package DEC file, and a header file under
"Include/Guid".
(Arguably, this GUID declaration / definition could even live under
SecurityPkg, but the edk2 tradition has been to hoist GUIDs,
protocols/PPIs, and lib classes from OvmfPkg to a core package only when
dependent C code is added to the core package.)
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@arm.com>
Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1747
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Gary Lin <glin@suse.com>
A large portion of "EnrollDefaultKeys.c" is hex-encoded X509 certificates,
GUIDs, and signatures. These objects are constants, unlikely to see
changes anytime soon. Move them out of the way, to "AuthData.c", so we can
more easily work on functions in "EnrollDefaultKeys.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@arm.com>
Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1747
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Gary Lin <glin@suse.com>
"EnrollDefaultKeys.c" defines three structure types: SINGLE_HEADER,
REPEATING_HEADER, and SETTINGS. The definitions are scattered over the C
file, and lack high-level summary comments.
Extract the structures to "EnrollDefaultKeys.h", and add the missing
comments.
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@arm.com>
Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1747
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Gary Lin <glin@suse.com>
The GetExact(), GetSettings(), PrintSettings() functions are only called
from within "EnrollDefaultKeys.c", and none of them take variable
arguments. Drop their EFIAPI calling convention specifiers.
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@arm.com>
Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1747
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Gary Lin <glin@suse.com>
According to the edk2 coding standards, "[w]hen all letters in an acronym
are capitalized, it makes the prior and subsequent words visually
difficult to distinguish".
Fix the spellings of three acronyms, accordingly:
- "KEK" (Key Exchange Key) should be written as "Kek", in "mMicrosoftKEK",
- "CA" (Certificate Authority) should be written as "Ca", in
"mMicrosoftUefiCA",
- "PCA" (Production Certificate Authority) should be written as "Pca", in
"mMicrosoftPCA".
Generate the changes with:
sed --regexp-extended --in-place \
--expression='s,\<mMicrosoftKEK\>,mMicrosoftKek,g' \
--expression='s,\<mMicrosoftUefiCA\>,mMicrosoftUefiCa,g' \
--expression='s,\<mMicrosoftPCA\>,mMicrosoftPca,g' \
OvmfPkg/EnrollDefaultKeys/EnrollDefaultKeys.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@arm.com>
Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1747
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Gary Lin <glin@suse.com>
In edk2, we should start the names of module-global variables with "m".
Rename the "RedHatPkKek1", "MicrosoftKEK", "MicrosoftPCA",
"MicrosoftUefiCA" variables accordingly, with the following command:
sed --regexp-extended --in-place \
--expression='s,\<(RedHatPkKek1|Microsoft(KEK|PCA|UefiCA))\>,m\1,g' \
OvmfPkg/EnrollDefaultKeys/EnrollDefaultKeys.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@arm.com>
Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1747
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Gary Lin <glin@suse.com>
In edk2, we should spell "#pragma pack(...)" with a space character in
front of the opening parenthesis. Fix up locations that suggest otherwise.
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@arm.com>
Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1747
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Gary Lin <glin@suse.com>
Bump INF_VERSION to the latest edk2 INF specification.
Regenerate FILE_GUID to distinguish this application from downstream-only
versions.
Remove the VALID_ARCHITECTURES comment as there is nothing ISA or platform
specific in the application.
Ensure all sections apart from [Defines] are alphabetically sorted.
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@arm.com>
Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1747
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Gary Lin <glin@suse.com>
Refresh the sentence that states the purpose of the application.
Extend the copyright notice to the year 2019.
Replace the 2-clause BSD License banner with the BSD-2-Clause-Patent SPDX
ID.
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@arm.com>
Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1747
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Gary Lin <glin@suse.com>
Add the OvmfPkg/EnrollDefaultKeys shell application source as it is at the
"edk2-20190308git89910a39dcfd-2.el8" tag in RHEL8's downstream "edk2"
package.
Further patches in this series will replace Red Hat-specific bits in the
application, with a conduit to pass in parameters directly from the host
side, on both QEMU and Xen.
(Note: at the moment, Xen doesn't support Secure Boot, due to lacking a
standards-conformant variable driver stack. However, that could change
soon
<https://fosdem.org/2019/schedule/event/vai_implementing_uefi_variable_services_in_qemu/>,
and then this facility will become useful on Xen too.)
The use case for this application (including why it is only being added to
the DSC files) is explained in detail in
<https://bugzilla.tianocore.org/show_bug.cgi?id=1747#c0>.
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@arm.com>
Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1747
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Gary Lin <glin@suse.com>
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>
The real mode interrupt vector table, which we modify for the sake of
Windows 7, starts at address 0, which happens to be the representation of
null pointers on all edk2 architectures. A null pointer may never undergo
pointer arithmetic, and RH covscan justifiedly reports:
> Error: CPPCHECK_WARNING (CWE-682):
> edk2-89910a39dcfd/OvmfPkg/QemuVideoDxe/VbeShim.c:105:
> error[nullPointerArithmetic]: Pointer addition with NULL pointer.
> # 103| //
> # 104| Segment0Pages = 1;
> # 105|-> Int0x10 = (IVT_ENTRY *)(UINTN)Segment0 + 0x10;
> # 106| Segment0AllocationStatus = gBS->AllocatePages (
> # 107| AllocateAddress,
Fix this by calculating the EFI_PHYSICAL_ADDRESS of IVT entry 0x10 first,
and by casting the address to the right type second.
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-1002.txt
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
The "XenBus.c", "XenStore.c", "XenStore.h" files under "OvmfPkg/XenBusDxe"
include the MIT License text. Replace those license blocks with
"SPDX-License-Identifier: MIT" (which refers to
<https://spdx.org/licenses/MIT.html>) for easier parsing by machines (and
humans).
This follows the tree-wide adoption of "SPDX-License-Identifier"s, made
for <https://bugzilla.tianocore.org/show_bug.cgi?id=1373>.
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@arm.com>
Cc: Lars Kurth <lars.kurth@citrix.com>
Cc: xen-devel@lists.xenproject.org
Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1654
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
The header files under "OvmfPkg/Include/IndustryStandard/Xen" include the
MIT License text. Replace those license blocks with
"SPDX-License-Identifier: MIT" (which refers to
<https://spdx.org/licenses/MIT.html>) for easier parsing by machines (and
humans).
This follows the tree-wide adoption of "SPDX-License-Identifier"s, made
for <https://bugzilla.tianocore.org/show_bug.cgi?id=1373>.
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@arm.com>
Cc: Lars Kurth <lars.kurth@citrix.com>
Cc: xen-devel@lists.xenproject.org
Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1654
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
Refresh the MIT license text from <https://spdx.org/licenses/MIT.html>,
and add "SPDX-License-Identifier: MIT" for easier parsing by machines.
This follows the tree-wide adoption of "SPDX-License-Identifier"s, made
for <https://bugzilla.tianocore.org/show_bug.cgi?id=1373>; in particular:
- commit 304bff7223 ("edk2: Change License.txt from 2-Clause BSD to
BSD+Patent", 2019-04-09),
- commit 75fae505b7 ("OvmfPkg: Change License.txt from 2-Clause BSD to
BSD+Patent", 2019-04-09).
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@arm.com>
Cc: Lars Kurth <lars.kurth@citrix.com>
Cc: xen-devel@lists.xenproject.org
Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1654
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1496
This commit updates the OVMF DSC/FDF files to consume the copied
8259InterruptControllerDxe and 8254TimerDxe drivers within OvmfPkg.
The unconsumed PCD:
gPcAtChipsetPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel
is removed from DSC files as well.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1496
This commit will remove the IntelFrameworkPkg DEC file dependency in the
driver INF file.
A new GUID has been updated for the INF file.
Corresponding changes have been made in OVMF DSC files as well in order to
verify the build.
Please note that a subsequent commit (final patch of the series) will:
A) Add OvmfPkg/8254TimerDxe driver in OVMF FDF files;
B) Remove the consumption of PcAtChipsetPkg/8254TimerDxe driver in OVMF
DSC/FDF files.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1496
This commit copies the exact 8254TimerDxe driver from PcAtChipsetPkg to
OvmfPkg.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1496
Several updates have been made to the OvmfPkg/AcpiPlatformDxe driver to
drop its dependency on PcAtChipsetPkg:
A) Consumes the PCD 'Pcd8259LegacyModeEdgeLevel' defined within OvmfPkg;
B) Remove the PcAtChipsetPkg DEC file dependency in the driver INF file.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1496
Several updates have been made to the
OvmfPkg/8259InterruptControllerDxe driver to make it build under OvmfPkg:
A) Update the driver INF file to consume PCDs defined within OvmfPkg;
B) Remove the unnecessary dependency on the IntelFrameworkPkg header file
'FrameworkDxe.h';
C) Remove the IntelFrameworkPkg & PcAtChipsetPkg DEC files dependency in
the driver INF file.
A new GUID has been updated for the INF file.
Corresponding changes have been made in OVMF DSC files as well in order to
verify the build.
Please note that a subsequent commit (final patch of the series) will:
A) Add OvmfPkg/8259InterruptControllerDxe driver in OVMF FDF files;
B) Remove the consumption of PcAtChipsetPkg/8259InterruptControllerDxe
driver in OVMF DSC/FDF files;
C) Remove the consumption of
gPcAtChipsetPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel in OVMF DSC
files.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1496
According to the DEC file in PcAtChipsetPkg, this commit adds the two
8259-driver-related PCDs into the OvmfPkg DEC file.
Please note that, instead of adding the two PCDs under section:
[PcdsFixedAtBuild, PcdsDynamic, PcdsDynamicEx, PcdsPatchableInModule]
as in PcAtChipsetPkg.dec file, they are added in section:
[PcdsFixedAtBuild]
in OvmfPkg.dec instead.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1496
This commit copies the exact Legacy8259 protocol header file from
IntelFrameworkPkg to OvmfPkg. Also, the protocol GUID definition is
duplicated in the OvmfPkg DEC file.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1496
This commit copies the exact 8259InterruptControllerDxe driver from
PcAtChipsetPkg to OvmfPkg.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1495
This commit will add a static build flag 'USE_LEGACY_ISA_STACK' to select
the ISA driver stack.
If the flag is set to TRUE, the below driver stack will be used:
PcAtChipsetPkg/IsaAcpiDxe/IsaAcpi.inf
IntelFrameworkModulePkg/Bus/Isa/IsaBusDxe/IsaBusDxe.inf
IntelFrameworkModulePkg/Bus/Isa/IsaSerialDxe/IsaSerialDxe.inf
IntelFrameworkModulePkg/Bus/Isa/Ps2KeyboardDxe/Ps2keyboardDxe.inf
If the flag is set to FALSE, the below driver stack will be used:
OvmfPkg/SioBusDxe/SioBusDxe.inf
MdeModulePkg/Bus/Pci/PciSioSerialDxe/PciSioSerialDxe.inf
MdeModulePkg/Bus/Isa/Ps2KeyboardDxe/Ps2KeyboardDxe.inf
The default value is set to FALSE in OVMF DSC files.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Ray Ni <ray.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Anthony PERARD <anthony.perard@citrix.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1495
There is a plan to remove the IntelFrameworkModulePkg:
https://bugzilla.tianocore.org/show_bug.cgi?id=1605
This patch will a new OVMF Super I/O bus driver which will create the
below child devices:
* COM 1 UART
* COM 2 UART
* PS/2 Keyboard
and installs the Super I/O Protocol on them.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Anthony PERARD <anthony.perard@citrix.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1495
There is a plan to remove the IntelFrameworkModulePkg:
https://bugzilla.tianocore.org/show_bug.cgi?id=1605
And for driver:
IntelFrameworkModulePkg/Bus/Isa/IsaFloppyDxe
This patch proposes to drop the ISA Floppy device support in OVMF.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Anthony PERARD <anthony.perard@citrix.com>
Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1653
"create-release.py" generates a 2-BSDL copyright block that will no longer
apply once we fix <https://bugzilla.tianocore.org/show_bug.cgi?id=1373>.
Rather than update "create-release.py", remove it. We haven't used it in
several years now, plus source releases of upstream edk2 are now covered
by the edk2 stable tags
<https://github.com/tianocore/tianocore.github.io/wiki/EDK-II#stable-tags>.
Regarding binary releases of upstream OVMF: OVMF and ArmVirtQemu binaries
built at the edk2 stable tags are being bundled with upstream QEMU,
similarly to other firmware that runs on QEMU platforms:
<https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg06148.html>.
Furthermore, the Xen project has provided its own builds of OVMF and
ArmVirtXen for a good while now.
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@arm.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Jordan Justen <jordan.l.justen@intel.com>
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>
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>
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>
The check for 1.[1-9][0-9].* was removed since qemu jumped to 2.0
after 1.7.
Changed 2.*.* to [2-9].*.* to match major releases 3 - 9.
Added [1-9][0-9]*.*.* to match major releses >= 10.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
This patch adds the TCG2 Configuration menu to the Device Manager
menu. We can apparently reuse the sample Tcg2ConfigDxe from
SecurityPkg/Tcg/Tcg2Config without obvious adverse effects. The
added TCG2 Configuration menu now shows details about the attached
TPM 2.0 and lets one for example configure the active PCR banks
or issue commands, among other things.
The code is added to Ovmf by building with -DTPM2_ENABLE and
-DTPM2_CONFIG_ENABLE.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
The SMM based FTW and variable drivers are going to depend on
MmServicesTableLib after a subsequent patch, so add a resolution
for it to various OvmfPkg .dsc files.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
We're about to remove BaseTools support for GCC44..GCC47. Reject those gcc
versions cleanly in "OvmfPkg/build.sh". In "OvmfPkg/README", upgrade any
mentions of the same gcc versions to GCC48.
No GCC44..GCC47 references remain under OvmfPkg after this patch.
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>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1377
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>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1405
The codes have been updated to not use PcdPeiCoreMaxFvSupported,
PcdPeiCoreMaxPeimPerFv and PcdPeiCoreMaxPpiSupported, so their
statement in platform DSC could be removed.
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@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
https://bugzilla.tianocore.org/show_bug.cgi?id=1355
XCODE doesn't support HII resource section. TftpDynamicCommand driver depends
on HII resource section. To let OvmfPkg boot to shell on XCODE5 tool chain,
don't include TftpDynamicCommand driver.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Liming Gao <liming.gao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
BAR | std vga | vmsvga
---------------------------------
0 | Framebuffer | I/O space
1 | Reserved | Framebuffer
2 | MMIO | FIFO
- We cannot recognize VMW SVGA as BOCHS because that would confuse the
IsQxl setting in QemuVideoControllerDriverStart(),
- We cannot recognize VMW SVGA as BOCHS_MMIO because BAR2 on VMW SVGA is
not the BOCHS MMIO BAR (we can only use port IO).
Therefore the list of reasons for which we should introduce
QEMU_VIDEO_VMWARE_SVGA should name three reasons:
(1) Get framebuffer from correct PCI BAR
(2) Prevent using BAR2 for MMIO
(3) Prevent mis-recognizing VMW SVGA as QXL
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: yuchenlin <yuchenlin@synology.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
This reverts commit 05a5379458.
The VMWare SVGA display device implemented by Qemu (-vga vmware) uses
an I/O-type BAR which is laid out such that some register offsets are
not aligned to the read/write width with which they are expected to be
accessed. However, we reverted the initialization of VMWare SVGA device,
we don't need such unaligned I/O.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: yuchenlin <yuchenlin@synology.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
(cherry picked from commit 438ada5aa5)
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
This reverts commit c137d95081.
The VMWare SVGA model now -- since commit 104bd1dc70 in QEMU --
falls back to stdvga (that is, Bochs) if we don't setup VMWare SVGA
FIFO.
To simplify QemuVideoDxe, we don't intend to implement the VMWare SVGA
FIFO setup feature. It means our current VMW SVGA driver code is
basically dead. To simplify the problem, we will replace the old
VMWare SVGA driver to Bochs interface. It should work on all QEMU
version.
The first step for using Bochs interface is to revert old driver.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: yuchenlin <yuchenlin@synology.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
(cherry picked from commit 98856a724c)
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
This reverts commit b2959e9f1a.
The VMWare SVGA display device implemented by Qemu (-vga vmware) uses
an I/O-type BAR which is laid out such that some register offsets are
not aligned to the read/write width with which they are expected to be
accessed. However, we will revert the initialization of VMWare SVGA
device later, we don't need such unaligned I/O.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: yuchenlin <yuchenlin@synology.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
(cherry picked from commit e038bde267)
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Remove EdkShellBinPkg in OvmfPkgIa32.fdf,
OvmfPkg/OvmfPkgIa32X64.fdf amd OvmfPkg/OvmfPkgX64.fdf.
https://bugzilla.tianocore.org/show_bug.cgi?id=1108
v2: Remove USE_OLD_SHELL in DSC and FDF because it will be
unnecessary to use 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>
This reverts commit e038bde267, reapplying
b2959e9f1a.
Note that the commit now being reverted is technically correct; the only
reason we're reverting it is because it should not have been pushed past
the Soft Feature Freeze for the edk2-stable201811 tag.
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: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: yuchenlin <yuchenlin@synology.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1319
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: yuchenlin <yuchenlin@synology.com>
This reverts commit 98856a724c, reapplying
c137d95081.
Note that the commit now being reverted is technically correct; the only
reason we're reverting it is because it should not have been pushed past
the Soft Feature Freeze for the edk2-stable201811 tag.
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: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: yuchenlin <yuchenlin@synology.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1319
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: yuchenlin <yuchenlin@synology.com>
This reverts commit 438ada5aa5,
reapplying 05a5379458.
Note that the commit now being reverted is technically correct; the only
reason we're reverting it is because it should not have been pushed past
the Soft Feature Freeze for the edk2-stable201811 tag.
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: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: yuchenlin <yuchenlin@synology.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1319
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: yuchenlin <yuchenlin@synology.com>
This reverts commit 328409ce8d, reapplying
9bcca53fe4.
Note that the commit now being reverted is technically correct; the only
reason we're reverting it is because it should not have been pushed past
the Soft Feature Freeze for the edk2-stable201811 tag.
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: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: yuchenlin <yuchenlin@synology.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1319
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: yuchenlin <yuchenlin@synology.com>
This reverts commit 05a5379458.
The VMWare SVGA display device implemented by Qemu (-vga vmware) uses
an I/O-type BAR which is laid out such that some register offsets are
not aligned to the read/write width with which they are expected to be
accessed. However, we reverted the initialization of VMWare SVGA device,
we don't need such unaligned I/O.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: yuchenlin <yuchenlin@synology.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
This reverts commit c137d95081.
The VMWare SVGA model now -- since commit 104bd1dc70 in QEMU --
falls back to stdvga (that is, Bochs) if we don't setup VMWare SVGA
FIFO.
To simplify QemuVideoDxe, we don't intend to implement the VMWare SVGA
FIFO setup feature. It means our current VMW SVGA driver code is
basically dead. To simplify the problem, we will replace the old
VMWare SVGA driver to Bochs interface. It should work on all QEMU
version.
The first step for using Bochs interface is to revert old driver.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: yuchenlin <yuchenlin@synology.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
This reverts commit b2959e9f1a.
The VMWare SVGA display device implemented by Qemu (-vga vmware) uses
an I/O-type BAR which is laid out such that some register offsets are
not aligned to the read/write width with which they are expected to be
accessed. However, we will revert the initialization of VMWare SVGA
device later, we don't need such unaligned I/O.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: yuchenlin <yuchenlin@synology.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
V2:
Add missed library instance for NetworkPkg iSCSI driver.
This patch replaces the MdeModulePkg TCP, PXE and iSCSI driver with those
ones in NetworkPkg. These 3 drivers in MdeModulePkg are not being actively
maintained and will be removed from edk2 master soon.
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@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Fu Siyuan <siyuan.fu@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
This is for conformance with the TCG "Platform Reset Attack Mitigation
Specification". Because clearing the CPU caches at boot doesn't impact
performance significantly, do it unconditionally, for simplicity's
sake.
Flush the cache on all logical processors, thanks to
EFI_PEI_MP_SERVICES_PPI and CacheMaintenanceLib.
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@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Tested-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
[lersek@redhat.com: remove bogus Message-Id line from commit msg]
Sha384 and Sha512 were added to HashInstanceLib recently. To make them
available in Tcg2Pei and Tcg2Dxe, we have to link both libraries.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Build-tested-by: Laszlo Ersek <lersek@redhat.com>
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"]
ResourcePublicationLib class name is ResourcePublicationLib.
INF and DSC files are updated to use the correct one.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Liming Gao <liming.gao@intel.com>
Signed-off-by: Dongao Guo <dongao.guo@intel.com>
[lersek@redhat.com: insert empty line between commit msg body and tags]
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
XenPvBlkDxe doesn't reference gEfiDevicePathProtocolGuid; remove it from
the INF file.
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: Steven Shi <steven.shi@intel.com>
Reported-by: Steven Shi <steven.shi@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1034
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
None of the source files referenced by "AcpiPlatformDxe.inf" #include
"MdePkg/Include/Library/DxeServicesLib.h" or use interfaces declared
therein, so drop DxeServicesLib from [LibraryClasses].
"AcpiPlatformDxe.inf" references "AcpiPlatform.c", which installs ACPI
tables built into the firmware image from under "OvmfPkg/AcpiTables/", in
case dynamically generated ACPI tables are not available from Xen or QEMU.
For this, the driver consumes gEfiFirmwareVolume2ProtocolGuid. Account for
that in [Protocols].
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Steven Shi <steven.shi@intel.com>
Reported-by: Steven Shi <steven.shi@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1014
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
In the SMM build, only an SMM driver is using the address range hence we
do not need to expose the flash MMIO range in EFI runtime mapping.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Julien Grall <julien.grall@linaro.org>
Cc: Justen Jordan L <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
The flash memory range is an IO address and should be presented as Memory
Mapped IO in EFI Runtime mapping. This information can be used by OS
when mapping the flash memory range.
It is especially helpful in SEV guest case, in which IO addresses should
be mapped as unencrypted. If memory region is not marked as MMIO then OS
maps the range as encrypted.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Julien Grall <julien.grall@linaro.org>
Cc: Justen Jordan L <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
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>
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>
Anthony PERARD
Eric Dong
Rebecca Cran
Imran Desai
Laszlo Ersek
Gary Lin
David Woodhouse
Hao A Wu
Marc W Chen
Fu Siyuan
Zhang, Shenglei
Michael D Kinney
Igor Druzhinin
Zhichao Gao
Bret Barkelew
Jordan Justen
Stefan Berger
Ard Biesheuvel
Star Zeng
Liming Gao
yuchenlin
Marc-André Lureau
Ruiyu Ni
Brijesh Singh
chenc2
Gerd Hoffmann