At this stage, the driver builds, and suffices for testing binding and
unbinding.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://tianocore.acgmultimedia.com/show_bug.cgi?id=66
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
In the Platform Init v1.4a spec,
- Volume 1 "4.7 Status Code Service" defines the
EFI_PEI_SERVICES.ReportStatusCode() service,
- Volume 1 "6.3.5 Status Code PPI (Optional)" defines the
EFI_PEI_PROGRESS_CODE_PPI (equivalent to the above),
- Volume 2 "14.2 Status Code Runtime Protocol" defines the
EFI_STATUS_CODE_PROTOCOL.
These allow PEIMs and DXE (and later) modules to report status codes.
Currently OvmfPkg uses modules from under
"IntelFrameworkModulePkg/Universal/StatusCode/", which produce the above
abstractions (PPI and PROTOCOL) directly, and write the status codes, as
they are reported, to the serial port or to a memory buffer. This is
called "handling" the status codes.
In the Platform Init v1.4a spec,
- Volume 3 "7.2.2 Report Status Code Handler PPI" defines
EFI_PEI_RSC_HANDLER_PPI,
- Volume 3 "7.2.1 Report Status Code Handler Protocol" defines
EFI_RSC_HANDLER_PROTOCOL.
These allow several PEIMs and runtime DXE drivers to register callbacks
for status code handling.
MdeModulePkg offers a PEIM under
"MdeModulePkg/Universal/ReportStatusCodeRouter/Pei" that produces both
EFI_PEI_PROGRESS_CODE_PPI and EFI_PEI_RSC_HANDLER_PPI, and a runtime DXE
driver under "MdeModulePkg/Universal/ReportStatusCodeRouter/RuntimeDxe"
that produces both EFI_STATUS_CODE_PROTOCOL and EFI_RSC_HANDLER_PROTOCOL.
MdeModulePkg also offers status code handler modules under
MdeModulePkg/Universal/StatusCodeHandler/ that depend on
EFI_PEI_RSC_HANDLER_PPI and EFI_RSC_HANDLER_PROTOCOL, respectively.
The StatusCodeHandler modules register themselves with
ReportStatusCodeRouter through EFI_PEI_RSC_HANDLER_PPI /
EFI_RSC_HANDLER_PROTOCOL. When another module reports a status code
through EFI_PEI_PROGRESS_CODE_PPI / EFI_STATUS_CODE_PROTOCOL, it reaches
the phase-matching ReportStatusCodeRouter module first, which in turn
passes the status code to the pre-registered, phase-matching
StatusCodeHandler module.
The status code handling in the StatusCodeHandler modules is identical to
the one currently provided by the IntelFrameworkModulePkg modules. Replace
the IntelFrameworkModulePkg modules with the MdeModulePkg ones, so we can
decrease our dependency on IntelFrameworkModulePkg.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Cinnamon Shia <cinnamon.shia@hpe.com>
Suggested-by: Liming Gao <liming.gao@intel.com>
Fixes: https://tianocore.acgmultimedia.com/show_bug.cgi?id=63
[jordan.l.justen@intel.com: point out IntelFareworkModulePkg typos]
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
[lersek@redhat.com: rewrap to 74 cols; fix IntelFareworkModulePkg typos]
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
In the next patch we're going to put EFI_PEI_MP_SERVICES_PPI to use.
CpuMpPei uses the following PCDs from gUefiCpuPkgTokenSpaceGuid, beyond
those already used by CpuDxe:
- PcdCpuMicrocodePatchAddress and PcdCpuMicrocodePatchRegionSize: these
control whether CpuMpPei performs microcode update. If the region size
is zero, then the microcode update is skipped. UefiCpuPkg.dec sets the
region size to zero by default, which is appropriate for OVMF.
- PcdCpuApLoopMode and PcdCpuApTargetCstate: the former controls how
CpuMpPei puts the APs to sleep: 1 -- HLT, 2 -- MWAIT, 3 -- busy wait
(with PAUSE). The latter PCD is only relevant if the former PCD is 2
(MWAIT). In order to be consistent with SeaBIOS and with CpuDxe itself,
we choose HLT. That's the default set by UefiCpuPkg.dec.
Furthermore, although CpuMpPei could consume SecPeiCpuExceptionHandlerLib
technically, it is supposed to consume PeiCpuExceptionHandlerLib. See:
- http://thread.gmane.org/gmane.comp.bios.edk2.devel/12703
- git commit a81abf1616 ("UefiCpuPkg/ExceptionLib: Import
PeiCpuExceptionHandlerLib module"), part of the series linked above.
Jeff recommended to resolve CpuExceptionHandlerLib to
PeiCpuExceptionHandlerLib for all PEIMs:
- http://thread.gmane.org/gmane.comp.bios.edk2.devel/14471/focus=14477
Since at the moment we have no resolution in place that would cover this
for PEIMs (from either [LibraryClasses] or [LibraryClasses.common.PEIM]),
it's easy to do.
Cc: Jeff Fan <jeff.fan@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
After IncompatiblePciDeviceSupportDxe, this is another small driver /
protocol implementation that tweaks the behavior of the PCI bus driver in
edk2.
The protocol is specified in the Platform Init Spec v1.4a, Volume 5,
Chapter 12.6 "PCI Hot Plug PCI Initialization Protocol". This
implementation steers the PCI bus driver to reserve the following
resources ("padding") for each PCI bus, in addition to the BARs of the
devices on that PCI bus:
- 2MB of 64-bit non-prefetchable MMIO aperture,
- 512B of IO port space.
The goal is to reserve room for devices hot-plugged at runtime even if the
bridge receiving the device is empty at boot time.
The 2MB MMIO size is inspired by SeaBIOS. The 512B IO port size is
actually only 1/8th of the PCI spec mandated reservation, but the
specified size of 4096 has proved wasteful (given the limited size of our
IO port space -- see commit bba734ab4c). Especially on Q35, where every
PCIe root port and downstream port qualifies as a separate bridge (capable
of accepting a single device).
Test results for this patch:
- regardless of our request for 64-bit MMIO reservation, it is downgraded
to 32-bit,
- although we request 512B alignment for the IO port space reservation,
the next upstream bridge rounds it up to 4096B.
Cc: "Johnson, Brian J." <bjohnson@sgi.com>
Cc: Alex Williamson <alex.williamson@redhat.com>
Cc: Andrew Fish <afish@apple.com>
Cc: Feng Tian <feng.tian@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Marcel Apfelbaum <marcel@redhat.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Suggested-by: Andrew Fish <afish@apple.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Ruiyu Ni <Ruiyu.ni@intel.com>
The Driver Health HII menu is not an integral part of the MdeModulePkg BDS
driver / UI app. Because we abandoned the IntelFrameworkModulePkg BDS, now
we have to get the same functionality explicitly from
DriverHealthManagerDxe.
Suggested-by: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Bruce Cran <bruce.cran@gmail.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
[lersek@redhat.com: update commit message]
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
The default stack size (from UefiCpuPkg/UefiCpuPkg.dec) is 8KB, which
proved too small (i.e., led to stack overflow) across commit range
98c2d9610506^..f85d3ce2efc2^, during certificate enrollment into "db".
As the edk2 codebase progresses and OVMF keeps including features, the
stack demand constantly fluctuates; double the SMM stack size for good
measure.
Cc: Jeff Fan <jeff.fan@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Ref: http://thread.gmane.org/gmane.comp.bios.edk2.devel/12864
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1341733
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
In the course of porting OvmfPkg to the MdeModulePkg BDS, commit
817fb3ac2a
OvmfPkg/PlatformBootManagerLib: Add EnableQuietBoot & DisableQuietBoot
open-coded the EnableQuietBoot() function (and its dependencies / friends)
from IntelFrameworkModulePkg BDS.
This code duplication can be avoided; the functionality is available from
the following three libraries in MdeModulePkg:
- BootLogoLib: provides the BootLogoEnableLogo() function. It does not
provide the internal ConvertBmpToGopBlt() function -- that one is
delegated to ImageDecoderLib (function DecodeImage()).
- ImageDecoderLib: a general library that registers decoder plugins for
specific image formats, and provides the generic DecodeImage() on top.
- BmpImageDecoderLib: one of said decoder plugins, for handling BMP images
(which is the format of our logo).
In this patch, we revert 817fb3ac2a, and atomically incorporate the
above libraries. This is inspired by Nt32Pkg commit 859e75c4fc42:
Nt32Pkg: Use BootLogoLib for logo and progress bar drawing.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
According to edk2 commit
"MdeModulePkg/PciBus: do not improperly degrade resource"
and to the EFI_INCOMPATIBLE_PCI_DEVICE_SUPPORT_PROTOCOL definition in the
Platform Init 1.4a specification, a platform can provide such a protocol
in order to influence the PCI resource allocation performed by the PCI Bus
driver.
In particular it is possible instruct the PCI Bus driver, with a
"wildcard" hint, to allocate the 64-bit MMIO BARs of a device in 64-bit
address space, regardless of whether the device features an option ROM.
(By default, the PCI Bus driver considers an option ROM reason enough for
allocating the 64-bit MMIO BARs in 32-bit address space. It cannot know if
BDS will launch a legacy boot option, and under legacy boot, a legacy BIOS
binary from a combined option ROM could be dispatched, and fail to access
MMIO BARs in 64-bit address space.)
In platform code we can ascertain whether a CSM is present or not. If not,
then legacy BIOS binaries in option ROMs can't be dispatched, hence the
BAR degradation is detrimental, and we should prevent it. This is expected
to conserve the 32-bit address space for 32-bit MMIO BARs.
The driver added in this patch could be simplified based on the following
facts:
- In the Ia32 build, the 64-bit MMIO aperture is always zero-size, hence
the driver will exit immediately. Therefore the driver could be omitted
from the Ia32 build.
- In the Ia32X64 and X64 builds, the driver could be omitted if CSM_ENABLE
was defined (because in that case the degradation would be justified).
On the other hand, if CSM_ENABLE was undefined, then the driver could be
included, and it could provide the hint unconditionally (without looking
for the Legacy BIOS protocol).
These short-cuts are not taken because they would increase the differences
between the OVMF DSC/FDF files. If we can manage without extreme
complexity, we should use dynamic logic (vs. build time configuration),
plus keep conditional compilation to a minimum.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
This completes the transition to the new BDS.
The FILE_GUID in "QemuBootOrderLib.inf" is intentionally not changed.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Gary Ching-Pang Lin <glin@suse.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reasons:
- USE_OLD_BDS requires duplicating updates between OVMF's library
instances that depend on USE_OLD_BDS being FALSE vs. TRUE. Examples:
d5aee61bfa OvmfPkg/QemuNewBootOrderLib: adapt Q35 SATA PMPN to UEFI
spec Mantis 1353
1da7616649 OvmfPkg/QemuBootOrderLib: adapt Q35 SATA PMPN to UEFI spec
Mantis 1353
- The Xen community has embraced the new BDS. Examples:
14b2ebc30c OvmfPkg/PlatformBootManagerLib: Postpone the shell
registration
49effaf26e OvmfPkg/PciHostBridgeLib: Scan for root bridges when
running over Xen
- OVMF doesn't build with "-D USE_OLD_BDS -D HTTP_BOOT_ENABLE" anyway, as
NetworkPkg/HttpBootDxe now requires UefiBootManagerLib:
50a65824c7 NetworkPkg: Use UefiBootManagerLib API to create load
option.
We (correctly) don't resolve UefiBootManagerLib when USE_OLD_BDS is
TRUE.
- The new BDS has been working well; for example it's the only BDS
available in ArmVirtPkg:
1946faa710 ArmVirtPkg/ArmVirtQemu: use MdeModulePkg/BDS
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Gary Ching-Pang Lin <glin@suse.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Make PcdPciIoBase and PcdPciIoSize dynamic PCDs, and set them in
MemMapInitialization(), where we produce our EFI_RESOURCE_IO descriptor
HOB. (The PCD is consumed by the core PciHostBridgeDxe driver, through our
PciHostBridgeLib instance.)
Take special care to keep the GCD IO space map unchanged on all platforms
OVMF runs on.
Cc: Gabriel Somlo <somlo@cmu.edu>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1333238
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Tested-by: Gabriel Somlo <somlo@cmu.edu>
The RamDiskDxe driver in MdeModulePkg now will use EFI_ACPI_TABLE_PROTOCOL
and EFI_ACPI_SDT_PROTOCOL during reporting RAM disks to NVDIMM Firmware
Interface Table (NFIT).
A Pcd 'PcdInstallAcpiSdtProtocol' controls whether the
EFI_ACPI_SDT_PROTOCOL will be produced. Its default value is set to FALSE
in MdeModulePkg. To make the NFIT reporting feature working properly under
OVMF, the patch will set the Pcd to TRUE in OVMF DSC files.
Also, the RamDiskDxe driver will sometimes report a NVDIMM Root Device
using ASL code which is put in a Secondary System Description Table (SSDT)
according to the ACPI 6.1 spec.
Locating the SSDT requires modifying the [Rule.Common.DXE_DRIVER] field in
OVMF FDF files.
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Samer El-Haj-Mahmoud <elhaj@hpe.com>
PcdShellFile is never used in the PEI phase.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
By default the new MdeModulePkg/BDS is used.
If USE_OLD_BDS is defined to TRUE, IntelFrameworkModulePkg/BDS
is used.
Fixes: https://github.com/tianocore/edk2/issues/62
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
It's been a month since the following commits appeared in the repo:
4014885ffd OvmfPkg: switch to MdeModulePkg/Bus/Pci/PciHostBridgeDxe
c47ed6fcb5 OvmfPkg: match PCI config access to machine type (if not
USE_OLD_PCI_HOST)
in which we introduced the USE_OLD_PCI_HOST fallback, and made other work
depend on it. I have not heard of any problems (primarily from the
vfio-users group that uses Gerd's daily / hourly OVMF builds), so it's
time to drop the fallback.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Now that FatPkg is open source (and therefore can be included in the
EDK II tree) we build and use it directly.
Build tested with GCC 5.3 on IA32 and X64. Boot tested to UEFI Shell
on IA32 and UEFI Linux on X64.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
The same functional code has been in S3SaveStateDxe,
OVMF AcpiS3SaveDxe can be retired now.
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
Also need to declare PcdAcpiS3Enable as DynamicDefault in *.dsc.
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Edk2 commit 8a45f80eda ("MdeModulePkg: Make HII configuration settings
available to OS runtime") implements the optional UEFI feature described
in "31.2.11.1 OS Runtime Utilization" in UEFI v2.6.
While this feature might show benefits down the road even in QEMU virtual
machines, at the moment it only presents drawbacks:
- it increases the EfiRuntimeServicesData footprint,
- it triggers HII compatibility problems between edk2 and external drivers
unconditionally, even if the end-user is not interested in HII and/or in
configuring said drivers (see
<https://www.redhat.com/archives/vfio-users/2016-March/msg00153.html>
and <http://thread.gmane.org/gmane.comp.bios.edk2.devel/9894> for an
example).
While the feature was being introduced, popular demand for a controlling
Feature PCD rose (see
<http://thread.gmane.org/gmane.comp.bios.edk2.devel/7626>), which is why
we can set it now to FALSE.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
PcdMaxHardwareErrorVariableSize sets the size limit for individual
Hardware Error Record Variables (see "7.2.3 Hardware Error Record
Persistence" and "Appendix P, Hardware Error Record Persistence Usage" in
the UEFI-2.6 spec).
Since Hardware Error Record Persistence is an optional firmware feature,
according to the spec, and OVMF does not enable it -- it inherits
PcdHwErrStorageSize and PcdHardwareErrorRecordLevel with zero values --,
the PcdMaxHardwareErrorVariableSize setting in our DSC files has no
effect. Remove it in order to eliminate future confusion.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Suggested-by: Star Zeng <star.zeng@intel.com>
Ref: http://thread.gmane.org/gmane.comp.bios.edk2.devel/9743/focus=9780
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Currently booting off of a RAM disk is not supported by
IntelFrameWorkModulePkg BDS, however on systems without writable
disks, the RAM disk can be made useful when loading raw HDD images
into it -- specially the ones with a FAT32 partition on which files
can be natively accessed by system firmware.
This patch adds RamDiskDxe driver by default in OVMF platform.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Paulo Alcantara <paulo.alc.cavalcanti@hp.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
During real world testing I was getting an error with too many entries
in db: On my Secure boot laptop, I currently have seven certificates:
two Microsoft ones, Three Kernel ones from various distributions, my
own Secure Key and a temporary test key. That gives a total EFI
Signature List size of 8317 which is over the 0x2000 maximum.
Fix this by setting the PcdMaxAuthVariableSize to 0x2800 (10K) which
isn't much of an increase but allows for 9-10 certificates.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
The main observation about the 64-bit PCI host aperture is that it is the
highest part of the useful address space. It impacts the top of the GCD
memory space map, and, consequently, our maximum address width calculation
for the CPU HOB too.
Thus, modify the GetFirstNonAddress() function to consider the following
areas above the high RAM, while calculating the first non-address (i.e.,
the highest inclusive address, plus one):
- the memory hotplug area (optional, the size comes from QEMU),
- the 64-bit PCI host aperture (we set a default size).
While computing the first non-address, capture the base and the size of
the 64-bit PCI host aperture at once in PCDs, since they are natural parts
of the calculation.
(Similarly to how PcdPciMmio32* are not rewritten on the S3 resume path
(see the InitializePlatform() -> MemMapInitialization() condition), nor
are PcdPciMmio64*. Only the core PciHostBridgeDxe driver consumes them,
through our PciHostBridgeLib instance.)
Set 32GB as the default size for the aperture. Issue#59 mentions the
NVIDIA Tesla K80 as an assignable device. According to nvidia.com, these
cards may have 24GB of memory (probably 16GB + 8GB BARs).
As a strictly experimental feature, the user can specify the size of the
aperture (in MB) as well, with the QEMU option
-fw_cfg name=opt/ovmf/X-PciMmio64Mb,string=65536
The "X-" prefix follows the QEMU tradition (spelled "x-" there), meaning
that the property is experimental, unstable, and might go away any time.
Gerd has proposed heuristics for sizing the aperture automatically (based
on 1GB page support and PCPU address width), but such should be delayed to
a later patch (which may very well back out "X-PciMmio64Mb" then).
For "everyday" guests, the 32GB default for the aperture size shouldn't
impact the PEI memory demand (the size of the page tables that the DXE IPL
PEIM builds). Namely, we've never reported narrower than 36-bit addresses;
the DXE IPL PEIM has always built page tables for 64GB at least.
For the aperture to bump the address width above 36 bits, either the guest
must have quite a bit of memory itself (in which case the additional PEI
memory demand shouldn't matter), or the user must specify a large aperture
manually with "X-PciMmio64Mb" (and then he or she is also responsible for
giving enough RAM to the VM, to satisfy the PEI memory demand).
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Marcel Apfelbaum <marcel@redhat.com>
Cc: Thomas Lamprecht <t.lamprecht@proxmox.com>
Ref: https://github.com/tianocore/edk2/issues/59
Ref: http://www.nvidia.com/object/tesla-servers.html
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
If USE_OLD_PCI_HOST is FALSE, then we switch all executable module types
supported by DxePciLibI440FxQ35 to the following library instance stack:
BasePciSegmentLibPci [class: PciSegmentLib]
DxePciLibI440FxQ35 [class: PciLib]
BasePciCf8Lib [class: PciCf8Lib]
BasePciExpressLib [class: PciExpressLib]
Every module will select 0xCF8 vs. ECAM based on the OVMF platform type
(i440fx or Q35). Notably, MdeModulePkg/Bus/Pci/PciHostBridgeDxe is among
the affected drivers.
The BasePciExpressLib instance is where the PcdPciExpressBaseAddress PCD
fills its original role.
Cc: Gabriel Somlo <somlo@cmu.edu>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Marcel Apfelbaum <marcel@redhat.com>
Cc: Micha Zegan <webczat_200@poczta.onet.pl>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Tested-by: Gabriel Somlo <somlo@cmu.edu>
Tested-by: Micha Zegan <webczat_200@poczta.onet.pl>
The comments in the code should speak for themselves; here we note only
two facts:
- The PCI config space writes (to the PCIEXBAR register) are performed
using the 0xCF8 / 0xCFC IO ports, by virtue of PciLib being resolved to
BasePciLibCf8. (This library resolution will permanently remain in place
for the PEI phase.)
- Since PCIEXBAR counts as a chipset register, it is the responsibility of
the firmware to reprogram it at S3 resume. Therefore
PciExBarInitialization() is called regardless of the boot path. (Marcel
recently posted patches for SeaBIOS that implement this.)
This patch suffices to enable PCIEXBAR (and the dependent ACPI table
generation in QEMU), for the sake of "PCIeHotplug" in the Linux guest:
ACPI: MCFG 0x000000007E17F000 00003C
(v01 BOCHS BXPCMCFG 00000001 BXPC 00000001)
PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0x80000000-0x8fffffff]
(base 0x80000000)
PCI: MMCONFIG at [mem 0x80000000-0x8fffffff] reserved in E820
acpi PNP0A08:00: _OSC: OS supports
[ExtendedConfig ASPM ClockPM Segments MSI]
acpi PNP0A08:00: _OSC: OS now controls
[PCIeHotplug PME AER PCIeCapability]
In the following patches, we'll equip the core PCI host bridge / root
bridge driver and the rest of DXE as well to utilize ECAM on Q35.
Cc: Gabriel Somlo <somlo@cmu.edu>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Marcel Apfelbaum <marcel@redhat.com>
Cc: Micha Zegan <webczat_200@poczta.onet.pl>
Ref: https://github.com/tianocore/edk2/issues/32
Ref: http://thread.gmane.org/gmane.comp.bios.coreboot.seabios/10548
Suggested-by: Marcel Apfelbaum <marcel@redhat.com>
Reported-by: Micha Zegan <webczat_200@poczta.onet.pl>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Marcel Apfelbaum <marcel@redhat.com>
Tested-by: Gabriel Somlo <somlo@cmu.edu>
Tested-by: Micha Zegan <webczat_200@poczta.onet.pl>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Enable the network2 commands when NETWORK_IP6_ENABLE is TRUE, so we
would have Ping6 and Ifconfig6.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gary Ching-Pang Lin <glin@suse.com>
[lersek@redhat.com: added the word "Shell" to the subject]
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
The old driver is retained for now; it remains available with "-D
USE_OLD_PCI_HOST". This is because I'd like to involve end users and
downstreams in testing the new drier, but also allow them to switch back
to the old driver at the first sight of trouble, while we debug the new
driver in parallel.
In a few weeks the ifdeffery and the "OvmfPkg/PciHostBridgeDxe/" driver
should be removed.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Marcel Apfelbaum <marcel@redhat.com>
Cc: Alex Williamson <alex.williamson@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
In the next patch we'll build "MdeModulePkg/Bus/Pci/PciHostBridgeDxe".
That driver depends on the PciSegmentLib class. Edk2 offers four
instances:
(1) MdePkg/Library/UefiPciSegmentLibPciRootBridgeIo/
Inappropriate here because it consumes
EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL, but
"MdeModulePkg/Bus/Pci/PciHostBridgeDxe" needs the library class for
producing that protocol.
(2) MdePkg/Library/PeiPciSegmentLibPciCfg2/
Restricted to PEIM, SEC, and PEI_CORE client modules.
(3) MdePkg/Library/DxePciSegmentLibEsal/
"uses ESAL services to perform PCI Configuration cycles"
(4) MdePkg/Library/BasePciSegmentLibPci/
A simple BASE library instance that sits on top of PciLib. This is our
choice. We can resolve PciSegmentLib to this instance for all module
types.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Marcel Apfelbaum <marcel@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Going forward, two modules will need to know about the aperture:
PlatformPei (as before), and OVMF's upcoming PciHostBridgeLib instance
(because the core PciHostBridgeDxe driver requires the library to state
the exact apertures for all root bridges).
On QEMU, all root bridges share the same MMIO aperture, hence one pair of
PCDs suffices.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Marcel Apfelbaum <marcel@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Because SecureBootConfigDxe use FileExplorerLib now, but
FileExplorerLib is not in the dsc file of the package
that use SecureBootConfigDxe. Now add it to pass build.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Eric Dong <eric.dong@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
This adds the new Virtio-RNG DXE module to all three builds of
OvmfPkg. Note that QEMU needs to be invoked with the 'device
virtio-rng-pci' option in order for this device to be exposed to
the guest.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
QEMU emulates NVMe. NvmExpressDxe seems to work well with it. The relevant
QEMU options are
-drive id=drive0,if=none,format=FORMAT,file=PATHNAME \
-device nvme,drive=drive0,serial=SERIAL
where the required SERIAL value sets the Serial Number (SN) field of the
"Identify Controller Data Structure". It is an ASCII string with up to 20
characters, which QEMU pads with spaces to maximum length.
(Refer to "NVME_ADMIN_CONTROLLER_DATA.Sn" in
"MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.h".)
Cc: Vladislav Vovchenko <vladislav.vovchenko@sk.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Reference: https://github.com/tianocore/edk2/issues/48
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Tested-by: Vladislav Vovchenko <vladislav.vovchenko@sk.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19791 6f19259b-4bc3-4df7-8a09-765794883524
Change the image verification policy for option ROM images to 0x00
(ALWAYS_EXECUTE).
While this may not be a good idea for physical platforms (see e.g.
<https://trmm.net/Thunderstrike>), on the QEMU platform the benefits seem
to outweigh the drawbacks:
- For QEMU's virtual PCI devices, and for some assigned PCI devices, the
option ROMs come from host-side files, which can never be rewritten from
within the guest. Since the host admin has full control over a guest
anyway, executing option ROMs that originate from host-side files
presents no additional threat to the guest.
- For assigned physical PCI devices with option ROMs, the argument is not
so clear-cut. In theory a setup could exist where:
- the host-side UEFI firmware (with DENY_EXECUTE_ON_SECURITY_VIOLATION)
rejects the option ROM of a malicious physical PCI device, but
- when the device is assigned to the guest, OVMF executes the option ROM
in the guest,
- the option ROM breaks out of the guest (using an assumed QEMU
vulnerability) and gains QEMU user privileges on the host.
However, in order to escalate as far as it would happen on the bare
metal with ALWAYS_EXECUTE (i.e., in order to gain firmware-level access
on the host), the malicious option ROM would have to break through (1)
QEMU, (2) traditional UID and GID based privilege separation on the
host, (3) sVirt (SELinux) on the host, (4) the host OS - host firmware
boundary. This is not impossible, but not likely enough to discourage
the use cases below.
- This patch makes it possible to use unsigned iPXE network drivers that
QEMU presents in the option ROMs of virtual NICs and assigned SR-IOV
VFs, even if Secure Boot is in User Mode or Deployed Mode.
- The change also makes it possible to execute unsigned, outdated
(revoked), or downright malicious option ROMs of assigned physical
devices in guests, for corporate, entertainment, academia, or security
research purposes.
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Chao Zhang <chao.b.zhang@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Chao Zhang <chao.b.zhang@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19614 6f19259b-4bc3-4df7-8a09-765794883524
Secure Boot support was originally addded to OvmfPkg on 2012-Mar-09, in
SVN r13093 (git 8cee3de7e9), titled
OvmfPkg: Enable secure-boot support when SECURE_BOOT_ENABLE==TRUE
At that time the image verification policies in
SecurityPkg/SecurityPkg.dec were:
- option ROM image: 0x00 (ALWAYS_EXECUTE)
- removable media image: 0x05 (QUERY_USER_ON_SECURITY_VIOLATION)
- fixed media image: 0x05 (QUERY_USER_ON_SECURITY_VIOLATION)
The author of SVN r13093 apparently didn't want to depend on the
SecurityPkg defaults for the latter two image origins, plus the
ALWAYS_EXECUTE policy for option ROM images must have been deemed too lax.
For this reason SVN r13093 immediately spelled out 0x05
(QUERY_USER_ON_SECURITY_VIOLATION) within OvmfPkg for all three image
origins.
Fast forward to 2013-Aug-28: policy 0x05
(QUERY_USER_ON_SECURITY_VIOLATION) had been forbidden in the UEFI spec,
and SVN r14607 (git db44ea6c4e) reflected this in the source code:
- The policies for the latter two image origins were switched from 0x05 to
0x04 (DENY_EXECUTE_ON_SECURITY_VIOLATION) in SecurityPkg,
- the patch changed the default policy for option ROM images too, from
0x00 (ALWAYS_EXECUTE) to 0x04 (DENY_EXECUTE_ON_SECURITY_VIOLATION),
- any other client DSC files, including OvmfPkg's, underwent a whole-sale
0x05 (QUERY_USER_ON_SECURITY_VIOLATION) -> 0x04
(DENY_EXECUTE_ON_SECURITY_VIOLATION) replacement too.
The practical result of that patch for OvmfPkg was that the explicit 0x04
settings would equal the strict SecurityPkg defaults exactly.
And that's what we have today: the "override the default values from
SecurityPkg" comments in OvmfPkg's DSC files are stale, in practice.
It is extremely unlikely that SecurityPkg would change the defaults from
0x04 (DENY_EXECUTE_ON_SECURITY_VIOLATION) any time in the future, so let's
just inherit those in OvmfPkg.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Fu Siyuan <siyuan.fu@intel.com>
Cc: Chao Zhang <chao.b.zhang@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Fu Siyuan <siyuan.fu@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Chao Zhang <chao.b.zhang@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19613 6f19259b-4bc3-4df7-8a09-765794883524
When -D SMM_REQUIRE is given, replace both
- OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf and
- OvmfPkg/EmuVariableFvbRuntimeDxe/Fvb.inf
with
- OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesSmm.inf.
The outermost (= runtime DXE driver) VariableSmmRuntimeDxe enters SMM, and
the rest:
- the privileged half of the variable driver, VariableSmm,
- the fault tolerant write driver, FaultTolerantWriteSmm,
- and the FVB driver, FvbServicesSmm,
work in SMM purely.
We also resolve the BaseCryptLib class for DXE_SMM_DRIVER modules, for the
authenticated VariableSmm driver's sake.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19065 6f19259b-4bc3-4df7-8a09-765794883524
The following modules constitute the variable driver stack:
- QemuFlashFvbServicesRuntimeDxe and EmuVariableFvbRuntimeDxe, runtime
alternatives for providing the Firmware Volume Block(2) Protocol,
dependent on qemu pflash presence,
- FaultTolerantWriteDxe, providing the Fault Tolerant Write Protocol,
- MdeModulePkg/Universal/Variable/RuntimeDxe, independently of
-D SECURE_BOOT_ENABLE, providing the Variable and Variable Write
Architectural Protocols.
Let's move these drivers closer to each other in the DSC and FDF files, so
that we can switch the variable driver stack to SMM with more local
changes.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19064 6f19259b-4bc3-4df7-8a09-765794883524
At this point we can enable building PiSmmCpuDxeSmm.
CPU specific features, like SMRR detection, and functions that are used to
initialize SMM and process SMIs, are abstracted through the
SmmCpuFeaturesLib class for the PiSmmCpuDxeSmm module. Resolve it to our
own implementation under OvmfPkg -- it allows PiSmmCpuDxeSmm to work with
QEMU's and KVM's 64-bit state save map format, which follows the
definition from AMD's programmer manual.
SmmCpuPlatformHookLib provides platform specific functions that are used
to initialize SMM and process SMIs. Resolve it to the one Null instance
provided by UefiCpuPkg, which is expected to work for most platforms.
Cc: Paolo Bonzini <pbonzini@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
[pbonzini@redhat.com: resolve the SmmCpuFeaturesLib class to OVMF's own
instance]
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19061 6f19259b-4bc3-4df7-8a09-765794883524
The PiSmmCpuDxeSmm driver from UefiCpuPkg depends on the ACPI_CPU_DATA
structure -- created by a platform- and CPU-specific driver -- in order to
support ACPI S3. The address of this structure is communicated through the
dynamic PCD PcdCpuS3DataAddress.
The "UefiCpuPkg/Include/AcpiCpuData.h" header file documents the fields of
this structure in detail.
The simple/generic "UefiCpuPkg/CpuS3DataDxe" driver creates and populates
the structure in a conformant way, and it co-operates well with
PiSmmCpuDxeSmm, for OVMF's purposes.
PlatformBdsLib CpuS3DataDxe PiSmmCpuDxeSmm S3Resume2Pei
(DXE_DRIVER) (DXE_DRIVER) (DXE_SMM_DRIVER) (PEIM)
-------------- --------------- ---------------- --------------
normal collects data
boot except MTRR
settings into
ACPI_CPU_DATA
sets
PcdCpuS3Da...
signals
End-of-Dxe
|
+----------> collects MTRR
settings into
ACPI_CPU_DATA
installs
[Dxe]Smm
ReadyToLock
|
+---------------------------> fetches
PcdCpuS3Dat...
copies
ACPI_CPU_DATA
into SMRAM
runtime
S3
suspend
S3 transfers
resume control to
PiSmmCpuDxe...
|
uses <----+
ACPI_CPU_DATA
from SMRAM
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19060 6f19259b-4bc3-4df7-8a09-765794883524
This patch complements the previous one, "OvmfPkg: use relaxed AP SMM
synchronization mode". While that patch focuses on the case when the SMI
is raised synchronously by the BSP, on the BSP:
BSPHandler() [UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c]
SmmWaitForApArrival() [UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c]
IsSyncTimerTimeout() [UefiCpuPkg/PiSmmCpuDxeSmm/SyncTimer.c]
this patch concerns itself with the case when it is one of the APs that
raises (and sees delivered) the synchronous SMI:
APHandler() [UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c]
IsSyncTimerTimeout() [UefiCpuPkg/PiSmmCpuDxeSmm/SyncTimer.c]
Namely, in APHandler() the AP waits for the BSP to enter SMM regardless of
PcdCpuSmmSyncMode, for PcdCpuSmmApSyncTimeout microseconds (the default
value is 1 second). If the BSP doesn't show up in SMM within that
interval, then the AP brings it in with a directed SMI, and waits for the
BSP again for PcdCpuSmmApSyncTimeout microseconds.
Although during boot services, SmmControl2DxeTrigger() is only called by
the BSP, at runtime the OS can invoke runtime services from an AP (it can
even be forced with "taskset -c 1 efibootmgr"). Because on QEMU
SmmControl2DxeTrigger() only raises the SMI for the calling processor (BSP
and AP alike), the first interval above times out invariably in such cases
-- the BSP never shows up before the AP calls it in.
In order to mitigate the performance penalty, decrease
PcdCpuSmmApSyncTimeout to one tenth of its default value: 100 ms. (For
comparison, Vlv2TbltDevicePkg sets 1 ms.)
NOTE: once QEMU becomes capable of synchronous broadcast SMIs, this patch
and the previous one ("OvmfPkg: use relaxed AP SMM synchronization mode")
should be reverted, and SmmControl2DxeTrigger() should be adjusted
instead.
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19059 6f19259b-4bc3-4df7-8a09-765794883524
Port 0xb2 on QEMU only sends an SMI to the currently executing processor.
The SMI handler, however, and in particular SmmWaitForApArrival, currently
expects that SmmControl2DxeTrigger triggers an SMI IPI on all processors
rather than just the BSP. Thus all SMM invocations loop for a second (the
default value of PcdCpuSmmApSyncTimeout) before SmmWaitForApArrival sends
another SMI IPI to the APs.
With the default SmmCpuFeaturesLib, 32-bit machines must broadcast SMIs
because 32-bit machines must reset the MTRRs on each entry to system
management modes (they have no SMRRs). However, our virtual platform
does not have problems with cacheability of SMRAM, so we can use "directed"
SMIs instead. To do this, just set gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmSyncMode
to 1 (aka SmmCpuSyncModeRelaxedAp). This fixes SMM on multiprocessor virtual
machines.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19058 6f19259b-4bc3-4df7-8a09-765794883524
Explanation from Michael Kinney:
This PCD allows a platform to provide PlatformSmmBspElection() in a
platform specific SmmCpuPlatformHookLib instance to decide which CPU
gets elected to be the BSP in each SMI.
The SmmCpuPlatformHookLibNull [instance] always returns EFI_NOT_READY
for that function, which makes the module behave the same as the PCD
being set to FALSE.
The default is TRUE, so the platform lib is always called, so a platform
developer can implement the hook function and does not have to also
change a PCD setting for the hook function to be active.
A platform that wants to eliminate the call to the hook function
[altogether] can set the PCD to FALSE.
So for OVMF, I think it makes sense to set this PCD to FALSE in the DSC
file.
Suggested-by: Michael Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19053 6f19259b-4bc3-4df7-8a09-765794883524
Although neither LocalApicLib instance is suitable for runtime DXE drivers
(because they access the APIC at the physical address retrieved from
either MSR_IA32_APIC_BASE_ADDRESS or PcdCpuLocalApicBaseAddress), they are
suitable for SMM drivers -- SMM drivers are not influenced by the runtime
OS's virtual address map.
PiSmmCpuDxeSmm links against LocalApicLib. 64-bit Linux guests tend to
enable x2apic mode even in simple VCPU configurations (e.g., 4 sockets, 1
core/socket, 1 thread/core):
[ 0.028173] x2apic enabled
If PiSmmCpuDxeSmm was linked with the BaseXApicLib instance (i.e., with no
x2apic support), then the next runtime service call that is backed by an
SMM driver triggers the following ASSERT in BaseXApicLib (because the
latter notices that x2apic has been enabled, which it doesn't support):
ASSERT .../UefiCpuPkg/Library/BaseXApicLib/BaseXApicLib.c(263):
ApicBaseMsr.Bits.Extd == 0
It is reasonable to give all LocalApicLib client modules in OVMF the same
level of x2apic support, hence resolve LocalApicLib globally to
BaseXApicX2ApicLib. This will not be conditional on -D SMM_REQUIRE,
because BaseXApicX2ApicLib is compatible with BaseXApicLib in any
environment where the latter can be used.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19052 6f19259b-4bc3-4df7-8a09-765794883524
UefiCpuPkg/PiSmmCpuDxeSmm depends on this library (the
RegisterCpuInterruptHandler() function specifically) to set up its
specialized page fault handler (SmiPFHandler() -> DumpModuleInfoByIp()).
It doesn't hurt to resolve this library class for all DXE_SMM_DRIVER
modules.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19050 6f19259b-4bc3-4df7-8a09-765794883524
PiSmmCpuDxeSmm depends on this library class, and it's okay to resolve it
generally for all DXE_SMM_DRIVER modules.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19049 6f19259b-4bc3-4df7-8a09-765794883524
During DXE, drivers save data in the LockBox. A save operation is layered
as follows:
- The unprivileged driver wishing to store data in the LockBox links
against the "MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.inf"
library instance.
The library allows the unprivileged driver to format requests for the
privileged SMM LockBox driver (see below), and to parse responses.
We apply this resolution for DXE_DRIVER modules.
- The privileged SMM LockBox driver is built from
"MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.inf". This driver
has module type DXE_SMM_DRIVER and can access SMRAM.
The driver delegates command parsing and response formatting to
"MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxSmmLib.inf".
Therefore we include this DXE_SMM_DRIVER in the build, and apply said
resolution specifically to it.
(Including the driver requires us to resolve a few of other library
classes for DXE_SMM_DRIVER modules.)
- In PEI, the S3 Resume PEIM (UefiCpuPkg/Universal/Acpi/S3Resume2Pei)
retrieves data from the LockBox. It is capable of searching SMRAM
itself.
We resolve LockBoxLib to
"MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.inf" specifically
for this one PEIM.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19048 6f19259b-4bc3-4df7-8a09-765794883524
Ruiyu Ni
Laszlo Ersek
Jeff Fan
Cinnamon Shia
Bruce Cran
Hao Wu
Jordan Justen
Star Zeng
Alcantara, Paulo
James Bottomley
Gary Lin
Dandan Bi
Ard Biesheuvel
Paolo Bonzini
Michael Kinney