mirror_edk2.git
4 years agoIntelSiliconPkg/IntelVTdPmrPei: Parse RMRR table.
Jiewen Yao [Fri, 15 Sep 2017 04:29:10 +0000 (12:29 +0800)]
IntelSiliconPkg/IntelVTdPmrPei: Parse RMRR table.

In order to support PEI graphic, we let VTdPmrPei driver
parse DMAR table RMRR entry and allow the UMA access.

If a system has no PEI IGD, no RMRR is needed. The behavior
is unchanged.

If a system has PEI IGD, it must report RMRR in PEI phase.
The PeiVTdPrm will program the IGD VTd engine to skip the
RMRR region, and program the rest PCI VTd engine to skip
the another DMA buffer allocated in PEI phase for other
device driver.

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>
4 years agoIntelSiliconPkg/VTdInfoPpi: Let it follow DMAR table.
Jiewen Yao [Fri, 15 Sep 2017 03:33:42 +0000 (11:33 +0800)]
IntelSiliconPkg/VTdInfoPpi: Let it follow DMAR table.

We notice that there is real usage in PEI to show
the graphic out. As such we need report RMRR table
in PEI to let VTdPmrPei driver skip the IGD UMA region.

Now the VTD_INFO PPI uses the same DMAR data structure.

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>
4 years agoMdePkg/include: Add Acpi.h to DMAR table.
Jiewen Yao [Wed, 20 Sep 2017 06:39:32 +0000 (14:39 +0800)]
MdePkg/include: Add Acpi.h to DMAR table.

Suggested-by: Star Zeng <star.zeng@intel.com>
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>
4 years agoBaseTools/tools_def AARCH64: enable frame pointers for RELEASE builds
Ard Biesheuvel [Fri, 15 Sep 2017 23:06:02 +0000 (16:06 -0700)]
BaseTools/tools_def AARCH64: enable frame pointers for RELEASE builds

Commit 8f0b62a5dac0 ("BaseTools/tools_def AARCH64: enable frame pointers
for DEBUG builds") removed the -fomit-frame-pointer switch from the CFLAGS
definitions that are shared between AARCH64 DEBUG and RELEASE builds, and
moved it to the RELEASE specific ones, so that DEBUG builds can produce a
backtrace when a crash occurs.

This is actually a useful thing to have for RELEASE builds as well. AArch64
has 30 general purpose registers, and so the performance hit of having a
frame pointer is unlikely to be noticeable, nor are the additional 8 bytes
of stack space likely to present a problem.

So remove -fomit-frame-pointer altogether this time.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Liming Gao <liming.gao@intel.com>
4 years agoArmPkg/PlatformBootManagerLib: process pending capsules
Ard Biesheuvel [Mon, 11 Sep 2017 16:50:29 +0000 (17:50 +0100)]
ArmPkg/PlatformBootManagerLib: process pending capsules

Process any capsule HOBs that were left for us by CapsulePei. This
involves calling ProcessCapsules() twice, as explained in the comment
in DxeCapsuleLibFmp [sic].

1) The first call must be before EndOfDxe. The system capsules is processed.
   If device capsule FMP protocols are exposted at this time and device FMP
   capsule has zero EmbeddedDriverCount, the device capsules are processed.
   Each individual capsule result is recorded in capsule record variable.
   System may reset in this function, if reset is required by capsule and
   all capsules are processed.
   If not all capsules are processed, reset will be defered to second call.

2) The second call must be after EndOfDxe and after ConnectAll, so that all
   device capsule FMP protocols are exposed.
   The system capsules are skipped. If the device capsules are NOT processed
   in first call, they are processed here.
   Each individual capsule result is recorded in capsule record variable.
   System may reset in this function, if reset is required by capsule
   processed in first call and second call.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
4 years agoBaseTools: Fix a bug to correct SourceFileList
Yonghong Zhu [Fri, 15 Sep 2017 08:14:17 +0000 (16:14 +0800)]
BaseTools: Fix a bug to correct SourceFileList

We met a case that use two microcode files in the Microcode.inf file,
one is .mcb file, another is .txt file. then it cause build failure
because the SourceFileList include the .txt file's output file, while
this output file is still not be generated, so it cause
GetFileDependency report failure.

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>
4 years agoMdeModulePkg/UdfDxe: Refine enum member naming style
Hao Wu [Fri, 15 Sep 2017 00:57:40 +0000 (08:57 +0800)]
MdeModulePkg/UdfDxe: Refine enum member naming style

Similar to the naming style for variables, it's better for the name of
members in a enum type to avoid using only upper-case letters.

Cc: Paulo Alcantara <pcacjr@zytor.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Dandan Bi <dandan.bi@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Paulo Alcantara <pcacjr@zytor.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
4 years agoMdeModulePkg/Udf: Avoid declaring and initializing local GUID variable
Hao Wu [Fri, 15 Sep 2017 00:43:22 +0000 (08:43 +0800)]
MdeModulePkg/Udf: Avoid declaring and initializing local GUID variable

The local GUID variable 'UdfDevPathGuid', it has been initialized during
its declaration.

For better coding style, this commit uses a global variable instead.

Cc: Paulo Alcantara <pcacjr@zytor.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Dandan Bi <dandan.bi@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Paulo Alcantara <pcacjr@zytor.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
4 years agoMdeModulePkg/UdfDxe: Avoid short (single character) variable name
Hao Wu [Thu, 14 Sep 2017 08:02:42 +0000 (16:02 +0800)]
MdeModulePkg/UdfDxe: Avoid short (single character) variable name

In ResolveSymlink(), replace the following variable:
CHAR16              *C;

with:
CHAR16              *Char;

Cc: Paulo Alcantara <pcacjr@zytor.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Dandan Bi <dandan.bi@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Paulo Alcantara <pcacjr@zytor.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
4 years agoMdeModulePkg/Udf: Refine function description comments
Hao Wu [Thu, 14 Sep 2017 05:19:13 +0000 (13:19 +0800)]
MdeModulePkg/Udf: Refine function description comments

Cc: Paulo Alcantara <pcacjr@zytor.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Dandan Bi <dandan.bi@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Paulo Alcantara <pcacjr@zytor.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
4 years agoMdeModulePkg/UdfDxe: Use compare operator for non-boolean comparisons
Hao Wu [Thu, 14 Sep 2017 02:52:47 +0000 (10:52 +0800)]
MdeModulePkg/UdfDxe: Use compare operator for non-boolean comparisons

Cc: Paulo Alcantara <pcacjr@zytor.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Dandan Bi <dandan.bi@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Paulo Alcantara <pcacjr@zytor.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
4 years agoMdeModulePkg/UdfDxe: Fix operands of different size in bitwise OP
Hao Wu [Thu, 14 Sep 2017 02:44:59 +0000 (10:44 +0800)]
MdeModulePkg/UdfDxe: Fix operands of different size in bitwise OP

Cc: Paulo Alcantara <pcacjr@zytor.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Paulo Alcantara <pcacjr@zytor.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
4 years agoMdeModulePkg/UdfDxe: Add checks to ensure no possible NULL ptr deref
Hao Wu [Thu, 14 Sep 2017 02:15:53 +0000 (10:15 +0800)]
MdeModulePkg/UdfDxe: Add checks to ensure no possible NULL ptr deref

Case 1 - Within DuplicateFid() & DuplicateFe():
The call to AllocateCopyPool() may return NULL.
Add ASSERTs as checks.

Case 2 - Within UdfRead():
Add ASSERT to ensure 'NewFileEntryData' returned from FindFileEntry()
will not be NULL pointer.

Case 3 - Within GetAllocationDescriptorLsn():
The return value of 'GetPdFromLongAd (Volume, ParentIcb)' may be NULL,
and it will be passed into function GetShortAdLsn() which will
dereference it.
Add ASSERT in GetShortAdLsn() as check.

Case 4 - Within ReadFile():
Add ASSERT to ensure 'Data' returned from GetAedAdsData() will not be NULL
pointer.

Case 5 - Within InternalFindFile():
If both 'Parent->FileIdentifierDesc' and 'Icb' are NULL, then possible
NULL pointer dereference will happen in ReadDirectoryEntry().
Add additional check to resolve.

Cc: Paulo Alcantara <pcacjr@zytor.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Paulo Alcantara <pcacjr@zytor.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
4 years agoMdeModulePkg/SerialDxe: Fix not able to change serial attributes
Pankaj Bansal [Mon, 18 Sep 2017 07:42:45 +0000 (15:42 +0800)]
MdeModulePkg/SerialDxe: Fix not able to change serial attributes

Issue : When try to change serial attributes using sermode
command, the default values are set with the execute flow
as below.

The sermode command calls SerialSetAttributes, which sets H/W
attributes of Serial device. After that the SerialIo protocol is
reinstalled, which causes MdeModulePkg/Universal/Console/TerminalDxe
and MdeModulePkg/Universal/Console/ConPlatformDxe drivers' bindings
to stop and then start. This in turn calls SerialReset, which undoes
changes of SerialSetAttributes.

Cause : The SerialReset command resets the attributes' values
to default.
Fix : Serial Reset command should set the attributes which have
been changed by user after calling SerialSetAttributes.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pankaj Bansal <pankaj.bansal@nxp.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
4 years agoMdeModulePkg SmbiosMeasurementDxe: Skip measurement for OEM type
Star Zeng [Thu, 14 Sep 2017 11:24:35 +0000 (19:24 +0800)]
MdeModulePkg SmbiosMeasurementDxe: Skip measurement for OEM type

The generic driver has no way to know whether an OEM type should
be filtered or not.
This patch is to update the code to skip measurement for OEM type
and platform code can measure it by self if required.

Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Chasel Chiu <chasel.chiu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Chasel Chiu <chasel.chiu@intel.com>
4 years agoNetworkPkg: Remove the redundant '/' in the end of returned ISCSIMacAddr keyword.
Fu Siyuan [Thu, 14 Sep 2017 03:13:05 +0000 (11:13 +0800)]
NetworkPkg: Remove the redundant '/' in the end of returned ISCSIMacAddr keyword.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Fu Siyuan <siyuan.fu@intel.com>
Reviewed-by: Wu Jiaxin <jiaxin.wu@intel.com>
4 years agoIntelSiliconPkg/VTdPei: Fix Linux build error.
Jiewen Yao [Mon, 18 Sep 2017 00:50:59 +0000 (08:50 +0800)]
IntelSiliconPkg/VTdPei: Fix Linux build error.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jiewen Yao <jiewen.yao@intel.com>
4 years agoIntelSiliconPkg/PlatformIntelVTdInfoSamplePei: Move to feature dir.
Jiewen Yao [Sat, 16 Sep 2017 01:35:00 +0000 (09:35 +0800)]
IntelSiliconPkg/PlatformIntelVTdInfoSamplePei: Move to feature dir.

Move PlatformIntelVTdInfoSamplePei to Feature/VTd/.

Suggested-by: Star Zeng <star.zeng@intel.com>
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>
4 years agoIntelSiliconPkg/IntelVTdPmrPei: Move to feature dir.
Jiewen Yao [Sat, 16 Sep 2017 01:33:49 +0000 (09:33 +0800)]
IntelSiliconPkg/IntelVTdPmrPei: Move to feature dir.

Move IntelVTdPmrPei to Feature/VTd/IntelVTdPmrPei.

Suggested-by: Star Zeng <star.zeng@intel.com>
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>
4 years agoIntelSiliconPkg/PlatformVTdSampleDxe: Move to feature dir.
Jiewen Yao [Sat, 16 Sep 2017 01:32:33 +0000 (09:32 +0800)]
IntelSiliconPkg/PlatformVTdSampleDxe: Move to feature dir.

Move PlatformVTdSampleDxe to Feature/VTd/PlatformVTdSampleDxe.

Suggested-by: Star Zeng <star.zeng@intel.com>
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>
4 years agoIntelSiliconPkg/IntelVTdDxe: Move to feature dir.
Jiewen Yao [Sat, 16 Sep 2017 01:28:05 +0000 (09:28 +0800)]
IntelSiliconPkg/IntelVTdDxe: Move to feature dir.

Move IntelVTdDxe to Feature/VTd/IntelVTdDxe.

Suggested-by: Star Zeng <star.zeng@intel.com>
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>
4 years agoMdeModulePkg/XhciPei: Support IoMmu.
Jiewen Yao [Thu, 7 Sep 2017 08:06:27 +0000 (16:06 +0800)]
MdeModulePkg/XhciPei: Support IoMmu.

Update XHCI driver to consume IOMMU_PPI to allocate DMA buffer.

If no IOMMU_PPI exists, this driver still calls PEI service
to allocate DMA buffer, with assumption that DRAM==DMA.

This is a compatible change.

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>
4 years agoIntelSiliconPkg/dsc: Add PlatformVTdInfoSamplePei.
Jiewen Yao [Wed, 6 Sep 2017 12:40:37 +0000 (20:40 +0800)]
IntelSiliconPkg/dsc: Add PlatformVTdInfoSamplePei.

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>
4 years agoIntelSiliconPkg: Add PlatformVTdInfoSamplePei.
Jiewen Yao [Wed, 6 Sep 2017 12:40:24 +0000 (20:40 +0800)]
IntelSiliconPkg: Add PlatformVTdInfoSamplePei.

This is a sample driver to produce VTD_INFO PPI.

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>
4 years agoIntelSiliconPkg/dsc: Add IntelVTdPmrPeim.
Jiewen Yao [Fri, 1 Sep 2017 08:31:12 +0000 (16:31 +0800)]
IntelSiliconPkg/dsc: Add IntelVTdPmrPeim.

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>
4 years agoIntelSiliconPkg: Add IntelVTdPmrPei.
Jiewen Yao [Fri, 1 Sep 2017 08:30:46 +0000 (16:30 +0800)]
IntelSiliconPkg: Add IntelVTdPmrPei.

This PEIM is to produce IOMMU_PPI, so that PEI device
driver can have better DAM management.

This PEIM will setup VTD PMR register to protect
most DRAM. It allocates a big chunk DMA buffer in
the entrypoint, and only use this buffer for DMA.
Any other region is DMA protected.

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>
4 years agoIntelSiliconPkg/dec: Add VTD_INFO PPI GUID
Jiewen Yao [Wed, 6 Sep 2017 07:48:59 +0000 (15:48 +0800)]
IntelSiliconPkg/dec: Add VTD_INFO 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>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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]

4 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>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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>
4 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>