The Width and Height assignment suppresses an invalid gcc-4.8 warning
on Ia32.
These warnings look unjustified to me. Namely, near the beginning of
the function, there is a while(1) loop. In that loop,
ConvertBmpToGopBlt() is called unconditionally. If the call fails,
the rest of the loop body is not reached (where the Height and Width
variables are used -- the compiler warns about their use in the
switch statement). If the call succeeds, then the variables are set.
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>
EnableQuietBoot and DisableQuietBoot are copied from
IntelFrameworkModulePkg/Library/GenericBdsLib/BdsConsole.c.
Because these two functions are not in UefiBootManagerLib.
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 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
Ruiyu Ni
Laszlo Ersek
Ard Biesheuvel
Star Zeng
Paolo Bonzini