The patch uses EfiBootManagerRefreshAllBootOption() to collect
all boot options and uses SetBootOrderFromQemu exposed by
QemuNewBootOrderLib to adjust the boot option order.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
The patch changes PlatformBdsConnectSequence() to use library API
exposed from UefiBootManagerLib and removes the additional
connect ALL action.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
MdeModulePkg/BDS doesn't launch UI (Boot Manager Menu) from platform
side.
The change removes the code which launches the UI but still set the
boot timeout.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
The major difference between IntelFrameworkModulePkg/BDS and
MdeModulePkg/BDS is the latter connects the consoles in core
code while the former connects in platform code.
The change initializes the console variables in
PlatformBootManagerBeforeConsole() and removes the console
connection code.
It also removes unused functions: PlatformBdsNoConsoleAction()
and LockKeyboards().
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
The DevicePathToStr() function (in
"IntelFrameworkModulePkg/Library/GenericBdsLib/DevicePath.c") is a
simple wrapper around ConvertDevicePathToText().
DevicePathToStr() passes DisplayOnly=TRUE and AllowShortcuts=TRUE to
ConvertDevicePathToText(), whereas in this patch, both parameters are
flipped to FALSE.
The formatted devpaths are used only for debugging purposes, so this
change is safe.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Change the function name to follow new library class
PlatformBootManagerLib interfaces.
NOTE: There is no progress bar during BDS timeout waiting.
In order to show the progress bar, PlatformBootManagerWaitCallback ()
needs to change to draw it.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
It will be changed to build with MdeModulePkg/BDS.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
NOTE: SetBootOrderFromQemu() interface is not changed.
But when the old IntelFrameworkModulePkg/BDS is no longer used in
OVMF and ArmVirtPkg, additional patch will be submitted to change
this interface to remove parameter BootOptionList.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
QemuNewBootOrderLib will be changed to work with MdeModulePkg/BDS.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
At the moment, the EFI_DXE_SMM_READY_TO_LOCK_PROTOCOL is only installed if
S3 is enabled -- at the end of SaveS3BootScript().
While a runtime OS is never booted with SMM unlocked (because the SMM IPL
locks down SMM as a last resort:
> SMM IPL! DXE SMM Ready To Lock Protocol not installed before Ready To
> Boot signal
> SmmInstallProtocolInterface: [EfiSmmReadyToLockProtocol] 0
> Patch page table start ...
> Patch page table done!
> SMM IPL locked SMRAM window
), we shouldn't allow UEFI drivers and applications either to mess with
SMM just because S3 is disabled. So install
EFI_DXE_SMM_READY_TO_LOCK_PROTOCOL in PlatformBdsInit() unconditionally.
Cc: Feng Tian <feng.tian@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
OVMF's PlatformBdsLib currently makes SMM vulnerable to the following
attack:
(1) a malicious guest OS copies a UEFI driver module to the EFI system
partition,
(2) the OS adds the driver as a Driver#### option, and references it from
DriverOrder,
(3) at next boot, the BdsEntry() function in
"IntelFrameworkModulePkg/Universal/BdsDxe/BdsEntry.c" processes
Driver#### and DriverOrder between the calls to PlatformBdsInit() and
PlatformBdsPolicyBehavior(),
(4) OVMF locks down SMM only in PlatformBdsPolicyBehavior(), hence the
driver runs with SMM unlocked.
The BdsEntry() function of the MdeModulePkg BDS driver (in file
"MdeModulePkg/Universal/BdsDxe/BdsEntry.c") recommends to "Signal
ReadyToLock event" in PlatformBootManagerBeforeConsole() -- which
corresponds to PlatformBdsInit() --, not in
PlatformBootManagerAfterConsole() -- which corresponds to
PlatformBdsPolicyBehavior().
Albeit an independent question, but it's worth mentioning: this patch also
brings OvmfPkg's PlatformBdsInit() closer to ArmVirtPkg's. Namely, the
latter signals End-of-Dxe in PlatformBdsInit() already.
Cc: Feng Tian <feng.tian@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
XenIoMmioLib depends on MemoryAllocationLib, and uses its header, but
failed to declare the dependency in its INF.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Currently, the LockBox protocol is installed in entrypoint of
OVMF AcpiS3SaveDxe.
We can let the first driver run with LockBoxDxeLib linked to have its
library constructor to install LockBox protocol on the ImageHandle.
As other drivers may have gEfiLockBoxProtocolGuid dependency,
the first driver should run before them.
The later patches to retire AcpiS3SaveDxe for OVMF depends on this patch.
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>
In VirtIo 1.0, a device can reject a self-inconsistent feature bitmap
through the new VSTAT_FEATURES_OK status bit. (For example if the driver
requests a higher level feature but clears a prerequisite feature.) This
function is a small wrapper around
VIRTIO_DEVICE_PROTOCOL.SetGuestFeatures() that also verifies if the VirtIo
1.0 device accepts the feature bitmap.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
In virtio-1.0, it is not enough to pass the base address of the virtio
queue to the hypervisor (as a frame number); instead it will want the
addresses of the descriptor table, the available ring, and the used ring
separately. Pass the VRING object to the SetQueueAddress() member
function; this will enable a virtio-1.0 implementation. Convert the
current producers and consumers to this prototype.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
This function was never consumed by drivers, and the current prototype is
unsupportable with virtio-1.0. Remove the function from the protocol
definition, and drop the current (unused) implementations.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
The virtio-1.0 spec widens the Features bitmap to 64 bits. Modify the
declarations of the GetDeviceFeatures() and SetGuestFeatures() protocol
member functions accordingly.
Normally, a protocol cannot be changed in incompatible ways if the GUID
stays the same; however, we've always been extremely clear that
VIRTIO_DEVICE_PROTOCOL is internal to edk2. See for example the top of
"OvmfPkg/Include/Protocol/VirtioDevice.h".
In this patch, all producers and consumers of the GetDeviceFeatures() and
SetGuestFeatures() protocol members are updated.
The drivers that currently produce these members are "legacy" drivers (in
virtio-1.0 terminology), and they cannot (and will not) handle feature
bits above BIT31. Therefore their conversion is only for compatibility
with the modified protocol interface. The consumers will be responsible
for checking the VIRTIO_DEVICE_PROTOCOL.Revision field, and for not
passing feature bits that these backends cannot handle.
The VirtioMmioGetDeviceFeatures() implementation stores the result of an
MmioRead32() call with normal assignment, so it needs no change beyond
adapting its prototype.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
On the normal boot path (which is when PciHostBridgeDxe runs), the PCDs
have been calculated; report the 64-bit PCI host aperture to
PciHostBridgeDxe.
In the Ia32 build, the PCD values (zeros) come directly from the DEC file,
and this patch makes no difference.
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
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
The explanation is in the patch titled
OvmfPkg: introduce gRootBridgesConnectedEventGroupGuid
At this point, this signal doesn't do anything yet.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
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>
By now OVMF makes MdeModulePkg/Bus/Pci/PciHostBridgeDxe go through
MMCONFIG (when running on Q35). Enable the driver to address each B/D/F's
config space up to and including offset 0xFFF.
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>
This library is a trivial unification of the following two PciLib
instances (and the result is easily diffable against each):
- MdePkg/Library/BasePciLibCf8
- MdePkg/Library/BasePciLibPciExpress
The PCI config access method is determined in the constructor function,
from the dynamic PCD "PcdOvmfHostBridgePciDevId" that is set by
PlatformPei.
The library instance is usable in DXE phase or later modules: the PciLib
instances being unified have no firmware phase / client module type
restrictions, and here the only PCD access is made in the constructor
function. That is, even before a given client executable's entry point is
invoked.
The library instance depends on PlatformPei both for setting the PCD
mentioned above, and also for enabling MMCONFIG on Q35. PEI and earlier
phase modules are not expected to need extended config access even 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>
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>
We copy the code from InitRootBridge()
[OvmfPkg/PciHostBridgeDxe/PciHostBridge.c], with a slight change: the
device path is allocated separately now.
This is the final field to initialize in PCI_ROOT_BRIDGE.
The type EFI_PCI_ROOT_BRIDGE_DEVICE_PATH is renamed to
OVMF_PCI_ROOT_BRIDGE_DEVICE_PATH. The original is a misnomer (it is not a
standard UEFI type) that dates back to PcAtChipsetPkg/PciHostBridgeDxe.
Simply removing the EFI_ suffix would result in
PCI_ROOT_BRIDGE_DEVICE_PATH, where PCI_ could incorrectly suggest a
relation with the PCI standards or the PCI-related generic edk2 code.
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>
In "OvmfPkg/PciHostBridgeDxe/PciRootBridgeIo.c", the
RootBridgeIoCheckParameter() function hard-codes the maximum offset for
the PCI config space as 0xFF (see the MAX_PCI_REG_ADDRESS macro), which
matches OVMF's 0xCF8 / 0xCFC config access method.
The "MdeModulePkg/Bus/Pci/PciHostBridgeDxe" driver abstracts away config
space access via the PciSegmentLib class, so it has to be informed
separately about the config space size.
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>
The bus aperture is copied verbatim from InitRootBridge()
[OvmfPkg/PciHostBridgeDxe/PciHostBridge.c].
The IO and 32-bit MMIO apertures are matched to PlatformPei's settings.
PciHostBridgeLibDxe expects PciHostBridgeLib instances to advertize the
exact apertures.
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>
InitRootBridge() in "OvmfPkg/PciHostBridgeDxe/PciHostBridge.c" passes the
EFI_PCI_HOST_BRIDGE_COMBINE_MEM_PMEM allocation attribute to
RootBridgeConstructor(); we should do the same here.
From "MdePkg/Include/Protocol/PciHostBridgeResourceAllocation.h":
/// If this bit is set, then the PCI Root Bridge does not support separate
/// windows for Non-prefetchable and Prefetchable memory. A PCI bus driver
/// needs to include requests for Prefetchable memory in the
/// Non-prefetchable memory pool.
Which implies that both the 32-bit and 64-bit prefetchable MMIO apertures
should be marked empty. (The CreateRootBridge() function actually enforces
this in "MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c".)
Furthermore, since OvmfPkg/PciHostBridgeDxe does *not* set the
EFI_PCI_HOST_BRIDGE_MEM64_DECODE allocation attribute:
/// If this bit is set, then the PCI Root Bridge supports 64 bit memory
/// windows. If this bit is not set, the PCI bus driver needs to include
/// requests for 64 bit memory address in the corresponding 32 bit memory
/// pool.
we follow suit in the PciHostBridgeLib instance.
In turn, the 64-bit MMIO apertures (both prefetchable and
non-prefetchable) should be marked empty.
MdeModulePkg/Bus/Pci/PciHostBridgeDxe enforces this too.
(64-bit MMIO aperture support, based on yet more fw_cfg files, is a
planned future improvement.)
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>
When this BOOLEAN member is FALSE, and the caller tries to set up a DMA
transfer between a PCI device and a host buffer not entirely under 4GB,
then "MdeModulePkg/Bus/Pci/PciHostBridgeDxe" sets up a bounce buffer under
4GB, in the implementation of EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL.Map().
Since that's exactly what RootBridgeIoMap() does in
"OvmfPkg/PciHostBridgeDxe/PciRootBridgeIo.c", stick with it in this
conversion.
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>
These settings are copied from the RootBridgeConstructor() function, file
"OvmfPkg/PciHostBridgeDxe/PciRootBridgeIo.c".
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>
This is the first of the patches that set the fields of PCI_ROOT_BRIDGE.
The structure is zero-filled as a precaution for later field additions.
Here we set the Segment member explicitly to zero (so that any later
customization can be easier).
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>
This function has no counterpart in OvmfPkg/PciHostBridgeDxe/, but the
PciHostBridgeLib class requires it.
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>
In this patch we import the scan for extra root buses from the
InitializePciHostBridge() function, in file
"OvmfPkg/PciHostBridgeDxe/PciHostBridge.c".
For the time being, the InitRootBridge() and UninitRootBridge() functions
are just placeholders.
The PciHostBridgeGetRootBridges() API expects us to return the
PCI_ROOT_BRIDGE structures in a contiguous array, instead of a linked
list. Therefore the following bits have to be converted manually:
(1) The array is allocated in advance, in a single step.
(2) The calculation of the array size depends on an explicit
multiplication, which we must check against overflow. Since more than
255 extra root bridges make no sense anyway, we use (1 + 255) as the
limit on the main plus all extra root bridges. This also ensures that
the UINTN multiplication doesn't overflow.
(3) The PciHostBridgeDxe code decrements "ExtraRootBridgesLeft" to
terminate the scanning early. Here we need track the increasing count
of used array elements as well, so we employ "ExtraRootBridges" as a
constant limit, and increment the new local variable "Initialized".
(4) The prototypes of InitRootBridge() and UninitRootBridge() reflect that
the PCI_ROOT_BRIDGE structure is allocated by the caller; only
in-place initialization is necessary.
Additionally, macros are employed for standard PCI quantities, from
"MdePkg/Include/IndustryStandard/Pci22.h":
- MAX_PCI_DEVICE_NUMBER (31) is replaced with PCI_MAX_DEVICE (same),
- the constant 255 is replaced with PCI_MAX_BUS,
- the (RootBridgeNumber < 256) condition is replaced with
(RootBridgeNumber <= PCI_MAX_BUS).
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>
In this patch we clone "MdeModulePkg/Library/PciHostBridgeLibNull" for
customization under OvmfPkg. Differences relative to a verbatim copy:
- the Null suffix is dropped from file names,
- the UNI file is dropped, together with the corresponding MODULE_UNI_FILE
reference in the INF file,
- the INF file receives a new FILE_GUID,
- the top comments in the files mention OVMF, not a null instance.
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>
VirtioLib provides an API for simple, synchronous (request/response-style)
virtio communication. The guest driver builds one descriptor chain, link
for link, with VirtioPrepare() and VirtioAppendDesc(), then submits the
chain, and awaits the processing, with VirtioFlush().
The descriptor chain is always built at the beginning of the descriptor
area, with the head descriptor having descriptor index 0.
In order to submit the descriptor chain to the host, the guest always
pushes a new "available element" to the Available Ring, in genuine
queue-like fashion, with the new element referencing the head descriptor
(which always has index 0, see above).
In turn, after processing, the host always pushes a new "used element" to
the Used Ring, in genuine queue-like fashion, with the new element
referencing the head descriptor of the chain that was just processed. The
same element also reports the number of bytes that the host wrote,
consecutively across the host-writeable buffers that were linked by the
descriptors.
(See "OvmfPkg/VirtioNetDxe/TechNotes.txt" for a diagram about the
descriptor area and the rings.)
Because at most one descriptor chain can be in flight with VirtioLib at
any time,
- the Available Ring and the Used Ring proceed in lock-step,
- and the head descriptor that the new "available" and "used" elements can
ever reference has index 0.
Based on the above, we can modify VirtioFlush() to return the number of
bytes written by the host across the descriptor chain. The virtio-block
and virtio-scsi drivers don't care (they have other ways to parse the data
produced by the host), while the virtio-net driver doesn't use
VirtioFlush() at all (it employs VirtioLib only to set up its rings).
However, the virtio entropy device, to be covered in the upcoming
patches, reports the amount of randomness produced by the host only
through this quantity.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
GCC_ASM_EXPORT() not only exports a symbol as a function, it also emits
a .type <xxx>, %function directive, which is used by the ARM linker to
decide whether to emit interworking branches. So replace the explicit
.global with GCC_ASM_EXPORT(), or the code will not be callable from
Thumb-2 code.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19329 6f19259b-4bc3-4df7-8a09-765794883524
This adjusts the previously introduced state save map access functions, to
account for QEMU and KVM's 64-bit state save map following the AMD spec
rather than the Intel one.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
[lersek@redhat.com: reflow commit message, convert patch to CRLF]
Cc: Paolo Bonzini <pbonzini@redhat.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@19057 6f19259b-4bc3-4df7-8a09-765794883524
This implementation copies SMRAM state save map access from the
PiSmmCpuDxeSmm module.
The most notable change is:
- dropping support for EFI_SMM_SAVE_STATE_REGISTER_IO
- changing the implementation of EFI_SMM_SAVE_STATE_REGISTER_LMA to use
the SMM revision id instead of a local variable (which
UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c initializes from CPUID's LM
bit). This accounts for QEMU's implementation of x86_64, which always
uses revision 0x20064 even if the LM bit is zero.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
[lersek@redhat.com: reflow commit message & fix typo, convert patch to
CRLF]
Cc: Paolo Bonzini <pbonzini@redhat.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@19056 6f19259b-4bc3-4df7-8a09-765794883524
SMRR, MTRR, and SMM Feature Control support is not needed on a virtual
platform.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
[lersek@redhat.com: insert space between ASSERT and (), convert to CRLF,
refresh against SVN r18958]
Cc: Paolo Bonzini <pbonzini@redhat.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@19055 6f19259b-4bc3-4df7-8a09-765794883524
The next patches will customize the implementation, but let's start from
the common version to better show the changes.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
[lersek@redhat.com: drop UNI file, keep whitespace intact, generate new
FILE_GUID, split off DSC changes, reflow commit message, refresh against
SVN r18958]
Cc: Paolo Bonzini <pbonzini@redhat.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@19054 6f19259b-4bc3-4df7-8a09-765794883524
When the user builds OVMF with -D SMM_REQUIRE, our LockBox implementation
must not be used, since it doesn't actually protect data in the LockBox
from the runtime guest OS. Add an according assert to
LockBoxLibInitialize().
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19046 6f19259b-4bc3-4df7-8a09-765794883524
The OpenFirmware device paths that QEMU generates for these disks and
CD-ROMs are very similar to those generated for the i440fx IDE disks and
CD-ROMs (including the same number of devpath nodes necessary for unique
parsing). The interpretations and the translation to UEFI devpath
fragments are different, of course.
(The spaces after "ide@1,1" are inserted below only for illustration
purposes.)
primary or secondary
| master or slave
v v
i440fx IDE: /pci@i0cf8/ide@1,1 /drive@0/disk@0
Q35 SATA: /pci@i0cf8/pci8086,2922@1f,2/drive@1/disk@0
^ ^
| device number
| (fixed 0)
channel (port) number
The similarity is reflected in the translation output (spaces again
inserted for illustration only):
i440fx IDE: PciRoot(0x0)/Pci(0x1,0x1) /Ata(Primary,Master,0x0)
Q35 SATA: PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x1,0x0,0x0)
^ ^ ^
| | LUN;
| | always 0 on Q35
| port multiplier port
| number; always 0 on Q35
channel (port) number
Cc: Alexander Graf <agraf@suse.de>
Cc: Reza Jelveh <reza.jelveh@tuhh.de>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Hannes Reinecke <hare@suse.de>
Cc: Gabriel L. Somlo <somlo@cmu.edu>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18531 6f19259b-4bc3-4df7-8a09-765794883524
Also set the DocRev field the way QEMU exposes it, because
MdeModulePkg/Universal/SmbiosDxe lets us control that field too.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Wei Huang <wei@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Gabriel L. Somlo <somlo@cmu.edu>
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@18182 6f19259b-4bc3-4df7-8a09-765794883524
At this point all platforms that use OvmfPkg/SmbiosPlatformDxe in edk2,
namely ArmVirtQemu.dsc and OvmfPkg*.dsc, have been migrated to
SmbiosVersionLib. Therefore SmbiosPlatformDxe itself can forego verifying
QEMU's SMBIOS entry point; if SmbiosVersionLib's validation was
successful, it should just rely on that.
(Note that SmbiosPlatformDxe has a depex on EFI_SMBIOS_PROTOCOL, installed
by SmbiosDxe, containing SmbiosVersionLib, therefore the set/get order of
PcdQemuSmbiosValidated is ensured.)
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Wei Huang <wei@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Gabriel L. Somlo <somlo@cmu.edu>
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@18180 6f19259b-4bc3-4df7-8a09-765794883524
Introduce a minimal library instance for fetching and validating the
SMBIOS entry point structure exposed by QEMU over fw_cfg. This library is
meant to be hooked into MdeModulePkg/Universal/SmbiosDxe by platform DSC
files, so that the library can set the PCD(s) that SmbiosDxe consumes at
the right moment.
At the moment only SMBIOS 2.x entry points are recognized.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Wei Huang <wei@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Gabriel L. Somlo <somlo@cmu.edu>
Suggested-by: 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>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18174 6f19259b-4bc3-4df7-8a09-765794883524
The LineNumber parameter of the DebugAssert() function has type UINTN.
DebugAssert() passes it to AsciiSPrint() with the %d conversion specifier
at the moment, but %d would require an INT32 argument.
Fix this by casting LineNumber to UINT64, also employing the matching
decimal conversion specifier, %Lu.
(Another possibility would be to cast LineNumber to INT32, but a
UINTN->INT32 cast is not value preserving, generally speaking.)
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Scott Duplichan <scott@notabs.org>
Reported-by: Scott Duplichan <scott@notabs.org>
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@18173 6f19259b-4bc3-4df7-8a09-765794883524
Currently we have the following call chain in OVMF:
PlatformBdsPolicyBehavior()
[OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c]
//
// signals End-of-Dxe
//
OnEndOfDxe() [OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c]
S3Ready() [OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c]
//
// 1. saves S3 state
//
SaveS3BootScript() [OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c]
//
// 2. saves INFO opcode in S3 boot script
// 3. installs DxeSmmReadyToLockProtocol
//
The bottom of this call chain was introduced in git commit 5a217a06 (SVN
r15305, "OvmfPkg: S3 Suspend: save boot script after ACPI context"). That
patch was necessary because there was no other way, due to GenericBdsLib
calling S3Save() from BdsLibBootViaBootOption(), to perform the necessary
steps in the right order:
- save S3 system information,
- save a final (well, only) boot script opcode,
- signal DxeSmmReadyToLock, closing the boot script, and locking down
LockBox and SMM.
The GenericBdsLib bug has been fixed in the previous patch -- the call in
BdsLibBootViaBootOption() has been eliminated.
Therefore, hoist the SaveS3BootScript() code, and call, from
OvmfPkg/AcpiS3SaveDxe, to PlatformBdsLib:
PlatformBdsPolicyBehavior()
[OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c]
//
// signals End-of-Dxe
//
OnEndOfDxe() [OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c]
S3Ready() [OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c]
//
// 1. saves S3 state
//
<---
SaveS3BootScript() [OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c]
//
// 2. saves INFO opcode in S3 boot script
// 3. installs DxeSmmReadyToLockProtocol
//
The installation of DxeSmmReadyToLockProtocol belongs with Platform BDS,
not AcpiS3SaveDxe, and we can now undo the hack in SVN r15305, without
upsetting the relative order of the steps.
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>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18037 6f19259b-4bc3-4df7-8a09-765794883524
(Paraphrasing git commit 9cd7d3c5 / SVN r17713:)
Currently, OvmfPkg fails to signal the End-of-Dxe event group when
entering the BDS phase, which results in some loss of functionality, eg.
variable reclaim in the variable driver, and the memory region splitting
in the DXE core that belongs to the properties table feature specified in
UEFI-2.5.
As discussed on the edk2-devel mailing list here:
http://thread.gmane.org/gmane.comp.bios.tianocore.devel/16088/focus=16109
it is up to the platform BDS to signal End-of-Dxe, since there may be
platform specific ordering constraints with respect to the signalling of
the event that are difficult to honor at the generic level.
(OvmfPkg specifics:)
(1) In OvmfPkg, we can't signal End-of-Dxe before PCI enumeration
completes. According to the previous patch, that would trigger
OvmfPkg/AcpiS3SaveDxe to save S3 state *before* the following chain of
action happened:
- PCI enumeration completes
- ACPI tables are installed by OvmfPkg/AcpiPlatformDxe
- the FACS table becomes available
Since OvmfPkg/AcpiS3SaveDxe can only save S3 state once the FACS table
is available, we must delay the End-of-Dxe signal until after PCI
enumeration completes (ie. root bridges are connected).
(2) Pre-patch, S3Ready() in OvmfPkg/AcpiS3SaveDxe is entered from
BdsLibBootViaBootOption()
[IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c].
After the patch, we enter S3Ready() earlier than that, by signaling
End-of-Dxe in PlatformBdsPolicyBehavior(). The timing / location of
this new call is correct as well, and the original call (that now
becomes the chronologically second call) becomes a no-op: S3Ready() is
protected against 2nd and later entries.
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>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18035 6f19259b-4bc3-4df7-8a09-765794883524
The OFW device path that QEMU exports in the "bootorder" fw_cfg file, for
a device that is plugged into the main PCI root bus, is:
/pci@i0cf8/...
Whereas the same device plugged into the N'th extra root bus results in:
/pci@i0cf8,N/pci-bridge@0/...
(N is in hex.)
Extend TranslatePciOfwNodes() so that it not assume a single PCI root;
instead it parse the extra root bus serial number if present, and resolve
it in the translation to the UEFI devpath fragment.
Note that the "pci-bridge@0" node is a characteristic of QEMU's PXB
device. It reflects the actual emulated PCI hierarchy. We don't parse it
specifically in this patch, because it is automatically handled by the
bridge sequence translator added recently in SVN rev 17385 (git commit
feca17fa4b) -- "OvmfPkg: QemuBootOrderLib: parse OFW device path nodes of
PCI bridges".
The macro EXAMINED_OFW_NODES need not be raised from 6. The longest OFW
device paths that we wish to recognize under this new scheme comprise 5
nodes. The initial "extra root bus" OFW fragment, visible at the top,
takes up 2 nodes, after which the longest device-specific patterns (IDE
disk, IDE CD-ROM, ISA floppy, virtio-scsi disk) take 3 more nodes each.
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>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17965 6f19259b-4bc3-4df7-8a09-765794883524
SeaBIOS requires the OpenFirmware device paths exported in the "bootorder"
fw-cfg file to refer to extra (PXB) root buses by their relative positions
(in increasing bus number order) rather than by actual bus numbers.
However, OVMF's PCI host bridge / root bridge driver creates PciRoot(UID)
device path nodes for extra PCI root buses with UID=bus_nr, not position.
(These ACPI devpath UID values must, and do, match the UID values exposed
in QEMU's ACPI payload, generated for PXB root buses.)
Therefore the boot order matching logic will have to map extra root bus
positions to bus numbers. Add a small group of utility functions to help
with that.
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>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17964 6f19259b-4bc3-4df7-8a09-765794883524
Currently we only connect the root bus with bus number 0, by device path.
Soon we will possibly have several extra root buses, so connect all root
buses up-front (bus number zero and otherwise), by protocol GUID.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Regression-tested-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17954 6f19259b-4bc3-4df7-8a09-765794883524
The ASSERT() in SetPciIntLine() assumes that Device 0 on "the" root bus
corresponds to the PCI host bridge (00:00). This used to be true, but
because we're going to have extra root buses (with nonzero bus numbers),
soon this assumption may no longer hold. Check for the zero root bus
number explicitly.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Gabriel Somlo <somlo@cmu.edu>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Gabriel Somlo <somlo@cmu.edu>
Regression-tested-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17953 6f19259b-4bc3-4df7-8a09-765794883524
These messages are helpful for comparing the assignments made by OVMF
against those made by SeaBIOS. To SeaBIOS a small debug patch like the
following can be applied:
> diff --git a/src/fw/pciinit.c b/src/fw/pciinit.c
> index ac39d23..9e61c22 100644
> --- a/src/fw/pciinit.c
> +++ b/src/fw/pciinit.c
> @@ -308,8 +308,12 @@ static void pci_bios_init_device(struct pci_device *pci)
>
> /* map the interrupt */
> int pin = pci_config_readb(bdf, PCI_INTERRUPT_PIN);
> - if (pin != 0)
> - pci_config_writeb(bdf, PCI_INTERRUPT_LINE, pci_slot_get_irq(pci, pin));
> + if (pin != 0) {
> + int irqline = pci_slot_get_irq(pci, pin);
> +
> + pci_config_writeb(bdf, PCI_INTERRUPT_LINE, irqline);
> + dprintf(1, "assigned irq line %d\n", irqline);
> + }
>
> pci_init_device(pci_device_tbl, pci, NULL);
>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Gabriel Somlo <somlo@cmu.edu>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17952 6f19259b-4bc3-4df7-8a09-765794883524
The FileReserved variable in QemuFwCfgFindFile() is only used to skip
over the reserved field in file headers, which causes newer versions of
GCC to flag it with a "variable set but not used" warning (which is normally
not visible since as of right now these warnings are supressed). It's true
that the value read into FileReserved is never used, but this is
intentional. This patch adds a do-nothing reference to silence the
warning.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Bill Paul <wpaul@windriver.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17920 6f19259b-4bc3-4df7-8a09-765794883524
The PMBA_RTE and ACPI_TIMER_OFFSET macros apply equally to both boards,
plus they are triplicated between the various AcpiTimerLib instances.
Define them centrally in "OvmfPlatforms.h".
Cc: Gabriel Somlo <somlo@cmu.edu>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Gabriel Somlo <somlo@cmu.edu>
Tested-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17436 6f19259b-4bc3-4df7-8a09-765794883524
All POWER_MGMT_REGISTER_PIIX4() macro invocations in OvmfPkg should use
the macros in "I440FxPiix4.h" as arguments.
Cc: Gabriel Somlo <somlo@cmu.edu>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Gabriel Somlo <somlo@cmu.edu>
Tested-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17435 6f19259b-4bc3-4df7-8a09-765794883524
All POWER_MGMT_REGISTER_Q35() macro invocations in OvmfPkg should use the
macros in "Q35MchIch9.h" as arguments.
Cc: Gabriel Somlo <somlo@cmu.edu>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Gabriel Somlo <somlo@cmu.edu>
Tested-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17434 6f19259b-4bc3-4df7-8a09-765794883524
When the Q35 machine type(s) of QEMU are used with libvirt, libvirt tends
to place some devices behind PCI bridges. This is then reflected in the
"bootorder" fw_cfg file. For example:
/pci@i0cf8/pci-bridge@1e/pci-bridge@1/scsi@5/disk@0,0
/pci@i0cf8/pci-bridge@1e/pci-bridge@1/scsi@3/channel@0/disk@0,0
As yet QemuBootOrderLib doesn't support such OFW device paths.
Add code that translates a sequence of pci-bridge nodes.
In practice libvirt seems to insert two such nodes (*), hence increment
EXAMINED_OFW_NODES with the same number.
(* Background, paraphrasing Laine Stump's words:
When the machine type is Q35, we create a dmi-to-pci bridge coming off of
the pcie root controller, and a pci-to-pci bridge coming off of that, then
attach most devices to the pci-to-pci bridge. This is done because you
can't hotplug into pcie-root, can't (or at least shouldn't) plug a
pci-to-pci bridge into pcie-root (so the next one has to be
dmi-to-pci-bridge), and can't hotplug into dmi-to-pci-bridge (so you need
to have a pci-to-pci bridge).)
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@17385 6f19259b-4bc3-4df7-8a09-765794883524
It is the responsibility of the SerialPortLib implementation
to deal with flow control if the underlying medium cannot keep
up with the inflow of data.
So in our SerialPortWrite () function, we should spin as long
as we need to in order to deliver all the data instead of giving
up and returning a smaller value than the number of bytes we were
given. Also, remove the 'if (Sent > 0)' condition on the signalling
of the event channel: if the buffer is full and we haven't been able
to add any more data, it makes perfect sense to signal the event
channel again, even if we have done so before when we did write
the data.
Also, this patch brings the implementation of XenSerialPortLib
in sync with the library class documentation.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
[lersek@redhat.com: replace DebugLib dependency with open-coded ASSERT()]
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17079 6f19259b-4bc3-4df7-8a09-765794883524
On PIIX4, function 3, the PMREGMISC register at offset 0x80, with
default value 0x00 has its bit 0 (PMIOSE) indicate whether the PM
IO space given in the PMBA register (offset 0x40) is enabled.
PMBA must be configured *before* setting this bit.
On Q35/ICH9+, function 0x1f, the equivalent role is fulfilled by
bit 7 (ACPI_EN) in the ACPI Control Register (ACPI_CNTL) at offset
0x44, also with a default value of 0x00.
Currently, OVMF hangs when Q35 reboots, because while PMBA is reset
by QEMU, the register at offset 0x80 (matching PMREGMISC on PIIX4)
is not reset, since it has a completely different meaning on LPC.
As such, the power management initialization logic in OVMF finds
the "PMIOSE" bit enabled after a reboot and decides to skip setting
PMBA. This causes the ACPI timer tick routine to read a constant
value from the wrong register, which in turn causes the ACPI delay
loop to hang indefinitely.
This patch modifies the Base[Rom]AcpiTimerLib constructors and the
PlatformPei ACPI PM init routines to use ACPI_CNTL:ACPI_EN instead
of PMREGMISC:PMIOSE when running on Q35.
Reported-by: Reza Jelveh <reza.jelveh@tuhh.de>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17076 6f19259b-4bc3-4df7-8a09-765794883524
XenHypercallLib has two clients at the moment: XenBusDxe and
XenConsoleSerialPortLib. Currently, when XenBusDxe starts on a non-Xen X86
platform (ie. as part of OVMF not running on Xen), the X86XenHypercallLib
instance built into it fails to initialize, which triggers an ASSERT() in
auto-generated code.
Instead, let's call XenHypercallIsAvailable() in the driver's entry point,
and exit cleanly when the driver is started on a non-Xen platform.
Modify the constructor of XenConsoleSerialPortLib similarly; we shouldn't
proceed if Xen is not available. In practice this check should never fail,
because XenConsoleSerialPortLib is only used on ARM, and
ArmXenHypercallLib is always available; but nonetheless we should be
pedantic.
Reported-by: Gabriel L. Somlo <gsomlo@gmail.com>
Suggested-by: 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>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17001 6f19259b-4bc3-4df7-8a09-765794883524
Similarly to QemuFwCfgLib, we prefer mellow library construction code and
an explicit "are you available" query function in the XenHypercallLib
class. In this step we introduce that query function, but move no client
code to it yet.
Suggested-by: 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>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17000 6f19259b-4bc3-4df7-8a09-765794883524
In the next patch we'll add a simple query function to the XenHypercallLib
library class that is supposed to be called by initialization code in
modules. Among those, in constructors of dependent libraries too.
Library construction ordering is ensured only between libraries with
constructors, plus we shouldn't allow a dependent library with a
constructor to call into any XenHypercallLib instances (the simple query
function) before XenHypercallLib is constructed itself. For this reason,
introduce an (empty) constructor for ARM & AARCH64 too.
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: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16999 6f19259b-4bc3-4df7-8a09-765794883524
Perform the following renames in order to stick with edk2 tradition more
closely:
XenHypercallLibArm, XenHypercallLibIntel -> XenHypercallLib
XenHypercallIntel -> X86XenHypercall
In addition, we unify the INF files.
This patch modifies ArmVirtualizationPkg and OvmfPkg at once, in order to
keep both bisectable (client code shouldn't break).
Suggested-by: 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>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16998 6f19259b-4bc3-4df7-8a09-765794883524
This adds a XenIoMmioLib declaration and implementation that can
be invoked to install the XENIO_PROTOCOL and a corresponding
grant table address on a EFI handle.
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16979 6f19259b-4bc3-4df7-8a09-765794883524
This implements a SerialPortLib instance that wires up to the
PV console ring used by domU guests. Also imports the required
upstream Xen io/console.h header.
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16976 6f19259b-4bc3-4df7-8a09-765794883524
This patch adds an implementation of XenHypercallLib for both
AArch64 and AArch32 execution modes on ARM systems.
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16974 6f19259b-4bc3-4df7-8a09-765794883524
This moves all of the Xen hypercall code that was private to XenBusDxe
to a new library class XenHypercallLib. This will allow us to reimplement
it for ARM, and to export the Xen hypercall functionality to other parts
of the code, such as a Xen console SerialPortLib driver.
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16970 6f19259b-4bc3-4df7-8a09-765794883524
Before we launch the QEMU kernel, we should signal the ReadyToBoot
event.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16878 6f19259b-4bc3-4df7-8a09-765794883524
Implement new API DebugPrintLevelEnabled() to base on PCD PcdFixedDebugPrintErrorLevel.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16797 6f19259b-4bc3-4df7-8a09-765794883524
The QEMU command line option
-boot menu=on
is meant to have the guest firmware wait for a firmware-specific interval
for the user to enter the boot menu. During the wait, the user can opt to
enter the boot menu, or interrupt the wait and proceed to booting at once.
If the wait interval elapses, the firmware should boot as it normally
would.
The QEMU command line option
-boot menu=on,splash-time=N
means the same, except the firmware should wait for cca. N milliseconds
instead of a firmware-specific interval.
We can approximate this behavior quite well for edk2's virtual platforms
because the Intel BDS front page already supports a progress bar, with
semantics similar to the above. Let's distill the fw_cfg bits underlying
"-boot menu=on,splash-time=N" for the BDS policies, in the form of a
timeout value they can pass to Intel's PlatformBdsEnterFrontPage().
If the boot menu is not requested, we return
"gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdPlatformBootTimeOut", which
is what the virtual platforms use right now.
If the boot menu is requested without specifying the timeout, we return
the same PCD, unless it would cause us to skip the boot menu at once. In
the latter case, we return 3 seconds (as an approximation of the 2500 ms
SeaBIOS default.)
RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1170507
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: Olivier Martin <Olivier.martin@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16610 6f19259b-4bc3-4df7-8a09-765794883524
The TranslateMmioOfwNodes() function recognizes the following OpenFirmware
device paths:
virtio-blk: /virtio-mmio@000000000a003c00/disk@0,0
virtio-scsi disk: /virtio-mmio@000000000a003a00/channel@0/disk@2,3
virtio-net NIC: /virtio-mmio@000000000a003e00/ethernet-phy@0
The new translation can be enabled with the
"PcdQemuBootOrderMmioTranslation" Feature PCD. This PCD also controls if
the "survival policy" covers unselected boot options that start with the
virtio-mmio VenHw() node.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16575 6f19259b-4bc3-4df7-8a09-765794883524
The OpenFirmware device path nodes that QEMU generates for virtio-mmio
transports contain 64-bit hexadecimal values (16 nibbles) -- the base
addresses of the register blocks. In order to parse them soon,
ParseUnitAddressHexList() must parse UINT64 values.
Call sites need to be adapted, as expected.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16574 6f19259b-4bc3-4df7-8a09-765794883524
In preparation for adding OpenFirmware-to-UEFI translation for "MMIO-like"
OFW device path fragments, let's turn the currently exclusive "PCI-like"
translation into "just one" of the possible translations.
- Rename TranslateOfwNodes() to TranslatePciOfwNodes(), because it is
tightly coupled to "PCI-like" translations.
- Rename REQUIRED_OFW_NODES to REQUIRED_PCI_OFW_NODES, because this macro
is specific to TranslatePciOfwNodes().
- Introduce a new wrapper function under the original TranslateOfwNodes()
name. This function is supposed to try translations in some order until
a specific translation returns a status different from
RETURN_UNSUPPORTED.
- Introduce a new Feature PCD that controls whether PCI translation is
attempted at all.
- The boot option "survival policy" in BootOrderComplete() must take into
account if the user was able to select PCI-like boot options. If the
user had no such possibility (because the Feature PCD was off for
PCI-like translation), then we ought to keep any such unselected boot
options.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16571 6f19259b-4bc3-4df7-8a09-765794883524
and rebase OvmfPkg's PlatformBdsLib on the standalone library.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16570 6f19259b-4bc3-4df7-8a09-765794883524
Remove hard-coded list of PCI devices for which the Interrupt Line
register is initialized. Instead, provide a "visitor" function to
initialize the register only for present and applicable PCI devices.
At this time, we match the behavior of SeaBIOS (file src/fw/pciinit.c,
functions *_pci_slot_get_irq() and "map the interrupt" block from
pci_bios_init_device()).
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16398 6f19259b-4bc3-4df7-8a09-765794883524
Merge PciInitialization() and AcpiInitialization() into a single
function, PciAcpiInitialization(), and use a PCD set during PEI to
detect the underlying platform type (PIIX4 or Q35/MCH) and therefore
the addresses of the registers to be initialized.
Add LNK[A-H] routing target initialization for the Q35 platform.
Additionally, initialize PCI_INTERRUPT_LINE registers for the typical
set of PCI devices included by QEMU with the Q35 machine type. The
corresponding PIIX4 initialization of PCI_INTERRUPT_LINE registers is
cleaned up and the list of PIIX4 PCI devices updated to the list
typically included with QEMU.
NOTE: The list of PCI devices for which we initialize PCI_INTERRUPT_LINE
is hard-coded, and, depending on how QEMU devices are configured on
the command line, may miss some devices, or (harmlessly) attempt to
initialize devices which are not present in the system. A subsequent
patch will replace this hard-coded list with a mechanism to correctly
initialize PCI_INTERRUPT_LINE for applicable present PCI devices only.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16379 6f19259b-4bc3-4df7-8a09-765794883524
Link DXE_SMM_DRIVER, UEFI_DRIVER, UEFI_APPLICATION, and SMM_CORE against
a valid, non-asserting version of PcdLib, then switch them over to using
the "Dxe" instance of AcpiTimerLib (instead of the "Base" version).
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16378 6f19259b-4bc3-4df7-8a09-765794883524
Since in OVMF both PEI_CORE and PEIM run from RAM, and thus may
utilize global variables, use the "Base" AcpiTimerLib instance
(instead of BaseRom) to take advantage of the improved efficiency
of storing the timer register IO address in a global variable.
This leaves only SEC using the BaseRomAcpiTimerLib instance.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16377 6f19259b-4bc3-4df7-8a09-765794883524
Remove local power management register access macros in favor of
factored-out ones in OvmfPkg/Include/OvmfPlatforms.h
Next, AcpiTimerLib is split out into three instances, for use during
various stages:
- BaseRom: used during SEC, PEI_CORE, and PEIM;
- Dxe: used during DXE_DRIVER and DXE_RUNTIME_DRIVER;
- Base: used by default during all other stages.
Most of the code remains in AcpiTimerLib.c, to be shared by all
instances. The two platform-dependent methods (constructor and
InternalAcpiGetTimerTick) are provided separately by source files
specific to each instance, namely [BaseRom|Base|Dxe]AcpiTimerLib.c.
Since pre-DXE stages can't rely on storing data in global variables,
methods specific to the "BaseRom" instance will call platform
detection macros each time they're invoked.
The "Base" instance calls platform detection macros only from its
constructor, and caches the address required by InternalAcpiTimerTick
in a global variable.
The "Dxe" instance is very similar to "Base", except no platform
detection macros are called at all; instead, the platform type is
read via a dynamic PCD set from PlatformPei.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16376 6f19259b-4bc3-4df7-8a09-765794883524
PlatformBdsEnterFrontPage() already implements a keypress wait (for
entering the setup utility at boot) with a nice progress bar, only OVMF
has not been using it.
Removing our custom code and utilizing PlatformBdsEnterFrontPage()'s
builtin wait has the following benefits:
- It simplifies OVMF's BDS code.
- Because now we call PlatformBdsEnterFrontPage() unconditionally, it
actually has a chance to look at the EFI_OS_INDICATIONS_BOOT_TO_FW_UI
bit of the "OsIndications" variable, improving compliance with the UEFI
specification. References:
- https://bugzilla.redhat.com/show_bug.cgi?id=1153927
- http://thread.gmane.org/gmane.comp.bios.tianocore.devel/10487
- The progress bar looks nice. (And it keeps the earlier behavior intact,
when the user presses a key on the TianoCore splash screen.)
In any case, we set the timeout to 0 (which doesn't show the progress
bar and proceeds to the boot options immediately) in order to keep the
boot time down.
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@16310 6f19259b-4bc3-4df7-8a09-765794883524
This is again obviated by our earlier BdsLibConnectAll() call.
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@16309 6f19259b-4bc3-4df7-8a09-765794883524
The second parameter of said function is "ConnectAllHappened", and if set
to TRUE, the function sets "gConnectAllHappened" to TRUE.
This global variable in turn controls whether Intel BDS code *itself*
calls BdsLibConnectAllDriversToAllControllers() in various places -- if
the indicator is TRUE, then the "connect all" is assumed to have been
performed, and Intel BDS doesn't do it itself.
OVMF should pass TRUE as "ConnectAllHappened", because a few lines before
our call to PlatformBdsEnterFrontPage(), we already connect everything
with BdsLibConnectAll(), which includes the effects of
BdsLibConnectAllDriversToAllControllers():
PlatformBdsPolicyBehavior() [OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c]
BdsLibConnectAll() [IntelFrameworkModulePkg/Library/GenericBdsLib/BdsConnect.c]
BdsLibConnectAllDriversToAllControllers()
PlatformBdsEnterFrontPage() [IntelFrameworkModulePkg/Universal/BdsDxe/FrontPage.c]
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@16308 6f19259b-4bc3-4df7-8a09-765794883524
The PlatformBdsEnterFrontPage() function's first parameter,
"TimeoutDefault", determines the behavior of the setup utility:
- If (TimeoutDefault == 0), then the usual boot order is to be acted upon
immediately.
- If (TimeoutDefault == 0xFFFF), then the setup utility is entered
unconditionally.
- If (0 < TimeoutDefault && TimeoutDefault < 0xFFFF), then the
PlatformBdsEnterFrontPage() function displays a progress bar, waiting
for TimeoutDefault seconds. If the user presses a key, then the setup
utility is entered, otherwise the normal boot option processing takes
place.
The TimeoutDefault parameter is supposed to be set from
gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdPlatformBootTimeOut
which has the following (matching) documentation in
"IntelFrameworkModulePkg/IntelFrameworkModulePkg.dec":
The number of seconds that the firmware will wait before initiating the
original default boot selection.
A value of 0 indicates that the default boot selection is to be
initiated immediately on boot.
The value of 0xFFFF then firmware will wait for user input before
booting.
OVMF does this actually -- see the Timeout variable in
PlatformBdsPolicyBehavior() -- but right before calling
PlatformBdsEnterFrontPage(), OVMF hardwires TimeoutDefault to 0xFFFF.
This has been acceptable until now, because OVMF implements its own "wait
for keypress at the splash screen" logic in PlatformBdsPolicyBehavior(),
completely avoiding the progress bar mentioned above. OVMF only calls
PlatformBdsEnterFrontPage() when the user presses a key during its own
"splash screen wait", and *then* it indeed makes sense to enter the setup
utility unconditionally.
However, even that way, the
Timeout = 0xffff;
assignment is superfluous, because 0xFFFF is already the default value of
PcdPlatformBootTimeOut in "IntelFrameworkModulePkg.dec", and OvmfPkg
doesn't override it in its DSC files.
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@16307 6f19259b-4bc3-4df7-8a09-765794883524
This call has been dead since the conception of OvmfPkg (git commit
49ba9447 / SVN r8398), and only confuses readers -- let's remove it.
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@16305 6f19259b-4bc3-4df7-8a09-765794883524
The BaseTools/Scripts/ConvertMasmToNasm.py script was used to convert
X64/IoLibExAsm.asm to X64/IoLibExAsm.nasm
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16290 6f19259b-4bc3-4df7-8a09-765794883524
The BaseTools/Scripts/ConvertMasmToNasm.py script was used to convert
Ia32/IoLibExAsm.asm to Ia32/IoLibExAsm.nasm
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16289 6f19259b-4bc3-4df7-8a09-765794883524
The BaseTools/Scripts/ConvertMasmToNasm.py script was used to convert
X64/JumpToKernel.asm to X64/JumpToKernel.nasm
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16288 6f19259b-4bc3-4df7-8a09-765794883524
The BaseTools/Scripts/ConvertMasmToNasm.py script was used to convert
Ia32/JumpToKernel.asm to Ia32/JumpToKernel.nasm
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16287 6f19259b-4bc3-4df7-8a09-765794883524
Pick the appropriate bus:dev.fn for accessing ACPI power management
registers (00:01.3 on PIIX4 vs. 00:1f.0 on Q35) based on the device
ID of the host bridge (assumed always present at 00:00.0).
With this patch, OVMF can boot QEMU's "-machine q35" x86 machine type.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-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@16066 6f19259b-4bc3-4df7-8a09-765794883524
Names of firmware configuration files always take 56 bytes (including at
least one terminating NUL byte). Expose this constant to all consumers of
QemuFwCfgLib because further interfaces may depend on it.
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@15571 6f19259b-4bc3-4df7-8a09-765794883524
In many cases, the second node in /pci@i0cf8/XYZ@DD,FF node is enough
to match a UEFI device path; a typical cases is a NIC that is assigned
from the host to the guest. Add a catch-all case for PCI devices, and
reuse it for NICs since it works well for those too.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15422 6f19259b-4bc3-4df7-8a09-765794883524
The Boot#### variables that have become unreferenced in the new BootOrder
variable won't ever be automatically reused for booting. They are
"unreachable" resources that take up room in the variable store. Make an
effort to remove them.
This should plug the leak which, given sufficient reboots, exhausts the
variable store with stale Boot#### variables and renders the VM
unbootable.
Reported-by: Michael Chang <mchang@suse.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@15327 6f19259b-4bc3-4df7-8a09-765794883524
When PI can distinguish the "full config" boot mode from "assume no
changes", then the following BDS logic is correct:
if BootMode == BOOT_WITH_FULL_CONFIGURATION:
//
// connect all devices
// create & append each default boot option that's missing
//
BdsLibConnectAll
BdsLibEnumerateAllBootOption
else if BootMode == BOOT_ASSUMING_NO_CONFIGURATION_CHANGES:
//
// just stick with current BootOrder and the Boot#### variables
// referenced by it
//
In theory, the first branch is intended to run infrequently, and the
"assume no changes" branch should run most of the time.
However, some platforms can't tell these two boot modes apart. The
following substitute had been introduced:
//
// Technically, always assume "full config", but the BootMode HOB is
// actually meaningless wrt. to "full config" or "assume no changes".
//
ASSERT (BootMode == BOOT_WITH_FULL_CONFIGURATION);
//
// Key off the existence of BootOrder. Try to prepare an in-memory list
// of boot options, based on BootOrder and the referenced Boot####
// variables.
//
Status = BdsLibBuildOptionFromVar()
//
// If that succeeded, we'll treat it as "assume no changes". If it
// failed (*only* if it failed), we'll build default boot options,
// calling it "full config":
//
if EFI_ERROR(Status):
BdsLibConnectAll()
BdsLibEnumerateAllBootOption(BootOptionList)
What we have now in OVMF is a mixture of the hack, and the behavior that's
theoretically correct for "full config":
- We assert "full config" -- this is OK.
- We call "connect all" and "enumerate all" deliberately -- this is OK
too. It matches "full config" which we assert.
- However, we also have the hack in place, which had been meant as an
alternative.
In order to clean this up, we either need to restore the hack to its
original form (ie. comment out the unconditional calls again), or we ought
to remove the hack altogether.
The unconditional "connect all" + "enumerate all" calls are the correct
approach for OVMF, because we want, in fact, to start with "full config".
The QEMU boot order specification and the set of emulated devices might
change "out of band", which excludes "assume no changes".
In other words, removing the hack corresponds to the "real production"
case that the comment hints at.
Because SetBootOrderFromQemu() may change the BootOrder NvVar, we must
preserve the BdsLibBuildOptionFromVar() function call, in order to
refresh the in-memory list with the new boot priorities.
(The last step of BdsLibEnumerateAllBootOption() is such a call too.)
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@15326 6f19259b-4bc3-4df7-8a09-765794883524
The S3 suspend/resume infrastructure depends on the LockBox library class.
The edk2 tree currently contains Null and SMM instances. The Null instance
is useless, and the SMM instance would require SMM emulation by including
the SMM core and adding several new drivers, which is deemed too complex.
Hence add a simple LockBoxLib instance for OVMF.
jordan.l.justen@intel.com:
* use PCDs instead of EmuNvramLib
- clear memory in PlatformPei on non S3 boots
* allocate NVS memory and store a pointer to that memory
- reduces memory use at fixed locations
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15301 6f19259b-4bc3-4df7-8a09-765794883524
Such a packaged query function will come in handy in the following
patches.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
[jordan.l.justen@intel.com: check for enabled rather than disabled]
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15292 6f19259b-4bc3-4df7-8a09-765794883524
The BOOLEAN IsFinal variable initialization isn't properly seen by
MSVC. To make it compile OVMF the variable needs to be initialized.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Mauro Faccenda <faccenda@gmail.com>
Reviewed-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@15214 6f19259b-4bc3-4df7-8a09-765794883524
When this option is passed to qemu, it appends the word HALT to the
"bootorder" fw_cfg file, as last entry. For example,
/pci@i0cf8/ethernet@3/ethernet-phy@0
/pci@i0cf8/scsi@4/disk@0,0
HALT
The option's purpose is to prevent SeaBIOS from booting from devices that
have not been specified explicitly (with bootindex=N device properties nor
-boot options). When SeaBIOS sees HALT, it doesn't proceed to boot from
default locations (after boot fails from all of the listed locations).
The HALT string currently causes OVMF to reject the entire "bootorder"
fw_cfg contents, with "parse error". This is not good, because since a
recent libvirt commit, libvirt unconditionally passes "-boot strict=on" to
qemu. Consequently, the boot order logic in QemuBootOrder.c has stopped
working for libvirt users.
OVMF's SetBootOrderFromQemu() function actually implements the idea behind
"-boot strict=on": it drops all boot options not in the fw_cfg list. (*)
Therefore, let's recognize HALT, and just do what we've been doing all
along.
(*) Except the UEFI shell, according to the survival policy in
BootOrderComplete(), but the memory mapped UEFI shell is not expressible
via fw_cfg anyway, and its preservation has been requested on edk2-devel.
Hence it's a good boot option to keep in any case.
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@15197 6f19259b-4bc3-4df7-8a09-765794883524
The QemuFwCfgSecLib library instance
- is stateless,
- has no library constructor,
- is available to SEC client code,
- must be queried with QemuFwCfgIsAvailable() before use,
- is restricted to SEC in order to limit the explicit querying
requirement. (There is no current user.)
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@15046 6f19259b-4bc3-4df7-8a09-765794883524
The current implementation of QemuFwCfgLib is:
- stateful
- implicitly initialized in the library constructor.
OVMF's SEC runs from read-only memory/flash. When the library is linked
into a SEC binary (which currently never happens), the
"mQemuFwCfgSupported" global variable becomes read-only, making the
library non-functional.
Extract the stateful, implicitly initialized library implementation into a
separate file, making room for a stateless, explicitly queried
implementation that's usable in SEC. Restrict the stateful implementation
to the current, non-SEC clients.
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@15045 6f19259b-4bc3-4df7-8a09-765794883524
This internal function allows separation of library-internal and
for-clients external availability of fw_cfg.
The interface contract of QemuFwCfgIsAvailable() is changed so that now it
may modify fw_cfg state. All current users are compliant with the new
contract.
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@15044 6f19259b-4bc3-4df7-8a09-765794883524
These functions did not provide much more than the new protocol functions
VIRTIO_DEVICE_PROTOCOL.ReadDevice() / VIRTIO_DEVICE_PROTOCOL.WriteDevice().
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Olivier Martin <olivier.martin@arm.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14968 6f19259b-4bc3-4df7-8a09-765794883524
This change replaces the accesses to the PCI bus from the Block, Scsi and Net drivers by
the use of the new VIRTIO_DEVICE_PROTOCOL protocol that abstracts the transport layer.
It means these drivers can be used on PCI and MMIO transport layer.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Olivier Martin <olivier.martin@arm.com>
v5:
- VirtioFlush(): update comment block in VirtioLib.[hc]; error code is
propagated from VirtIo->SetQueueNotify().
- VirtioBlkInit(): jump to Failed label if SetPageSize() fails
- VirtioBlkInit(): fixup comment, and add error handling, near
SetQueueNum() call
- VirtioBlkDriverBindingStart(): remove redundant (always false) check for
a subsystem device ID different from VIRTIO_SUBSYSTEM_BLOCK_DEVICE;
VirtioBlkDriverBindingSupported() handles it already
- VirtioNetGetFeatures(): update stale comment block
- VirtioNetGetFeatures(): retrieve MAC address byte for byte (open-coded
loop)
- VirtioNetDriverBindingStart(): remove redundant (always false) check for
a subsystem device ID different from VIRTIO_SUBSYSTEM_NETWORK_CARD;
VirtioNetDriverBindingSupported() handles it already
- VirtioNetInitRing(): call SetQueueNum() and SetQueueAlign() for proper
MMIO operation
- VirtioNetInitialize(): fix destination error label for when
SetPageSize() fails
- VirtioScsi.c: fix comment block of VIRTIO_CFG_WRITE()/VIRTIO_CFG_READ()
- VirtioScsiInit(): fix destination error label for when SetPageSize()
fails
- VirtioScsiInit(): call SetQueueNum() and SetQueueAlign() for proper MMIO
operation
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@14966 6f19259b-4bc3-4df7-8a09-765794883524
Why is the virtio-mmio implementation of the protocol a library,
instead of a driver binary?
The UEFI driver model would encourage to create a virtio-mmio driver
instead of a library. But the reasons why I created a library are:
- A virtio-mmio driver would imply an additional protocol that would
probably have a single attribute field:
typedef struct {
PHYSICAL_ADDRESS BaseAddress;
} VIRTIO_MMIO_DEVICE_PROTOCOL;
- There is no (easy) way to scan the available VirtIo devices on a
platform. So, the UEFI firmware for this platform would need a driver
to produce instances for every virtio devices it wants to expose in
UEFI. A single call to a helper library (ie: VirtioMmioDeviceLib)
make the porting easier.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Olivier Martin <olivier.martin@arm.com>
v5:
- typo fix in VirtioMmioInstallDevice() comment block
- plug MmioDevice leak in VirtioMmioUninstallDevice()
- return EFI_INVALID_PARAMETER in VirtioMmioGetQueueAddress() if
QueueAddress is NULL
- VirtioMmioSetQueueSize(): fix return value (it's a status code)
- VirtioMmioSetPageSize(): check against EFI_PAGE_SIZE with "if" plus
EFI_UNSUPPORTED, rather than ASSERT()
- VirtioMmioDeviceWrite(), VirtioMmioDeviceRead(): remove redundant
(FieldSize > 8) checks
- VirtioMmioDeviceLib.inf: drop UefiDriverEntryPoint library dependency
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@14965 6f19259b-4bc3-4df7-8a09-765794883524
QemuFlashFvbServicesRuntimeDxe provides actual persistent storage for
non-volatile variables. When it is active, any on-disk NvVars file counts
as a stale source of variables -- hence don't load these files in BDS.
This also allows Secure Boot settings (eg. enrolled keys) to survive cold
VM reboots.
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@14844 6f19259b-4bc3-4df7-8a09-765794883524
LoadLinux() is looking at the wrong field for the kernel's EFI handover
protocol flags. It's not currently possible for JumpToUefiKernel() to
ever be called (even accidentally) because BIT2 and BIT3 of
Bp->hdr.load_flags are never set in modern kernels, which means that
control is always transferred to the kernel via the legacy entry point.
Look at the correct field so that the EFI handover protocol is used
whenever it's available.
Contributed-under: TianoCore Contribution Agreement 1.0
Cc: David Woodhouse <David.Woodhouse@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Borislav Petkov <bp@suse.de>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14721 6f19259b-4bc3-4df7-8a09-765794883524
Some of the active boot options that have not been selected over fw_cfg
should be preserved at the end of the boot order. For now we're adding
back everything that starts with neither PciRoot() nor HD(). This includes
the UEFI shell, memory-mapped from the firmware image.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Michael Chang <mchang@suse.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14668 6f19259b-4bc3-4df7-8a09-765794883524
This will allow us to identify those UEFI boot options (while keeping
their relative order) that have *not* been selected by fw_cfg.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Michael Chang <mchang@suse.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14667 6f19259b-4bc3-4df7-8a09-765794883524
In preparation for the next patch, collect active UEFI boot options in
advance into a new array. Rebase the current inner loop (the matching
loop) to this array.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Michael Chang <mchang@suse.com>
[jordan.l.justen@intel.com: initialize *ActiveOption for GCC IA32 warning]
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14666 6f19259b-4bc3-4df7-8a09-765794883524
The prefix matching logic in Match()
[OvmfPkg/Library/PlatformBdsLib/QemuBootOrder.c] expects UEFI boot options
to specify full (absolute) device paths. However, partial (relative)
device paths starting with a HD() node are valid for booting. By not
recognizing them, QemuBootOrder.c misses (and deletes) valid boot options
that would otherwise match the user's preference.
Just like BdsLibBootViaBootOption() expands such paths with the
BdsExpandPartitionPartialDevicePathToFull() function for booting, do the
same in QemuBootOrder.c for prefix matching.
This moves the very first call to
BdsExpandPartitionPartialDevicePathToFull() to an earlier point. The
following call tree explains it:
BdsEntry() [IntelFrameworkModulePkg/Universal/BdsDxe/BdsEntry.c]
PlatformBdsPolicyBehavior() [OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c]
SetBootOrderFromQemu() [OvmfPkg/Library/PlatformBdsLib/QemuBootOrder.c]
Match() [OvmfPkg/Library/PlatformBdsLib/QemuBootOrder.c]
BdsExpandPartitionPartialDevicePathToFull() [IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c]
BdsBootDeviceSelect() [IntelFrameworkModulePkg/Universal/BdsDxe/BdsEntry.c]
BdsLibBootViaBootOption() [IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c]
BdsExpandPartitionPartialDevicePathToFull() [IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c]
This should be fine, for two reasons:
- the new, earlier call is still under BdsEntry(),
- BdsExpandPartitionPartialDevicePathToFull() expects to be called
repeatedly, even with the same set of HD() device paths. This function
implements its own caching for device paths, likely for performance
reasons.
That fits this patch well because whatever device paths we expand under
PlatformBdsPolicyBehavior() can be quickly looked up in
BdsBootDeviceSelect(), so no work (ie.
BdsLibConnectAllDriversToAllControllers()) should be wasted.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Michael Chang <mchang@suse.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14665 6f19259b-4bc3-4df7-8a09-765794883524
The volatile 'NvVars' variable indicates that the variables do
not need to be loaded from the file again. After we write the
variables out to the file, there is clearly no need to load
them back from the file.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Michael Chang <mchang@suse.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14613 6f19259b-4bc3-4df7-8a09-765794883524
Enforce in-order execution of these steps even on not sequentially
consistent architectures, as discussed in [1]. These changes should be
unnecessary on x86 (the only architecture OVMF currently supports), but
they align the OVMF virtio code with the virtio specification and could be
necessary for future OVMF ports.
[1] http://lists.linuxfoundation.org/pipermail/virtualization/2013-June/024547.html
Suggested-by: Stefan Hajnoczi <stefanha@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14601 6f19259b-4bc3-4df7-8a09-765794883524
In Linux, efi_memblock_x86_reserve_range() and efi_reserve_boot_services()
expect that whoever allocates the EFI memmap allocates it in Loader Data
type memory. Linux's own exit_boot()-->low_alloc() complies, but
SetupLinuxMemmap() in LoadLinuxLib doesn't.
The memory type discrepancy leads to efi_memblock_x86_reserve_range() and
efi_reserve_boot_services() both trying to reserve the range backing the
memmap, resulting in memmap entry truncation in
efi_reserve_boot_services().
This fix also makes this allocation consistent with all other persistent
allocations in "OvmfPkg/Library/LoadLinuxLib/Linux.c".
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reported-and-tested-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14555 6f19259b-4bc3-4df7-8a09-765794883524
When the PM base address was moved from 0x400 to 0xb000, this
code was missed. This prevented shutdown's via the UEFI system
call from working. (For example, at the EFI shell prompt: reset -s)
We now use gUefiOvmfPkgTokenSpaceGuid.PcdAcpiPmBaseAddress
which is currently set at 0xb000.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@14492 6f19259b-4bc3-4df7-8a09-765794883524
OvmfPkg's file-based NvVar storage is read back as follows at boot (all
paths under OvmfPkg/Library/):
PlatformBdsPolicyBehavior() [PlatformBdsLib/BdsPlatform.c]
PlatformBdsRestoreNvVarsFromHardDisk()
VisitAllInstancesOfProtocol
for each simple file system:
VisitingFileSystemInstance()
ConnectNvVarsToFileSystem() [NvVarsFileLib/NvVarsFileLib.c]
LoadNvVarsFromFs() [NvVarsFileLib/FsAccess.c]
ReadNvVarsFile()
+-------------> SerializeVariablesSetSerializedVariables() [SerializeVariablesLib/SerializeVariablesLib.c]
| SerializeVariablesIterateInstanceVariables()
| +-------------> IterateVariablesInBuffer()
| | for each loaded / deserialized variable:
| +-|-----------------> IterateVariablesCallbackSetSystemVariable()
| | | gRT->SetVariable()
| | |
| | IterateVariablesInBuffer() stops processing variables as soon as the
| | first error is encountered from the callback function.
| |
| | In this case the callback function is
| IterateVariablesCallbackSetSystemVariable(), selected by
SerializeVariablesSetSerializedVariables().
The result is that no NvVar is restored from the file after the first
gRT->SetVariable() failure.
On my system such a failure
- never happens in an OVMF build with secure boot disabled,
- happens *immediately* with SECURE_BOOT_ENABLE, because the first
variable to restore is "AuthVarKeyDatabase".
"AuthVarKeyDatabase" has the EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS
attribute set. Since the loop tries to restore it before any keys (PK, KEK
etc) are enrolled, gRT->SetVariable() rejects it with
EFI_SECURITY_VIOLATION. Consequently the NvVar restore loop terminates
immediately, and we never reach non-authenticated variables such as
Boot#### and BootOrder.
Until work on KVM-compatible flash emulation converges between qemu and
OvmfPkg, improve the SECURE_BOOT_ENABLE boot experience by masking
EFI_SECURITY_VIOLATION in the callback:
- authenticated variables continue to be rejected same as before, but
- at least we allow the loop to progress and restore non-authenticated
variables, for example boot options.
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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14390 6f19259b-4bc3-4df7-8a09-765794883524
The descriptor table (also known as "queue") consists of descriptors. (The
corresponding type in the code is VRING_DESC.)
An individual descriptor describes a contiguous buffer, to be transferred
uni-directionally between host and guest.
Several descriptors in the descriptor table can be linked into a
descriptor chain, specifying a bi-directional scatter-gather transfer
between host and guest. Such a descriptor chain is also known as "virtio
request".
(The descriptor table can host sereval descriptor chains (in-flight virtio
requests) in parallel, but the OVMF driver supports at most one chain, at
any point in time.)
The first descriptor in any descriptor chain is called "head descriptor".
In order to submit a number of parallel requests (= a set of independent
descriptor chains) from the guest to the host, the guest must put *only*
the head descriptor of each separate chain onto the Available Ring.
VirtioLib currently places the head of its one descriptor chain onto the
Available Ring repeatedly, once for each single (head *or* dependent)
descriptor in said descriptor chain. If the descriptor chain comprises N
descriptors, this error amounts to submitting the same entire chain N
times in parallel.
Available Ring Descriptor table
Ptr to head ----> Desc#0 (head of chain)
Ptr to head --/ Desc#1 (next in same chain)
... / ...
Ptr to head / Desc#(N-1) (last in same chain)
Anatomy of a single virtio-blk READ request (a descriptor chain with three
descriptors):
virtio-blk request header, prepared by guest:
VirtioAppendDesc PhysAddr=3FBC6050 Size=16 Flags=1 Head=1232 Next=1232
payload to be filled in by host:
VirtioAppendDesc PhysAddr=3B934C00 Size=32768 Flags=3 Head=1232 Next=1233
host status, to be filled in by host:
VirtioAppendDesc PhysAddr=3FBC604F Size=1 Flags=2 Head=1232 Next=1234
Processing on the host side -- the descriptor chain is processed three
times in parallel (its head is available to virtqueue_pop() thrice); the
same chain is submitted/collected separately to/from AIO three times:
virtio_queue_notify vdev VDEV vq VQ#0
virtqueue_pop vq VQ#0 elem EL#0 in_num 2 out_num 1
bdrv_aio_readv bs BDRV sector_num 585792 nb_sectors 64 opaque REQ#0
virtqueue_pop vq VQ#0 elem EL#1 in_num 2 out_num 1
bdrv_aio_readv bs BDRV sector_num 585792 nb_sectors 64 opaque REQ#1
virtqueue_pop vq VQ#0 elem EL#2 in_num 2 out_num 1
bdrv_aio_readv bs BDRV sector_num 585792 nb_sectors 64 opaque REQ#2
virtio_blk_rw_complete req REQ#0 ret 0
virtio_blk_req_complete req REQ#0 status 0
virtio_blk_rw_complete req REQ#1 ret 0
virtio_blk_req_complete req REQ#1 status 0
virtio_blk_rw_complete req REQ#2 ret 0
virtio_blk_req_complete req REQ#2 status 0
On my Thinkpad T510 laptop with RHEL-6 as host, this probably leads to
simultaneous DMA transfers targeting the same RAM area. Even though the
source of each transfer is identical, the data is corrupted in the
destination buffer -- the CRC32 calculated over the buffer varies, even
though the origin of the transfers is the same, never rewritten LBA.
SynchronousRequest Lba=585792 BufSiz=32768 ReqIsWrite=0 Crc32=BF68A44D
The problem is invisible on my HP Z400 workstation.
Fix the request submission by:
- building the only one descriptor chain supported by VirtioLib always at
the beginning of the descriptor table,
- ensuring the head descriptor of this chain is put on the Available Ring
only once,
- requesting the virtio spec's language to be cleaned up
<http://lists.linuxfoundation.org/pipermail/virtualization/2013-April/024032.html>.
Available Ring Descriptor table
Ptr to head ----> Desc#0 (head of chain)
Desc#1 (next in same chain)
...
Desc#(N-1) (last in same chain)
VirtioAppendDesc PhysAddr=3FBC6040 Size=16 Flags=1 Head=0 Next=0
VirtioAppendDesc PhysAddr=3B934C00 Size=32768 Flags=3 Head=0 Next=1
VirtioAppendDesc PhysAddr=3FBC603F Size=1 Flags=2 Head=0 Next=2
virtio_queue_notify vdev VDEV vq VQ#0
virtqueue_pop vq VQ#0 elem EL#0 in_num 2 out_num 1
bdrv_aio_readv bs BDRV sector_num 585792 nb_sectors 64 opaque REQ#0
virtio_blk_rw_complete req REQ#0 ret 0
virtio_blk_req_complete req REQ#0 status 0
SynchronousRequest Lba=585792 BufSiz=32768 ReqIsWrite=0 Crc32=1EEB2B07
(The Crc32 was double-checked with edk2's and Linux's guest IDE driver.)
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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14356 6f19259b-4bc3-4df7-8a09-765794883524
Also, add a small delay after the 0xCF9 hard reset request -- on qemu/kvm the
port access is translated to the qemu-internal system reset request by the CPU
thread, and it might progress some more before the IO thread acts upon the
system reset request.
MicroSecondDelay() is implemented by OvmfPkg's own AcpiTimerLib.
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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14158 6f19259b-4bc3-4df7-8a09-765794883524
The reset requested via the keyboard controller (port 0x64) is actually a
soft reset, but qemu has supported it since forever (plus qemu has not
distinguished between hard reset and soft reset, although this is changing
now). Therefore leave the current IoWrite() in place for compatibility.
On qemu versions with commit 1ec4ba74 ("PIIX3: reset the VM when the Reset
Control Register's RCPU bit gets set"), use the PIIX3 RCR as first choice.
In the future qemu will act differently on soft vs. hard reset requests,
and we should honor that in ResetCold().
Writing to ioport 0xCF9 on qemu builds prior to commit 1ec4ba74 should
have no effect. Access to the PCI host config register went through
several implementations in qemu. Commit 9f6f0423 ("pci_host: rewrite
using rwhandler") seems safe, both before and after.
Commit d0ed8076 ("pci_host: convert conf index and data ports to memory
API") inadvertently dropped the alignment/size check, causing a boot
regression on NetBSD. It was fixed about six months later in commit
cdde6ffc, which is current. Translating that to qemu releases, the bug
was visible from v1.0 to v1.1.0.
On physical hardware cycling between reset methods is sometimes necessary
<http://mjg59.dreamwidth.org/3561.html>. On qemu the port access should
trap immediately.
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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14157 6f19259b-4bc3-4df7-8a09-765794883524
Usage of the EFI entry point was made feasible in the kernel
x64 boot protocol 2.12 where a 32-bit & 64-bit entry point
became well defined.
http://git.kernel.org/linus/09c205af
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14132 6f19259b-4bc3-4df7-8a09-765794883524
The Xcode assembler is much pickier than GCC. Also the 64-bit
linker is not a fan of relocations so it is better to us IP
relative code, but at least it removes a relocation entry.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Andrew Fish <afish@apple.com>
[jordan.l.justen@intel.com: use .byte for retfq rather than lret]
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14055 6f19259b-4bc3-4df7-8a09-765794883524
We're supposed to zero everything in the kernel bootparams that we don't
explicitly initialise, other than the setup_header from 0x1f1 onwards
for a precisely defined length, which is copied from the bzImage.
We're *not* supposed to just pass the garbage that we happened to find
in the bzImage file surrounding the setup_header.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14052 6f19259b-4bc3-4df7-8a09-765794883524
Boot protocol 2.05 just means that the relocatable_kernel field is present
in the header. We should actually check that it's *set*.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14051 6f19259b-4bc3-4df7-8a09-765794883524
We currently just jump to offset 0x200 in the kernel image, in 64-bit
mode. This is completely broken. If it's a 32-bit kernel, we'll be
jumping into the compressed data payload.
If it's a 64-bit kernel, it'll work... but the 0x200 offset is
explicitly marked as 'may change in the future', has already changed
from 0x100 to 0x200 in the past with no fanfare, and bootloaders are
instructed that they should look at the ELF header to find the offset.
So although it does actually work today, it's still broken in the
"someone needs to whipped for doing it this way" sense of the word.
In fact, the same bug exists in other bootloaders so the 0x200 offset
probably *is* now set in stone. But still it's only valid to use it if
we *know* it's a 64-bit kernel. And we don't. There *is* no ELF header
that we can look at when we're booting a bzImage, and we can't rely on
it having a PE/COFF header either.
The 32-bit entry point is always guaranteed to work, and we need to
support it anyway. So let's just *always* use it, in 32-bit mode, and
then we don't have to make up some horrible heuristics for detecting
32-bit vs. 64-bit kernels.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14045 6f19259b-4bc3-4df7-8a09-765794883524
If QEMU's -kernel parameter was used, then download the
kernel from the FwCfg interface, and launch it. (See -kernel,
-initrd, -append) The application uses the LoadLinuxLib to boot
the kernel image.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13923 6f19259b-4bc3-4df7-8a09-765794883524
This code is based on efilinux's bzimage support.
git://git.kernel.org/pub/scm/boot/efilinux/efilinux.git
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Matt Fleming <matt.fleming@intel.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13922 6f19259b-4bc3-4df7-8a09-765794883524
Ruiyu Ni
Laszlo Ersek
Ard Biesheuvel
Star Zeng
Paolo Bonzini
Bill Paul
Gabriel Somlo
Jordan Justen
Liming Gao
Mauro Faccenda
Olivier Martin
Matt Fleming
jljusten
andrewfish