mirror_edk2.git
3 years agoIntelSiliconPkg/include: Add VTD_INFO PPI.
Jiewen Yao [Wed, 6 Sep 2017 07:47:23 +0000 (15:47 +0800)]
IntelSiliconPkg/include: Add VTD_INFO PPI.

This VTD_INFO_PPI is to provide VTD information in PEI.
As such, we can have a generic VTd driver.

It is a lightweight version DMAR table, but it does
not contain PCI device information.

Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
3 years agoIntelSiliconPkg/VTdDxe: Disable PMR
Jiewen Yao [Fri, 8 Sep 2017 05:39:43 +0000 (13:39 +0800)]
IntelSiliconPkg/VTdDxe: Disable PMR

When VTd translation is enabled, PMR can be disable.
Or the DMA will be blocked by PMR.

Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
3 years agoIntelSiliconPkg/Vtd.h: Add definition for PMR.
Jiewen Yao [Mon, 4 Sep 2017 02:14:54 +0000 (10:14 +0800)]
IntelSiliconPkg/Vtd.h: Add definition for PMR.

Add missing PMR definition in VTd spec.

Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
3 years agoMdeModulePkg/Dec: Add IOMMU_PPI GUID.
Jiewen Yao [Fri, 1 Sep 2017 08:31:00 +0000 (16:31 +0800)]
MdeModulePkg/Dec: Add IOMMU_PPI GUID.

Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
3 years agoMdeModulePkg/Include: Add IOMMU_PPI.
Jiewen Yao [Fri, 1 Sep 2017 04:42:54 +0000 (12:42 +0800)]
MdeModulePkg/Include: Add IOMMU_PPI.

This IOMMU_PPI is to provide IOMMU abstraction in PEI.

Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
3 years agoArmPkg: ARM v8.2 updates for detecting FP
Sami Mujawar [Thu, 14 Sep 2017 16:11:21 +0000 (17:11 +0100)]
ArmPkg: ARM v8.2 updates for detecting FP

The ARMv8.2-FP16 extension introduces support for half precision
floating point and the processor ID registers have been updated to
enable detection of the implementation.

The possible values for the FP bits in ID_AA64PFR0_EL1[19:16] are:
  - 0000 : Floating-point is implemented.
  - 0001 : Floating-point including Half-precision support is
           implemented.
  - 1111 : Floating-point is not implemented.
  - All other values are reserved.

Previously ArmEnableVFP() compared the FP bits with 0000b to see if
the FP was implemented, before enabling FP. Modified this check to
enable the FP if the FP bits 19:16 are not 1111b.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Signed-off-by: Evan Lloyd <evan.lloyd@arm.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
3 years agoMdeModulePkg/UdfDxe: Fix NULL pointer dereference
Paulo Alcantara [Tue, 12 Sep 2017 01:30:23 +0000 (09:30 +0800)]
MdeModulePkg/UdfDxe: Fix NULL pointer dereference

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=704

For root directory, the FID (File Identifier Descriptor) pointer is
accessible through PRIVATE_UDF_FILE_DATA.Root, whereas non-root
directory and regular files, their FIDs are accessible through
PRIVATE_UDF_FILE_DATA.File.

In UdfSetPosition(), the FID was retrieved through
PRIVATE_UDF_FILE_DATA.File, hence when calling it with a root directory,
PRIVATE_UDF_FILE_DATA.File.FileIdentifierDescriptor would be NULL and
then dereferenced.

This patch fixes the NULL pointer dereference by calling _FILE() to
transparently return the correct UDF_FILE_INFO * which points to a valid
FID descriptor of a specific file.

Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Steven Shi <steven.shi@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Reported-by: Steven Shi <steven.shi@intel.com>
Signed-off-by: Paulo Alcantara <pcacjr@zytor.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
3 years agoMdeModulePkg UdfDxe: Fix VS2010/VS2012 build failure
Star Zeng [Thu, 14 Sep 2017 10:52:22 +0000 (18:52 +0800)]
MdeModulePkg UdfDxe: Fix VS2010/VS2012 build failure

VS2010/VS2012 build failure with below info:
warning C4701:
  potentially uninitialized local variable 'DataOffset' used
  potentially uninitialized local variable 'FilePosition' used
  potentially uninitialized local variable 'FinishedSeeking' used
  potentially uninitialized local variable 'Data' used
warning C4703:
  potentially uninitialized local pointer variable 'Data' used

In fact, DataOffset, FilePosition and FinishedSeeking are initialized
and then used if (ReadFileInfo->Flags == READ_FILE_SEEK_AND_READ).
DoFreeAed will be set to TRUE when Data is allocated and returned from
GetAedAdsData(), and Data will be freed if (DoFreeAed) when exiting.

Use same method at 5afa5b815936e2b45a375b6521764195bed68680 to fix
the build failure.

There is related discussion at
https://lists.01.org/pipermail/edk2-devel/2017-September/014641.html

Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Paulo Alcantara <pcacjr@zytor.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Dandan Bi <dandan.bi@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Paulo Alcantara <pcacjr@zytor.com>
3 years agoOvmfPkg/VirtioNetDxe: negotiate VIRTIO_F_IOMMU_PLATFORM
Brijesh Singh [Thu, 14 Sep 2017 21:22:47 +0000 (16:22 -0500)]
OvmfPkg/VirtioNetDxe: negotiate VIRTIO_F_IOMMU_PLATFORM

VirtioNetDxe driver has been updated to use IOMMU-like member functions
from VIRTIO_DEVICE_PROTOCOL to translate the system physical address to
device address. We do not need to do anything special when
VIRTIO_F_IOMMU_PLATFORM bit is present hence treat it in parallel with
VIRTIO_F_VERSION_1.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
3 years agoOvmfPkg/VirtioNetDxe: map caller-supplied Tx packet to device-address
Brijesh Singh [Thu, 14 Sep 2017 21:22:46 +0000 (16:22 -0500)]
OvmfPkg/VirtioNetDxe: map caller-supplied Tx packet to device-address

When device is behind the IOMMU, driver is require to pass the device
address of caller-supplied transmit buffer for the bus master operations.

The patch uses VirtioNetMapTxBuf() to map caller-supplied Tx packet to a
device-address and enqueue the device address in VRING for transfer and
perform the reverse mapping when transfer is completed so that we can
return the caller-supplied buffer.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
3 years agoOvmfPkg/VirtioNetDxe: add Tx packet map/unmap helper functions
Brijesh Singh [Thu, 14 Sep 2017 21:22:45 +0000 (16:22 -0500)]
OvmfPkg/VirtioNetDxe: add Tx packet map/unmap helper functions

When device is behind IOMMU, driver is require to pass the device address
of TxBuf in the Tx VRING. The patch adds helper functions and data
structure to map and unmap the TxBuf system physical address to a device
address.

Since the TxBuf is returned back to caller from VirtioNetGetStatus() hence
we use OrderedCollection interface to save the TxBuf system physical to
device address mapping. After the TxBuf is succesfully transmitted
VirtioNetUnmapTxBuf() does the reverse lookup in OrderedCollection data
structure to get the system physical address of TxBuf for a given device
address.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
3 years agoOvmfPkg/VirtioNetDxe: update TechNotes
Brijesh Singh [Thu, 14 Sep 2017 21:22:44 +0000 (16:22 -0500)]
OvmfPkg/VirtioNetDxe: update TechNotes

In next patches we will update Virtio transmit to use the device-mapped
address of the caller-supplied packet. The patch documents the new model.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
3 years agoOvmfPkg/VirtioNetDxe: dynamically alloc transmit header
Brijesh Singh [Thu, 14 Sep 2017 21:22:43 +0000 (16:22 -0500)]
OvmfPkg/VirtioNetDxe: dynamically alloc transmit header

Each network packet is submitted for transmission by pushing the head
descriptor of a two-part descriptor chain to the Available Ring of the
TX queue. VirtioNetInitTx() sets up the the descriptor chains for all
queueable packets in advance, and points all the head descriptors to the
same shared, never modified, VIRTIO_1_0_NET_REQ header object (or its
initial VIRTIO_NET_REQ sub-object, dependent on virtio version).
VirtioNetInitTx() currently uses the header object's system physical
address for populating the head descriptors.

When device is behind the IOMMU, VirtioNet driver is required to provide
the device address of VIRTIO_1_0_NET_REQ header. In this patch we
dynamically allocate the header using AllocateSharedPages() and map with
BusMasterCommonBuffer so that header can be accessed by both processor
and the device.

We map the header object for CommonBuffer operation because, in order to
stick with the current code order, we populate the head descriptors with
the header's device address first, and fill in the header itself second.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
3 years agoOvmfPkg/VirtioNetDxe: alloc RxBuf using AllocateSharedPages()
Brijesh Singh [Thu, 14 Sep 2017 21:22:42 +0000 (16:22 -0500)]
OvmfPkg/VirtioNetDxe: alloc RxBuf using AllocateSharedPages()

When device is behind the IOMMU, VirtioNetDxe is required to use the
device address in bus master operations. RxBuf is allocated using
AllocatePool() which returns the system physical address.

The patch uses VIRTIO_DEVICE_PROTOCOL.AllocateSharedPages() to allocate
the RxBuf and map with VirtioMapAllBytesInSharedBuffer() so that we can
obtain the device address for RxBuf.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
3 years agoOvmfPkg/VirtioNetDxe: map VRINGs using VirtioRingMap()
Brijesh Singh [Thu, 14 Sep 2017 21:22:41 +0000 (16:22 -0500)]
OvmfPkg/VirtioNetDxe: map VRINGs using VirtioRingMap()

When device is behind the IOMMU then driver need to pass the device
address when programing the bus master. The patch uses VirtioRingMap() to
map the VRING system physical address[es] to device address[es].

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
3 years agoOvmfPkg/VirtioNetDxe: add helper VirtioNetUninitRing()
Brijesh Singh [Thu, 14 Sep 2017 21:22:40 +0000 (16:22 -0500)]
OvmfPkg/VirtioNetDxe: add helper VirtioNetUninitRing()

Consolidate the virtio VRING resource cleanup into VirtioNetUninitRing().

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
3 years agoAppPkg/WebServer: Fix build failure.
Eric Dong [Wed, 13 Sep 2017 10:08:42 +0000 (18:08 +0800)]
AppPkg/WebServer: Fix build failure.

Fix build failure caused by UefiCpuPkg/MtrrLib removes deprecated macros.
related bugz: https://bugzilla.tianocore.org/show_bug.cgi?id=691

Cc: Daryl McDaniel <edk2-lists@mc2research.org>
Cc: Jaben Carsey <jaben.carsey@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Daryl McDaniel <edk2-lists@mc2research.org>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
3 years agoMdeModulePkg/UdfDxe: suppress incorrect compiler warning in ReadFile()
Laszlo Ersek [Tue, 12 Sep 2017 21:54:23 +0000 (23:54 +0200)]
MdeModulePkg/UdfDxe: suppress incorrect compiler warning in ReadFile()

When building the driver for DEBUG/RELEASE, GCC48/GCC49 warn about
ReadFile() possibly using "BytesLeft" without initializing it first.

This is not the case. The reads of "BytesLeft" are only reachable if
(ReadFileInfo->Flags == READ_FILE_SEEK_AND_READ). But, in that case, we
also set "BytesLeft" to "ReadFileInfo->FileDataSize", near the top of the
function.

Assign "BytesLeft" zero at the top, and add a comment that conforms to the
pending Coding Style Spec feature request at
<https://bugzilla.tianocore.org/show_bug.cgi?id=607>.

This issue was reported by Ard's and Gerd's CI systems independently.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Paulo Alcantara <pcacjr@zytor.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Reported-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reported-by: Gerd Hoffmann <kraxel@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Paulo Alcantara <pcacjr@zytor.com>
3 years agoMdeModulePkg/UdfDxe: reject reserved values in ICB.Flags[2:0]
Laszlo Ersek [Tue, 12 Sep 2017 21:39:12 +0000 (23:39 +0200)]
MdeModulePkg/UdfDxe: reject reserved values in ICB.Flags[2:0]

The ECMA-167 standard (3rd Edition, June 1997) reserves values 4 through 7
in the ICB.Flags[2:0] bit-field for future standardization; see "14.6 ICB
Tag" / "14.6.8 Flags (RBP 18)".

https://www.ecma-international.org/publications/standards/Ecma-167.htm

The

  switch (RecordingFlags)

statement in the ReadFile() function handles all the standard values,
using the constants of the UDF_FE_RECORDING_FLAGS enum type. However, the
reserved values are not caught with a "default" case label, which both
breaks the edk2 Coding Style Spec, and leaves the Status variable
un-initialized, before we return Status under the Done label.

Set Status to EFI_UNSUPPORTED if we encounter a reserved value.

This issue was reported by Ard's and Gerd's CI systems independently
(through build failures with GCC48/GCC49, DEBUG/RELEASE targets).

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Paulo Alcantara <pcacjr@zytor.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Reported-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reported-by: Gerd Hoffmann <kraxel@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Paulo Alcantara <pcacjr@zytor.com>
3 years agoMdeModulePkg: Add UdfDxe to the dsc file
Bi, Dandan [Wed, 13 Sep 2017 07:36:58 +0000 (15:36 +0800)]
MdeModulePkg: Add UdfDxe to the dsc file

Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
3 years agoMdeModulePkg: Update PiDxeS3BootScriptLib Internal function name
Liming Gao [Fri, 8 Sep 2017 02:39:44 +0000 (10:39 +0800)]
MdeModulePkg: Update PiDxeS3BootScriptLib Internal function name

To avoid the function name conflict, update the internal function name
to be the specific one.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
3 years agoMdeModulePkg/UdfDxe: Remove negative comparison of unsigned number
Paulo Alcantara [Wed, 13 Sep 2017 04:44:54 +0000 (12:44 +0800)]
MdeModulePkg/UdfDxe: Remove negative comparison of unsigned number

This patch gets rid of a negative comparison of an UINT64 type (Offset)
as it'll never evaluate to true.

Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Dandan Bi <dandan.bi@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Reported-by: Star Zeng <star.zeng@intel.com>
Signed-off-by: Paulo Alcantara <pcacjr@zytor.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
3 years agoArmVirtPkg/ArmVirtQemu: include UsbMassStorageDxe
Laszlo Ersek [Mon, 11 Sep 2017 15:27:31 +0000 (17:27 +0200)]
ArmVirtPkg/ArmVirtQemu: include UsbMassStorageDxe

This is needed for recognizing QEMU's "usb-storage" device model.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
3 years agoArmVirtPkg/ArmVirtQemu: port HTTP_BOOT_ENABLE from OvmfPkg
Laszlo Ersek [Mon, 11 Sep 2017 11:18:05 +0000 (13:18 +0200)]
ArmVirtPkg/ArmVirtQemu: port HTTP_BOOT_ENABLE from OvmfPkg

* From commit ab44a6e833fa ("OvmfPkg: Add HttpBoot support", 2015-08-23):
  - introduce HTTP_BOOT_ENABLE build define
  - resolve HttpLib class
  - include NetworkPkg drivers DnsDxe, HttpDxe, HttpBootDxe

* From commit 1a85139d9eac ("OvmfPkg: Build HTTP utilities driver",
  2015-08-28):
  - include NetworkPkg driver HttpUtilitiesDxe

* From commit 4b2fb7986d57 ("OvmfPkg: Allow HTTP connections if HTTP Boot
  enabled", 2017-01-19):
  - set PcdAllowHttpConnections to TRUE

> ## Indicates whether HTTP connections (i.e., unsecured) are permitted or
> ## not.
> # TRUE  - HTTP connections are allowed. Both the "https://" and
> #         "http://" URI schemes are permitted.
> # FALSE - HTTP connections are denied. Only the "https://" URI scheme is
> #         permitted.
> # @Prompt Indicates whether HTTP connections are permitted or not.
> gEfiNetworkPkgTokenSpaceGuid.PcdAllowHttpConnections|FALSE|BOOLEAN|...

TLS_ENABLE (for HTTPS) is not ported for the time being.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
3 years agoArmVirtPkg: don't build the network stack uselessly for Xen
Laszlo Ersek [Mon, 11 Sep 2017 10:58:49 +0000 (12:58 +0200)]
ArmVirtPkg: don't build the network stack uselessly for Xen

"ArmVirtXen.fdf" pulls in none of the drivers from
"MdeModulePkg/Universal/Network", therefore building them in
"ArmVirtXen.dsc", via "ArmVirt.dsc.inc", is wasted work.

Move the "MdeModulePkg/Universal/Network" drivers from "ArmVirt.dsc.inc"
to "ArmVirtQemu.dsc" and "ArmVirtQemuKernel.dsc".

Place the new block between the "Bds" and "SCSI Bus and Disk Driver"
blocks, similarly to its context in "ArmVirtQemuFvMain.fdf.inc".

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
3 years agoMdeModulePkg/PartitionDxe: remove always false comparison
Laszlo Ersek [Sat, 9 Sep 2017 22:42:02 +0000 (00:42 +0200)]
MdeModulePkg/PartitionDxe: remove always false comparison

In the expression

  (RemainderByMediaBlockSize != 0 ||
   Media->BlockSize > UDF_LOGICAL_SECTOR_SIZE)

the second expression is only evaluated if the first expression is false.

If the first expression is false, i.e.,

  RemainderByMediaBlockSize == 0

then UDF_LOGICAL_SECTOR_SIZE is a whole multiple of "Media->BlockSize",
which implies

  UDF_LOGICAL_SECTOR_SIZE >= Media->BlockSize.

Therefore whenever

  Media->BlockSize > UDF_LOGICAL_SECTOR_SIZE

is evaluated, it is false.

The expression

  ((expression) || FALSE)

is equivalent to

  (expression).

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Paulo Alcantara <pcacjr@zytor.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Paulo Alcantara <pcacjr@zytor.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
3 years agoMdeModulePkg/PartitionDxe: don't divide 64-bit values with C operators
Laszlo Ersek [Sat, 9 Sep 2017 22:23:42 +0000 (00:23 +0200)]
MdeModulePkg/PartitionDxe: don't divide 64-bit values with C operators

In edk2, the division and shifting of 64-bit values are forbidden with
C-language operators, because the compiler may generate intrinsic calls
for them.

For example, clang-3.8 emits a call to "__umoddi3" for

  UDF_LOGICAL_SECTOR_SIZE % Media->BlockSize

in PartitionInstallUdfChildHandles(), if PartitionDxe is built for IA32,
which then fails to link.

UDF_LOGICAL_SECTOR_SIZE has type UINT64, while
EFI_BLOCK_IO_MEDIA.BlockSize has type UINT32(). Replace the % operator
with a DivU64x32Remainder() call.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Paulo Alcantara <pcacjr@zytor.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Paulo Alcantara <pcacjr@zytor.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
3 years agoMdeModulePkg/UdfDxe: replace zero-init of local variables with ZeroMem()
Laszlo Ersek [Sat, 9 Sep 2017 21:41:01 +0000 (23:41 +0200)]
MdeModulePkg/UdfDxe: replace zero-init of local variables with ZeroMem()

In edk2, initialization of local variables is forbidden, both for
stylistic reasons and because such initialization may generate calls to
compiler intrinsics.

For the following initialization in UdfRead():

  CHAR16                          FileName[UDF_FILENAME_LENGTH] = { 0 };

clang-3.8 generates a memset() call, when building UdfDxe for IA32, which
then fails to link.

Replace the initialization with ZeroMem().

Do the same to "FilePath" in UdfOpen().

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Paulo Alcantara <pcacjr@zytor.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Paulo Alcantara <pcacjr@zytor.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
3 years agoMdeModulePkg/UdfDxe: don't return unset Status if INLINE_DATA req succeeds
Laszlo Ersek [Sat, 9 Sep 2017 21:11:41 +0000 (23:11 +0200)]
MdeModulePkg/UdfDxe: don't return unset Status if INLINE_DATA req succeeds

Ard reports that clang-3.8 correctly flags the following issue in the
ReadFile() function:

If "RecordingFlags" is INLINE_DATA, then there are three paths through the
code where we mean to return success, but forget to set Status
accordingly:

(1) when "ReadFileInfo->Flags" is READ_FILE_GET_FILESIZE, or

(2) when "ReadFileInfo->Flags" is READ_FILE_ALLOCATE_AND_READ and
    AllocatePool() succeeds, or

(3) when "ReadFileInfo->Flags" is READ_FILE_SEEK_AND_READ.

Set "Status" to EFI_SUCCESS when we are done processing the INLINE_DATA
request, i.e., when we reach the corresponding "break" statament under the
INLINE_DATA case label.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Paulo Alcantara <pcacjr@zytor.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Reported-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Paulo Alcantara <pcacjr@zytor.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
3 years agoMdeModulePkg/UdfDxe: ASSERT() valid ReadFileInfo Flags for INLINE_DATA req
Laszlo Ersek [Sat, 9 Sep 2017 21:25:33 +0000 (23:25 +0200)]
MdeModulePkg/UdfDxe: ASSERT() valid ReadFileInfo Flags for INLINE_DATA req

In the ReadFile() function, if "RecordingFlags" is INLINE_DATA, then we
cover the following values of "ReadFileInfo->Flags":

- READ_FILE_GET_FILESIZE
- READ_FILE_ALLOCATE_AND_READ
- READ_FILE_SEEK_AND_READ

We don't do anything (just proceed to the end of the function) if
"ReadFileInfo->Flags" is anything else.

In reality the above three values cover the domain of the
UDF_READ_FILE_FLAGS enum type fully, and "ReadFileInfo->Flags" is only
ever set internally to UdfDxe. Therefore any other flag value would be a
bug in UdfDxe.

ASSERT() specifically that "ReadFileInfo->Flags" has been set correctly,
so that the reader is not left wondering what happens if none of the enum
constants match.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Paulo Alcantara <pcacjr@zytor.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Paulo Alcantara <pcacjr@zytor.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
3 years agoMdeModulePkg/PartitionDxe: Initialize the array after declaration
Dandan Bi [Tue, 12 Sep 2017 08:56:16 +0000 (16:56 +0800)]
MdeModulePkg/PartitionDxe: Initialize the array after declaration

Initialize the array DescriptorLBAs[] after declaration to fix
non-constant aggregate initializer warning in VS tool chains.

Cc: Eric Dong <eric.dong@intel.com>
Cc: Paulo Alcantara <pcacjr@zytor.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: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Paulo Alcantara <pcacjr@zytor.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
3 years agoMdeModulePkg/UdfDxe: Initialize the array after declaration
Bi, Dandan [Tue, 12 Sep 2017 08:56:15 +0000 (16:56 +0800)]
MdeModulePkg/UdfDxe: Initialize the array after declaration

Initialize the array DescriptorLBAs[] after declaration to fix
non-constant aggregate initializer warning in VS tool chains.

Cc: Eric Dong <eric.dong@intel.com>
Cc: Paulo Alcantara <pcacjr@zytor.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: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Paulo Alcantara <pcacjr@zytor.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
3 years agoMdeModulePkg/UdfDxe: Add type cast to fix build failure in VS tools
Bi, Dandan [Tue, 12 Sep 2017 08:56:14 +0000 (16:56 +0800)]
MdeModulePkg/UdfDxe: Add type cast to fix build failure in VS tools

V3: Remove one unnecessay type cast in patch 1.
Codes:
if (FilePosition + ExtentLength > ReadFileInfo->FilePosition) {
  Offset = ReadFileInfo->FilePosition - FilePosition;
  if (Offset < 0) {
    Offset = -(Offset)
  }
...
}
Offset is UINT64 can not < 0, so the code logic may have some issue.
and Offset = -(Offset) may build failure in some circumstance.
Previously type cast Offset to INT64 to fix build break. Now remove
the type cast. Then can to check the code logic later.

Cc: Eric Dong <eric.dong@intel.com>
Cc: Paulo Alcantara <pcacjr@zytor.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: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Paulo Alcantara <pcacjr@zytor.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
3 years agoShellPkg/Ifconfig6: Update error message and add a new line
hegdenag [Tue, 1 Aug 2017 05:47:42 +0000 (13:47 +0800)]
ShellPkg/Ifconfig6: Update error message and add a new line

If DAD failed, we print "It failed to set", print the IPv6
address and exit. We need a better error string
and also, after printing the IPv6 address, we need a new line
else the Shell> prompt will overwrite the IPv6 address. Fixed
these issues in this patch.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hegde Nagaraj P <nagaraj-p.hegde@hpe.com>
Reviewed-by: Sriram Subramanian <sriram-s@hpe.com>
Reviewed-by: Wu Jiaxin <jiaxin.wu@intel.com>
3 years agoNetworkPkg/IScsiDxe: Fix the incorrect max length of IP_ADDRESS.
Jiaxin Wu [Wed, 30 Aug 2017 06:57:14 +0000 (14:57 +0800)]
NetworkPkg/IScsiDxe: Fix the incorrect max length of IP_ADDRESS.

When creating the ISCSI string OpCode for IP_ADDRESS, the max length
should be IP(4)_STR_MAX_SIZE instead of IP(4)_MAX_SIZE.

Cc: Ye Ting <ting.ye@intel.com>
Cc: Fu Siyuan <siyuan.fu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin <jiaxin.wu@intel.com>
Reviewed-by: Fu Siyuan <siyuan.fu@intel.com>
3 years agoOvmfPkg/SataControllerDxe: log informative message at DEBUG_INFO level
Laszlo Ersek [Mon, 4 Sep 2017 18:48:31 +0000 (20:48 +0200)]
OvmfPkg/SataControllerDxe: log informative message at DEBUG_INFO level

When a UEFI_DRIVER attempts to open a protocol interface with BY_DRIVER
attribute that it already has open with BY_DRIVER attribute,
OpenProtocol() returns EFI_ALREADY_STARTED. This is not an error. The
UEFI-2.7 spec currently says,

> EFI_ALREADY_STARTED -- Attributes is BY_DRIVER and there is an item on
>                        the open list with an attribute of BY_DRIVER
>                        whose agent handle is the same as AgentHandle.

(In fact it is so much an expected condition that recent USWG Mantis
ticket <https://mantis.uefi.org/mantis/view.php?id=1815> will codify its
additional edk2-specific behavior, namely to output the protocol interface
at once.)

Downgrade the log mask for this one condition to DEBUG_INFO, in
SataControllerStart(). This will match the log mask of the other two
informative messages in this function, "SataControllerStart START", and
"SataControllerStart END status = %r" (at which point Status can only be
EFI_SUCCESS).

Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
3 years agoOvmfPkg/PlatformBootManagerLib: log informative message at DEBUG_INFO lvl
Laszlo Ersek [Mon, 4 Sep 2017 18:34:18 +0000 (20:34 +0200)]
OvmfPkg/PlatformBootManagerLib: log informative message at DEBUG_INFO lvl

"Boot Mode:%x" is an informative message, not an error report. Set its
debug mask to DEBUG_INFO.

Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
3 years agoOvmfPkg/PlatformPei: log informative message at DEBUG_INFO level
Laszlo Ersek [Mon, 4 Sep 2017 18:31:21 +0000 (20:31 +0200)]
OvmfPkg/PlatformPei: log informative message at DEBUG_INFO level

"Platform PEIM Loaded" is an informative message, not an error report. Set
its debug mask to DEBUG_INFO.

Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
3 years agoUefiCpuPkg/CpuDxe: log informative message at DEBUG_INFO level
Laszlo Ersek [Mon, 4 Sep 2017 18:28:57 +0000 (20:28 +0200)]
UefiCpuPkg/CpuDxe: log informative message at DEBUG_INFO level

"Detect CPU count: %d\n" is an informative message, not an error report.
Set its debug mask to DEBUG_INFO.

Cc: Eric Dong <eric.dong@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
3 years agoMdeModulePkg/UsbBusDxe: log warning message at DEBUG_WARN level
Laszlo Ersek [Mon, 4 Sep 2017 18:36:37 +0000 (20:36 +0200)]
MdeModulePkg/UsbBusDxe: log warning message at DEBUG_WARN level

"UsbSelectConfig: failed to connect driver %r, ignored" is an error
message, but it states at once that the error condition will not affect
the control flow. Degrade the report to DEBUG_WARN.

Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
3 years agoOvmfPkg/PlatformDebugLibIoPort: write messages with IoWriteFifo8()
Laszlo Ersek [Mon, 4 Sep 2017 14:30:40 +0000 (16:30 +0200)]
OvmfPkg/PlatformDebugLibIoPort: write messages with IoWriteFifo8()

Since commit 19c6d9feaaf8 ("MdePkg: Expand BaseIoLibIntrinsic (IoLib
class) library", 2017-01-14), IoWriteFifo8() has been widely available to
modules. Use it to print debug messages and assertion failures to the QEMU
debug port, rather than open-coded loops.

In the general case this speeds up logging, because debug messages will
now trap to QEMU once per message (as opposed to once per character), due
to "REP OUTSB" in "MdePkg/Library/BaseIoLibIntrinsic/*/IoFifoSev.nasm".

In SEV guests, there is no speedup (SEV doesn't support the REP prefix).
SEV is detected internally to BaseIoLibIntrinsic.

Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Brijesh Singh <brijesh.singh@amd.com>
3 years agoMdePkg/BaseIoLibIntrinsic: fix SEV (=unrolled) variants of IoWriteFifoXX()
Laszlo Ersek [Mon, 4 Sep 2017 15:09:18 +0000 (17:09 +0200)]
MdePkg/BaseIoLibIntrinsic: fix SEV (=unrolled) variants of IoWriteFifoXX()

In commit b6d11d7c4678 ("MdePkg: BaseIoLibIntrinsic (IoLib class)
library", 2017-04-12), the MOV instructions in the write loops were
probably copied from the read loops. However, the operand order was not
adjusted.

As a result, the IoWriteFifoXX() routines, when invoked in SEV guests, now
overwrite the source buffer with value 0x01 / 0x0001 / 0x00000001 -- the
SevNoRepIo() function returns value 1 in EAX, in SEV guests --, and write
the same value to the target IO port.

Fix this by putting the target operand (AL / AX / EAX) first, and the
source operand (BYTE / WORD / DWORD [ESI/RSI]) second.

Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Fixes: b6d11d7c467810ea7f2e2eda46ef0bdc57bf1475
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
3 years agoBaseTools: Fix a bug for Mixed Pcd value display in the report
Yonghong Zhu [Sun, 10 Sep 2017 08:23:09 +0000 (16:23 +0800)]
BaseTools: Fix a bug for Mixed Pcd value display in the report

the case is that override the mixed pcd value in DSC [Components]
section, the value display in the report is incorrect.

Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yonghong Zhu <yonghong.zhu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
3 years agoMdeModulePkg Xhci: Correct description of Timeout param in XhciReg.h
Star Zeng [Thu, 7 Sep 2017 11:10:33 +0000 (19:10 +0800)]
MdeModulePkg Xhci: Correct description of Timeout param in XhciReg.h

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=653

Correct description of Timeout param in XhciReg.h to be matched with
XhciReg.c.

Cc: Alexei Fedorov <Alexei.Fedorov@arm.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
3 years agoBaseTools: Not show *B when Pcd value in build option same with DEC
Yonghong Zhu [Mon, 4 Sep 2017 08:40:26 +0000 (16:40 +0800)]
BaseTools: Not show *B when Pcd value in build option same with DEC

Per build spec, If the value obtained from either a build option, the
DSC or FDF is the same as the value in the DEC, then *B , *P or *F
will not be shown in the report.

Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yonghong Zhu <yonghong.zhu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
3 years agoBaseTools: Fix the bug that same region print twice in the build log
Yonghong Zhu [Tue, 5 Sep 2017 07:42:23 +0000 (15:42 +0800)]
BaseTools: Fix the bug that same region print twice in the build log

This patch fixed the bug that same region print twice in the build log.

Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yonghong Zhu <yonghong.zhu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
3 years agoBaseTools: correct to use specific arch to generate DSC database
Yonghong Zhu [Tue, 5 Sep 2017 11:34:03 +0000 (19:34 +0800)]
BaseTools: correct to use specific arch to generate DSC database

Not generic to use 'Common' arch, but use current build arch.

Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yonghong Zhu <yonghong.zhu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
3 years agoBaseTools/GCC: set -Wno-unused-const-variable on RELEASE builds
Thomas Lamprecht [Fri, 8 Sep 2017 07:01:31 +0000 (09:01 +0200)]
BaseTools/GCC: set -Wno-unused-const-variable on RELEASE builds

TianoCore BZ#700 [1]

Set the '-Wno-unused-const-variables' in RELEASE builds with the
GGC49 and GCC5 toolchain.

This fixes the RELEASE build of OVMF with GCC in version 6 or newer.
GCC 6 added the '-Wunused-const-variable' warning, which gets
activated by '-Wunused-variable' and has the following behavior:
"Warn whenever a constant static variable is unused aside from its
declaration" [2]

Commit 2ad6ba80a1bd58382bde6b994070f7c01d2fb48d introduced a case
where exactly this happens on a RELEASE build. All uses of the static
const variable are located in debug code only, which gets thrown out
by the compiler on RELEASE builds and thus triggers the
unused-const-variable warning.

There is currently no GCC 6 toolchain target defined and doing so
would add a lot of boilerplate code. Instead, use the fact that GCC
ignores unknown '-Wno-*' options:

"[...] if the -Wno- form is used [...] no diagnostic is produced for
-Wno-unknown-warning unless other diagnostics are being produced"

This behavior is available in GCC 4.9 [3] (and also earlier, for that
matter), so add the flag to the GCC49 and GCC5 toolchain, even if
both GCC versions do not supports it.
GCC49 doesn't enables LTO whereas GCC5 does. As GCC 6.0 through 6.2
had bugs relating to LTO there can be desire to use the GCC49 target
even if compiling with GCC 6, see 432f1d83f77a.

Orient the changes on 20d00edf21d2 which moved the
'-Wno-unused-but-set-variable' flag to RELEASE builds only, as there
it ensure that it does not gets raised if the only usage of a
variable is in (then collapsed) debug code.

[1] https://bugzilla.tianocore.org/show_bug.cgi?id=700
[2] https://gcc.gnu.org/onlinedocs/gcc-6.4.0/gcc/Warning-Options.html#index-Wunused-const-variable
[3] https://gcc.gnu.org/onlinedocs/gcc-4.9.0/gcc/Warning-Options.html

Cc: Yonghong Zhu <yonghong.zhu@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Liming Gao <liming.gao@intel.com>
[lersek@redhat.com: fix typo in subject]

3 years agoNt32Pkg: Enable UDF file system support
Paulo Alcantara [Fri, 8 Sep 2017 12:41:50 +0000 (09:41 -0300)]
Nt32Pkg: Enable UDF file system support

This patch enables UDF file system support by default.

Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Hao Wu <hao.a.wu@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Paulo Alcantara <pcacjr@zytor.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
3 years agoArmVirtPkg: Enable UDF file system support
Paulo Alcantara [Fri, 8 Sep 2017 12:41:49 +0000 (09:41 -0300)]
ArmVirtPkg: Enable UDF file system support

This patch enables UDF file system support by default.

Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Paulo Alcantara <pcacjr@zytor.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
3 years agoOvmfPkg: Enable UDF file system support
Paulo Alcantara [Fri, 8 Sep 2017 12:41:48 +0000 (09:41 -0300)]
OvmfPkg: Enable UDF file system support

This patch enables UDF file system support by default.

Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Paulo Alcantara <pcacjr@zytor.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
3 years agoMdeModulePkg: Initial UDF/ECMA-167 file system support
Paulo Alcantara [Fri, 8 Sep 2017 12:41:47 +0000 (09:41 -0300)]
MdeModulePkg: Initial UDF/ECMA-167 file system support

This patch introduces UDF file system support in EDK2. All block devices
that support BlockIo and DiskIo protocols and contain a valid UDF file
system - as specified by OSTA Universal Disk Format (revisions 1.02
through 2.60) - will be installed EFI_SIMPLE_FILE_SYSTEM_PROTOCOL to
provide access to underlying file system.

File system operations on regular, directory and symlink files are
supported.

Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Paulo Alcantara <pcacjr@zytor.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
3 years agoMdeModulePkg/PartitionDxe: Add UDF file system support
Paulo Alcantara [Fri, 8 Sep 2017 12:41:46 +0000 (09:41 -0300)]
MdeModulePkg/PartitionDxe: Add UDF file system support

Scan for UDF file systems on all block devices, as specified by OSTA
Universal Disk Format Specification 2.60, and install a Vendor-Defined
Media Device Path for each file system found.

The Vendor-Defined Media Device Path for the UDF file system is then
checked by UdfDxe to decide whether or not start the driver.

Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Paulo Alcantara <pcacjr@zytor.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
3 years agoMdePkg: Add UDF volume structure definitions
Paulo Alcantara [Fri, 8 Sep 2017 12:41:45 +0000 (09:41 -0300)]
MdePkg: Add UDF volume structure definitions

This patch adds basic volume structure definitions necessary to identify
a valid UDF file system on a block device, as specified by OSTA
Universal Disk Format Specification 2.60.

Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Paulo Alcantara <pcacjr@zytor.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
3 years agoOvmfPkg/IoMmuDxe: unmap all IOMMU mappings at ExitBootServices()
Laszlo Ersek [Thu, 7 Sep 2017 16:02:54 +0000 (18:02 +0200)]
OvmfPkg/IoMmuDxe: unmap all IOMMU mappings at ExitBootServices()

Register an ExitBootServices() callback that tears down all IOMMU
mappings, without modifying the UEFI memory map.

The trick is that in the ExitBootServices() callback, we don't immediately
do the work; instead we signal another (private) event.

Normally the dispatch order of ExitBootServices() callbacks is unspecified
(within the same task priority level anyway). By queueing another
function, we delay the unmapping until after all PciIo and Virtio drivers
abort -- in their own ExitBootServices() callbacks -- the pending DMA
operations of their respective controllers.

Furthermore, the fact that IoMmuUnmapWorker() rewrites client-owned memory
when it unmaps a Write or CommonBuffer bus master operation, is safe even
in this context. The existence of any given "MapInfo" in "mMapInfos"
implies that the client buffer pointed-to by "MapInfo->CryptedAddress" was
live when ExitBootServices() was entered. And, after entering
ExitBootServices(), nothing must have changed the UEFI memory map, hence
the client buffer at "MapInfo->CryptedAddress" still exists.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
3 years agoOvmfPkg/IoMmuDxe: generalize IoMmuUnmap() to IoMmuUnmapWorker()
Laszlo Ersek [Thu, 7 Sep 2017 15:26:57 +0000 (17:26 +0200)]
OvmfPkg/IoMmuDxe: generalize IoMmuUnmap() to IoMmuUnmapWorker()

IoMmuUnmapWorker() is identical to IoMmuUnmap(), it just takes an
additional BOOLEAN parameter called "MemoryMapLocked".  If the memory map
is locked, IoMmuUnmapWorker() does its usual job, but it purposely leaks
memory rather than freeing it. This makes it callable from
ExitBootServices() context.

Turn IoMmuUnmap() into a thin wrapper around IoMmuUnmapWorker() that
passes constant FALSE for "MemoryMapLocked".

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
3 years agoOvmfPkg/IoMmuDxe: track all mappings
Laszlo Ersek [Thu, 7 Sep 2017 13:30:19 +0000 (15:30 +0200)]
OvmfPkg/IoMmuDxe: track all mappings

The "mRecycledMapInfos" list implements an internal pool of unused
MAP_INFO structures between the IoMmuUnmap() and IoMmuMap() functions. The
original goal was to allow IoMmuUnmap() to tear down CommonBuffer mappings
without releasing any memory: IoMmuUnmap() would recycle the MAP_INFO
structure to the list, and IoMmuMap() would always check the list first,
before allocating a brand new MAP_INFO structure.

In one of the following patches, we'll change OvmfPkg/IoMmuDxe so that it
unmaps all existent bus master operations (CommonBuffer, Read, Write) at
ExitBootServices(), strictly after the individual device drivers abort
pending DMA on the devices they manage, in their own ExitBootServices()
notification functions.

For this, rename and repurpose the list to track all live mappings.

This means that IoMmuUnmap() will always release a MAP_INFO structure
(even when cleaning up a CommonBuffer operation). That's fine (for now),
because device drivers are no longer expected to call Unmap() in their
ExitBootServices() notification functions.

In theory, we could also move the allocation and freeing of the stash
buffer from IoMmuAllocateBuffer() and IoMmuFreeBuffer(), respectively, to
IoMmuMap() and IoMmuUnmap(). However, this would require allocating and
freeing a stash buffer in *both* IoMmuMap() and IoMmuUnmap(), as
IoMmuMap() performs in-place decryption for CommonBuffer operations, and
IoMmuUnmap() performs in-place encryption for the same.

By keeping the stash buffer allocation as-is, not only do we keep the code
almost fully undisturbed, but

- we also continue to guarantee that IoMmuUnmap() succeeds: allocating a
  stash buffer in IoMmuUnmap(), for in-place encryption after a
  CommonBuffer operation, could fail;

- we also keep IoMmuUnmap() largely reusable for ExitBootServices()
  callback context: allocating a stash buffer in IoMmuUnmap() would simply
  be forbidden in that context.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
3 years agoOvmfPkg/VirtioScsiDxe: don't unmap VRING at ExitBootServices()
Laszlo Ersek [Thu, 7 Sep 2017 12:24:22 +0000 (14:24 +0200)]
OvmfPkg/VirtioScsiDxe: don't unmap VRING at ExitBootServices()

In one of the following patches, we'll change OvmfPkg/IoMmuDxe so that it
unmaps all existent bus master operations (CommonBuffer, Read, Write) at
ExitBootServices(), strictly after the individual device drivers abort
pending DMA on the devices they manage, in their own ExitBootServices()
notification functions.

In preparation, remove the explicit
VIRTIO_DEVICE_PROTOCOL.UnmapSharedBuffer() call from VirtioScsiExitBoot(),
originally added in commit fc2168feb248 ("OvmfPkg/VirtioScsiDxe: map VRING
using VirtioRingMap()", 2017-08-31).

Add a DEBUG message so we can observe the ordering between
VirtioScsiExitBoot() and the upcoming cleanup of mappings in
OvmfPkg/IoMmuDxe.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
3 years agoOvmfPkg/VirtioRngDxe: don't unmap VRING at ExitBootServices()
Laszlo Ersek [Thu, 7 Sep 2017 12:24:22 +0000 (14:24 +0200)]
OvmfPkg/VirtioRngDxe: don't unmap VRING at ExitBootServices()

In one of the following patches, we'll change OvmfPkg/IoMmuDxe so that it
unmaps all existent bus master operations (CommonBuffer, Read, Write) at
ExitBootServices(), strictly after the individual device drivers abort
pending DMA on the devices they manage, in their own ExitBootServices()
notification functions.

In preparation, remove the explicit
VIRTIO_DEVICE_PROTOCOL.UnmapSharedBuffer() call from VirtioRngExitBoot(),
originally added in commit 0a568ccbcbd1 ("OvmfPkg/VirtioRngDxe: map host
address to device address", 2017-08-23).

Add a DEBUG message so we can observe the ordering between
VirtioRngExitBoot() and the upcoming cleanup of mappings in
OvmfPkg/IoMmuDxe.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
3 years agoOvmfPkg/VirtioGpuDxe: don't unmap VRING & BackingStore at ExitBootServices
Laszlo Ersek [Thu, 7 Sep 2017 12:24:22 +0000 (14:24 +0200)]
OvmfPkg/VirtioGpuDxe: don't unmap VRING & BackingStore at ExitBootServices

In one of the following patches, we'll change OvmfPkg/IoMmuDxe so that it
unmaps all existent bus master operations (CommonBuffer, Read, Write) at
ExitBootServices(), strictly after the individual device drivers abort
pending DMA on the devices they manage, in their own ExitBootServices()
notification functions.

In preparation, remove the explicit
VIRTIO_DEVICE_PROTOCOL.UnmapSharedBuffer() calls from VirtioGpuExitBoot(),
originally added in commit 9bc5026c19a5 ("OvmfPkg/VirtioGpuDxe: map VRING
for bus master common buffer operation", 2017-08-26) and commit
f10ae923665f ("OvmfPkg/VirtioGpuDxe: map backing store to bus master
device address", 2017-08-26).

Add a DEBUG message so we can observe the ordering between
VirtioGpuExitBoot() and the upcoming cleanup of mappings in
OvmfPkg/IoMmuDxe.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
3 years agoOvmfPkg/VirtioBlkDxe: don't unmap VRING at ExitBootServices()
Laszlo Ersek [Thu, 7 Sep 2017 12:24:22 +0000 (14:24 +0200)]
OvmfPkg/VirtioBlkDxe: don't unmap VRING at ExitBootServices()

In one of the following patches, we'll change OvmfPkg/IoMmuDxe so that it
unmaps all existent bus master operations (CommonBuffer, Read, Write) at
ExitBootServices(), strictly after the individual device drivers abort
pending DMA on the devices they manage, in their own ExitBootServices()
notification functions.

In preparation, remove the explicit
VIRTIO_DEVICE_PROTOCOL.UnmapSharedBuffer() call from VirtioBlkExitBoot(),
originally added in commit 19165130470f ("OvmfPkg/VirtioBlkDxe: map VRING
using VirtioRingMap()", 2017-08-27).

Add a DEBUG message so we can observe the ordering between
VirtioBlkExitBoot() and the upcoming cleanup of mappings in
OvmfPkg/IoMmuDxe.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
3 years agoMdeModulePkg/AtaAtapiPassThru: disable the device at ExitBootServices()
Laszlo Ersek [Sun, 3 Sep 2017 13:21:59 +0000 (15:21 +0200)]
MdeModulePkg/AtaAtapiPassThru: disable the device at ExitBootServices()

The AtaAtapiPassThru driver maps three system memory regions for Bus
Master Common Buffer operation on the following call path, if the
controller has PCI_CLASS_MASS_STORAGE_SATADPA class code:

  AtaAtapiPassThruStart()
    EnumerateAttachedDevice()
      AhciModeInitialization()
        AhciCreateTransferDescriptor()

The device is disabled (including Bus Master DMA) when the controller is
unbound, in AtaAtapiPassThruStop(). Then the regions are unmapped.

The former step should also be done when we exit the boot services, and
the OS gains ownership of system memory.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
3 years agoMdeModulePkg/AtaAtapiPassThru: unmap DMA buffers after disabling BM DMA
Laszlo Ersek [Thu, 7 Sep 2017 19:04:29 +0000 (21:04 +0200)]
MdeModulePkg/AtaAtapiPassThru: unmap DMA buffers after disabling BM DMA

In AtaAtapiPassThruStop(), if the device has been operating in AHCI mode,
we unmap the DMA buffers and then disable the device (including bus master
DMA). The order of these actions is wrong; we shouldn't unmap DMA buffers
until bus master DMA is turned off. Reverse the steps.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
3 years agoMdeModulePkg/AtaAtapiPassThru: cache EnabledPciAttributes
Laszlo Ersek [Thu, 7 Sep 2017 18:56:39 +0000 (20:56 +0200)]
MdeModulePkg/AtaAtapiPassThru: cache EnabledPciAttributes

Both AtaAtapiPassThruStart() and AtaAtapiPassThruStop() fetch the
supported attributes of the device, just so they can toggle the
IO+MMIO+BusMaster subset.

After we compute this bitmask in AtaAtapiPassThruStart(), we can cache it
for later, and save the fetch in AtaAtapiPassThruStop().

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
3 years agoNt32Pkg: Clean up DSC to remove unnecessary build option in SecMain
Liming Gao [Tue, 5 Sep 2017 06:56:28 +0000 (14:56 +0800)]
Nt32Pkg: Clean up DSC to remove unnecessary build option in SecMain

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Liming Gao <liming.gao@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
3 years agoSD : Updated CMD 6 implememtation.
Meenakshi Aggarwal [Thu, 7 Sep 2017 14:17:53 +0000 (19:47 +0530)]
SD : Updated CMD 6 implememtation.

For setting high speed in SD card,
First CMD 6 (Switch) is send to check if card supports High Speed and
Second command is send to switch card to high speed mode.

In current inplementation, CMD 6 was sent only once to switch the
card into HS mode without checking if card supports HS or not, which is
not as per specification and also we are not setting the HS i.e. 50000000
but directly asking the card to switch to 26000000 which is incorrect as
SD card supports either 25000000 or 50000000.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Meenakshi Aggarwal <meenakshi.aggarwal@nxp.com>
Reviewed-by: Jun Nie <jun.nie@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
3 years agoMMC : Added missing __FUNCTION__ macro.
Meenakshi Aggarwal [Thu, 7 Sep 2017 14:17:52 +0000 (19:47 +0530)]
MMC : Added missing __FUNCTION__ macro.

We want to print name of the function resulted in error,
but __FUNCTION__ macro was missing.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Meenakshi Aggarwal <meenakshi.aggarwal@nxp.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
3 years agoIntelSiliconPkg/IntelVtd: Consume VTd policy PCD
Jiewen Yao [Mon, 4 Sep 2017 01:50:25 +0000 (09:50 +0800)]
IntelSiliconPkg/IntelVtd: Consume VTd policy PCD

Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
3 years agoIntelSiliconPkg/dec: Add VTd policy PCD
Jiewen Yao [Mon, 4 Sep 2017 01:49:55 +0000 (09:49 +0800)]
IntelSiliconPkg/dec: Add VTd policy PCD

BIT0: This is to control if a platform wants to enable VTd
based protection during boot.
BIT1: This is to control if a platform wants to keep VTd
enabled at ExitBootService.

The default configuration is BIT0:1, BIT1:0.

Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
3 years agoOvmfPkg/SecMain: Fix stack switching to permanent memory
Ge Song [Wed, 6 Sep 2017 03:11:35 +0000 (11:11 +0800)]
OvmfPkg/SecMain: Fix stack switching to permanent memory

In earlier PEI stage, temporary memory at PcdOvmfSecPeiTempRamBase is
employed as stack and heap. We move them to the new room and do some
relocation fixup when permanent memory becomes available.
TemporaryRamMigration() is responsible for switching the stack.

Before entering TemporaryRamMigration(), Ebp/Rbp is populated with the
content of Esp/Rsp and used as frame pointer.

After the execution of SetJump/LongJump, stack migrates to new position
while the context keeps unchanged.

But when TemporaryRamMigration() exits, Esp/Rsp is filled with
the content of Ebp/Rbp to destroy this stack frame.

The result is, stack switches back to previous temporary memory.

When permanent memory becomes available, modules that have registered
themselves for shadowing will be scheduled to execute. Some of them
need to consume more memory(heap/stack). Contrast to temporary stack,
permanent stack possesses larger space.

The potential risk is overflowing the stack if stack staying in
temporary memory. When it happens, system may crash during S3 resume.

More detailed information:
> (gdb) disassemble /r
> Dump of assembler code for function TemporaryRamMigration:
>   0x00000000fffcd29c <+0>: 55 push   %rbp
>   0x00000000fffcd29d <+1>: 48 89 e5 mov    %rsp,%rbp
>   0x00000000fffcd2a0 <+4>: 48 81 ec 70 01 00 00 sub
> $0x170,%rsp
>    ...
>    ...
>    0x00000000fffcd425 <+393>: e8 80 10 00 00 callq  0xfffce4aa
> <SaveAndSetDebugTimerInterrupt>
> => 0x00000000fffcd42a <+398>: b8 00 00 00 00 mov    $0x0,%eax
>    0x00000000fffcd42f <+403>: c9 leaveq
>    0x00000000fffcd430 <+404>: c3 retq
> End of assembler dump.

See the description of leave(opcode: c9), from
Intel 64 and IA-32 Architectures Software Developer's Manual, Volume 2A

"Releases the stack frame set up by an earlier ENTER instruction. The
LEAVE instruction copies the frame pointer (in the EBP register) into
the stack pointer register (ESP), which releases the stack space
allocated to the stack frame. The old frame pointer (the frame pointer
for the calling procedure that was saved by the ENTER instruction) is
then popped from the stack into the EBP register, restoring the calling
procedure‚Äôs stack frame."

To solve this, update Ebp/Rbp too when Esp/Rsp is updated

Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ge Song <ge.song@hxt-semitech.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
3 years agoArmPkg: add ArmCrashDumpDxe driver
Ard Biesheuvel [Tue, 5 Sep 2017 18:14:41 +0000 (19:14 +0100)]
ArmPkg: add ArmCrashDumpDxe driver

Even though RELEASE builds produce some diagnostics when a crash
occurs, they can be rather unhelpful:

  Synchronous Exception at 0x0000000000000000

and sometimes, it would be useful to get a full register dump from
a production machine without having to modify the firmware.

This can be achieved very easily by incorporating a DEBUG build of
ARM's DefaultExceptionHandlerLib into a DXE driver, and registering
its DefaultExceptionHandler entry point as the synchronous exception
handler, overriding the default one. If we then build this driver
using the UefiDebugLibConOut DebugLib implementation, we end up
with a module than can simply be loaded via the Shell on any system.

Shell> load fs0:ArmCrashDumpDxe.efi

As a bonus, the crash dump will also appear on the graphical display,
not only on the serial port.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
3 years agoNetworkPkg: Fix GCC build error.
Fu Siyuan [Wed, 6 Sep 2017 10:08:07 +0000 (18:08 +0800)]
NetworkPkg: Fix GCC build error.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Fu Siyuan <siyuan.fu@intel.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
3 years agoMdeModulePkg: Fix GCC build error.
Fu Siyuan [Wed, 6 Sep 2017 10:07:40 +0000 (18:07 +0800)]
MdeModulePkg: Fix GCC build error.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Fu Siyuan <siyuan.fu@intel.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
3 years agoNetworkPkg/Ip6Dxe: fix a bug in IP6 driver for IpSec protocol notify.
Fu Siyuan [Mon, 4 Sep 2017 08:04:53 +0000 (16:04 +0800)]
NetworkPkg/Ip6Dxe: fix a bug in IP6 driver for IpSec protocol notify.

The IP driver uses EfiCreateProtocolNotifyEvent() to register notify callback
function for IpSec protocol, but it didn't notice that the callback will always
be executed at least once, even the protocol wasn't in handle database.
As a result, the Ip6IpSecProcessPacket() will still always call LocateProtocol()
even the IpSec protocol is not installed, which will impact the network
performance.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Fu Siyuan <siyuan.fu@intel.com>
Reviewed-by: Ye Ting <ting.ye@intel.com>
3 years agoMdeModulePkg/Ip4Dxe: fix a bug in IP4 driver for IpSec protocol notify.
Fu Siyuan [Mon, 4 Sep 2017 08:04:13 +0000 (16:04 +0800)]
MdeModulePkg/Ip4Dxe: fix a bug in IP4 driver for IpSec protocol notify.

The IP driver uses EfiCreateProtocolNotifyEvent() to register notify callback
function for IpSec protocol, but it didn't notice that the callback will always
be executed at least once, even the protocol wasn't in handle database.
As a result, the Ip4IpSecProcessPacket() will still always call LocateProtocol()
even the IpSec protocol is not installed, which will impact the network
performance.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Fu Siyuan <siyuan.fu@intel.com>
Reviewed-by: Ye Ting <ting.ye@intel.com>
3 years agoMdePkg/PiMmCis.h: Fix build failure.
Eric Dong [Wed, 6 Sep 2017 05:52:51 +0000 (13:52 +0800)]
MdePkg/PiMmCis.h: Fix build failure.

Include the missed header file to fix build failure.

Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
3 years agoMdePkg: Add UEFI 2.7 defined GUID and structure for AIP network media type.
Wang Fan [Thu, 24 Aug 2017 09:17:19 +0000 (17:17 +0800)]
MdePkg: Add UEFI 2.7 defined GUID and structure for AIP network media type.

Reviewed-by: Fu Siyuan <siyuan.fu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wang Fan <fan.wang@intel.com>
3 years agoIntelSiliconPkg/VTd: improve debug message.
Jiewen Yao [Wed, 6 Sep 2017 04:07:11 +0000 (12:07 +0800)]
IntelSiliconPkg/VTd: improve debug message.

Add /n for debug message to make error more
readable.

Suggested-by: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
3 years agoIntelFramdworkModulePkg/LegacyBios: Add IoMmu Support.
Jiewen Yao [Mon, 4 Sep 2017 01:28:26 +0000 (09:28 +0800)]
IntelFramdworkModulePkg/LegacyBios: Add IoMmu Support.

If IOMMU is enabled, the legacy BIOS need allow the legacy memory
access by the legacy device.
The legacy memory is below 1M memory and HighPmm memory.

Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
3 years agoIntelSiliconPkg/Vtd: Support CSM usage.
Jiewen Yao [Mon, 4 Sep 2017 08:43:35 +0000 (16:43 +0800)]
IntelSiliconPkg/Vtd: Support CSM usage.

Remove zero address check in IoMmuMap.
The reason is that a CSM legacy driver may use legacy memory for DMA.
As such, the legacyBios need allow below 1M to the legacy device.

This patch also fixed some typo.

Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
3 years agoMdePkg/PciSegmentLibSegmentInfo: fix typo in PciSegmentBitFieldAnd*()
Ruiyu Ni [Tue, 5 Sep 2017 14:49:37 +0000 (22:49 +0800)]
MdePkg/PciSegmentLibSegmentInfo: fix typo in PciSegmentBitFieldAnd*()

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
3 years agoMdeModulePkg/UefiBootManagerLib: Generate boot description for SD/eMMC
Hao Wu [Mon, 4 Sep 2017 02:18:41 +0000 (10:18 +0800)]
MdeModulePkg/UefiBootManagerLib: Generate boot description for SD/eMMC

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=620

Adds the support for SD/eMMC device path to show as a boot option.

The CID register content (returned from DiskInfo->Inquiry) seems do not
provide very useful/readable 'OEM/Application ID' and 'Product name'
field.

For SD devices, the OID is a 2-character ASCII string and the Product name
is a 5-character ASCII string.

For eMMC devices, the OID is an 8-bit binary number and the Product name
is a 6-character ASCII string.

These strings are relatively short and do not provide a very readable
description. Hence, this commit uses general 'SD (eMMC) Device' for the
boot option description.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
3 years agoPkcs7VerifyDxe: Don't allow Pkcs7Verify to install protocols twice
Peter Jones [Tue, 1 Aug 2017 02:59:00 +0000 (10:59 +0800)]
Pkcs7VerifyDxe: Don't allow Pkcs7Verify to install protocols twice

This patch makes Pkcs7VerifyDxe check that it has not already been
installed before installing its protocols.  This prevents the case
where loading it as an external driver (either manually, through
Driver#### variables, etc.) will refuse to add a second provider of
the API.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Peter Jones <pjones@redhat.com>
Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>
Reviewed-by: Long Qin <qin.long@intel.com>
3 years agoSecurityPkg/Pkcs7Verify: Complete the Pkcs7VerifyDxe protocol
Long Qin [Tue, 5 Sep 2017 07:46:21 +0000 (15:46 +0800)]
SecurityPkg/Pkcs7Verify: Complete the Pkcs7VerifyDxe protocol

VerifySignature can be implemented using a mirror of the
AuthenticodeVerify function that's already in use in the
ImageVerificationDXE environment, so this patch simply wires up
VerifySignature using that code.
<NOTE: Only Authenticode-signature verification was supported by
       this VerifySignature() implementation now.)

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Reviewed-by: Long Qin <qin.long@intel.com>
3 years agoUefiCpuPkg/Lmce.c Remove useless file.
Eric Dong [Fri, 1 Sep 2017 02:12:38 +0000 (10:12 +0800)]
UefiCpuPkg/Lmce.c Remove useless file.

Merge the code to MachineCheck.c file, remove this file.

Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
3 years agoUefiCpuPkg: ApicLib
Leo Duran [Tue, 1 Aug 2017 19:35:13 +0000 (03:35 +0800)]
UefiCpuPkg: ApicLib

GetProcessorLocationByApicId ()
- Use max possible thread count to decode InitialApicId on AMD processor.
- Clean-up on C Coding standards.

Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Jeff Fan <jeff.fan@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Leo Duran <leo.duran@amd.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
3 years agoBaseTools: update help info for -Y option to include 'HASH'
Yonghong Zhu [Mon, 4 Sep 2017 03:38:11 +0000 (11:38 +0800)]
BaseTools: update help info for -Y option to include 'HASH'

Per build spec,the default set of flags for -Y option include 'HASH',
so this patch to update the help info.

Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yonghong Zhu <yonghong.zhu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
3 years agoMdePkg PeiMemoryAllocationLib: Update InternalAllocateAlignedPages
Star Zeng [Fri, 3 Mar 2017 10:15:13 +0000 (18:15 +0800)]
MdePkg PeiMemoryAllocationLib: Update InternalAllocateAlignedPages

Update InternalAllocateAlignedPages to use PeiServicesFreePages.

Let the InternalAllocateAlignedPages in PeiMemoryAllocationLib use
same algorithm with InternalAllocateAlignedPages in
UefiMemoryAllocationLib.

Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
3 years agoMdePkg PeiMemoryAllocationLib: Update Free(Aligned)Pages
Star Zeng [Fri, 3 Mar 2017 08:45:37 +0000 (16:45 +0800)]
MdePkg PeiMemoryAllocationLib: Update Free(Aligned)Pages

Update Free(Aligned)Pages to use PeiServicesFreePages.

Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
3 years agoMdePkg PeiServicesLib: Add PeiServicesFreePages
Star Zeng [Fri, 3 Mar 2017 08:45:11 +0000 (16:45 +0800)]
MdePkg PeiServicesLib: Add PeiServicesFreePages

Add PeiServicesFreePages and update
comments for PeiServicesAllocatePages.

Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
3 years agoMdeModule PeiCore: Support pre memory page allocation
Star Zeng [Thu, 23 Feb 2017 10:16:09 +0000 (18:16 +0800)]
MdeModule PeiCore: Support pre memory page allocation

Support pre memory page allocation.
Support FreePages.
Allocation made prior to permanent memory will be
migrated to permanent memory and the HOB updated.

Cc: Liming Gao <liming.gao@intel.com>
Cc: Ruiyu Ni <Ruiyu.Ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
3 years agoMdePkg PiPeiCis.h: Add FreePages definition
Star Zeng [Thu, 23 Feb 2017 09:24:18 +0000 (17:24 +0800)]
MdePkg PiPeiCis.h: Add FreePages definition

Follow PI 1.6 spec to add FreePages definition and comments for
AllocatePages that will support pre permanent memory page allocation.

Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
3 years agoSourceLevelDebugPkg/DebugCommLibUsb3: Remove IntelFrameworkPkg.dec
Star Zeng [Thu, 31 Aug 2017 09:35:46 +0000 (17:35 +0800)]
SourceLevelDebugPkg/DebugCommLibUsb3: Remove IntelFrameworkPkg.dec

Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Hao Wu <hao.a.wu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Hao Wu <hao.a.wu@intel.com>
3 years agoSourceLevelDebugPkg/DebugCommLibUsb3Pei: Make sure alloc physical mem
Star Zeng [Thu, 31 Aug 2017 08:53:16 +0000 (16:53 +0800)]
SourceLevelDebugPkg/DebugCommLibUsb3Pei: Make sure alloc physical mem

PI 1.6 has supported pre permanent memory page allocation,
to make sure the allocated memory is physical memory for DMA,
the patch is to check memory discovered PPI installed or not first
before calling AllocatePages.

Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Hao Wu <hao.a.wu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Hao Wu <hao.a.wu@intel.com>
3 years agoSourceLevelDebugPkg: Use Pcd for the revision of transfer protocol
Hao Wu [Fri, 1 Sep 2017 01:32:10 +0000 (09:32 +0800)]
SourceLevelDebugPkg: Use Pcd for the revision of transfer protocol

V3 changes:
Add detailed description for the usage of the Pcd in package DEC file.
Update the comment for the introduced Pcd in module INF files.

V2 changes:
Instead of using a global variable, use a Pcd for transfer protocol
revision.

Previously, the revision of the debug agent transfer protocol is
reflected by a macro.

This commit introduces a Pcd to reflect the revision in order to avoid the
comparison of two macros, which will generate a constant result detected
by code checkers.

Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
3 years agoOvmfPkg/VirtioGpuDxe: negotiate VIRTIO_F_IOMMU_PLATFORM
Laszlo Ersek [Sat, 26 Aug 2017 22:56:59 +0000 (00:56 +0200)]
OvmfPkg/VirtioGpuDxe: negotiate VIRTIO_F_IOMMU_PLATFORM

VirtioGpuDxe is now IOMMU-clean; it translates system memory addresses to
bus master device addresses. Negotiate VIRTIO_F_IOMMU_PLATFORM in parallel
with VIRTIO_F_VERSION_1. (Note: the VirtIo GPU device, and this driver,
are virtio-1.0 only (a.k.a. "modern-only").)

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
3 years agoOvmfPkg/VirtioGpuDxe: map backing store to bus master device address
Laszlo Ersek [Sat, 26 Aug 2017 16:12:15 +0000 (18:12 +0200)]
OvmfPkg/VirtioGpuDxe: map backing store to bus master device address

VirtioGpuDxe is a UEFI Bus driver (not a Device driver). This is because a
UEFI graphics driver is expected to produce its GraphicsOutput protocol
instance(s) on new child handle(s) of the video controller handle, one
child handle (plus GOP) per video output (or, one child handle plus GOP
per combination of multiple video outputs).

In VirtioGpuDxe, we support a single VirtIo GPU head (scanout), namely
head#0. This means that, with regard to a specific VirtIo GPU device, the
driver may be in one of three states, at any time:

[1] VirtioGpuDxe has not bound the device at all,

[2] VirtioGpuDxe has bound the device, but not produced the sole child
    handle for head#0,

[3] VirtioGpuDxe has bound the device, and produced the sole child handle
    for head#0, with a GOP instance on the child handle.

(Which state the driver is in wrt. a given VirtIo GPU device depends on
the VirtioGpuDriverBindingStart() / VirtioGpuDriverBindingStop()
invocations issued by the ConnectController() / DisconnectController()
boot services. In turn those come from BDS or e.g. the UEFI shell.)

The concept of "current video mode" is technically tied to the GOP (i.e.,
the child handle, state [3] only), not the VirtIo GPU controller handle.
This is why we manage the storage that backs the current video mode in our
EFI_GRAPHICS_OUTPUT_PROTOCOL.SetMode() member implementation.

GopSetMode() is first called *internally*, when we enter state [3] (that
is, when we produce the child handle + GOP on it):

  VirtioGpuDriverBindingStart() [DriverBinding.c]
    InitVgpuGop()               [DriverBinding.c]
      VgpuGop->Gop.SetMode()    [Gop.c]

When this happens, we allocate the backing store *without* having a
preexistent backing store (due to no preexistent video mode and GOP).
Skipping VirtIo GPU details not relevant for this patch, we just note that
the backing store is exposed *permanently* to the VirtIo GPU device, with
the RESOURCE_ATTACH_BACKING command.

When external clients call the EFI_GRAPHICS_OUTPUT_PROTOCOL.Blt() member
function -- called GopBlt() in this driver --, in state [3], the function
operates on the backing store, and sends only small messages to the VirtIo
GPU device.

When external clients call GopSetMode() for switching between video modes
-- in state [3] --, then

- a new backing store is allocated and exposed to the device (attached to
  a new host-side VirtIo GPU resource),

- head#0 is flipped to the new backing store,

- on success, the ReleaseGopResources() function both detaches the
  previous backing store from the VirtIo GPU device, an releases it. The
  new backing store address and size are saved in our GOP object. (In
  other words, we "commit" to the new video mode.)

When the DisconnectController() boot service asks us to leave state [3] --
we can leave it directly only for state [2] --, then the
ReleaseGopResources() function is called on a different path:

  VirtioGpuDriverBindingStop() [DriverBinding.c]
    UninitVgpuGop()            [DriverBinding.c]
      ReleaseGopResources()    [Gop.c]

In this case, the backing store being released is still in use (we're not
leaving it for a new mode -- head#0 has not been flipped "away" from it),
so in ReleaseGopResources() we disable head#0 first.

(The ReleaseGopResources() function is called the same way on the error
path in InitVgpuGop(), if the first -- internal -- VgpuGop->Gop.SetMode()
call succeeds, but the rest of InitVgpuGop() fails.)

Based on the above, for IOMMU-compatibility,

- in GopSetMode(), don't just allocate, but also map the backing store of
  the nascent video mode to a device address, for bus master common buffer
  operation,

- (the VirtioGpuAllocateZeroAndMapBackingStore() helper function
  introduced in the last patch takes care of zeroing internally,)

- pass the device address to the VirtIo GPU device in the
  RESOURCE_ATTACH_BACKING command,

- if GopSetMode() succeeds, save the mapping token,

- if GopSetMode() fails, don't just free but also unmap the still-born
  backing store,

- in ReleaseGopResources(), don't just free but also unmap the backing
  store -- which is the previous backing store if we're mode-switching,
  and the current backing store if we're leaving state [3].

Finally, ExitBootServices() may be called when the driver is in either
state [1], [2] or [3], wrt. a given VirtIo GPU device. (Of course we are
only notified in states [2] and [3].) If we get the notification in state
[3], then the current video mode's backing store has to be unmapped, but
not released. (We must not change the UEFI memory map.)

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
3 years agoOvmfPkg/VirtioGpuDxe: helpers for backing store (de)allocation+(un)mapping
Laszlo Ersek [Sat, 26 Aug 2017 20:15:46 +0000 (22:15 +0200)]
OvmfPkg/VirtioGpuDxe: helpers for backing store (de)allocation+(un)mapping

Introduce the VirtioGpuAllocateZeroAndMapBackingStore() and
VirtioGpuUnmapAndFreeBackingStore() helper functions. These functions tie
together the allocation, zeroing and mapping, and unmapping and
deallocation, respectively, of memory that the virtio GPU will permanently
reference after receiving the RESOURCE_ATTACH_BACKING command.

With these functions we can keep the next patch simpler -- the GOP
implementation in "Gop.c" retains its error handling structure, and
remains oblivious to VIRTIO_DEVICE_PROTOCOL and VirtioLib.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
3 years agoOvmfPkg/VirtioGpuDxe: take EFI_PHYSICAL_ADDRESS in ResourceAttachBacking()
Laszlo Ersek [Sat, 26 Aug 2017 17:54:49 +0000 (19:54 +0200)]
OvmfPkg/VirtioGpuDxe: take EFI_PHYSICAL_ADDRESS in ResourceAttachBacking()

The RESOURCE_ATTACH_BACKING virtio GPU command assigns guest-side backing
pages to a host-side resource that was created earlier with the
RESOURCE_CREATE_2D command.

We compose the RESOURCE_ATTACH_BACKING command in the
VirtioGpuResourceAttachBacking() function. Currently this function takes
the parameter

  IN VOID *FirstBackingPage

This is only appropriate as long as we pass a (guest-phys) system memory
address to the device. In preparation for a mapped bus master device
address, change the above parameter to

  IN EFI_PHYSICAL_ADDRESS BackingStoreDeviceAddress

In order to keep the current call site functional, move the (VOID*) to
(UINTN) conversion out of the function, to the call site.

The "Request.Entry.Addr" field already has type UINT64.

This patch is similar to commit 4b725858de68 ("OvmfPkg/VirtioLib: change
the parameter of VirtioAppendDesc() to UINT64", 2017-08-23).

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>
3 years agoOvmfPkg/VirtioGpuDxe: map virtio GPU command objects to device addresses
Laszlo Ersek [Sat, 26 Aug 2017 15:34:51 +0000 (17:34 +0200)]
OvmfPkg/VirtioGpuDxe: map virtio GPU command objects to device addresses

Every virtio GPU command used by VirtioGpuDxe is synchronous and formatted
as a two-descriptor chain: request, response. The internal workhorse
function that all the command-specific functions call for such messaging
is VirtioGpuSendCommand().

In VirtioGpuSendCommand(), map the request from system memory to bus
master device address for BusMasterRead operation, and map the response
from system memory to bus master device address for BusMasterWrite
operation.

Pass the bus master device addresses to VirtioAppendDesc(). (See also
commit 4b725858de68, "OvmfPkg/VirtioLib: change the parameter of
VirtioAppendDesc() to UINT64", 2017-08-23.)

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Brijesh Singh <brijesh.singh@amd.com>