Amit Kumar [Fri, 23 Jun 2017 10:09:47 +0000 (18:09 +0800)]
MdeModulePkg/DxeCore: Fixed Interface returned by CoreOpenProtocol
Change since v4: Revise the patch based on V4 sent by Amit Kumar
1) Only return the corresponding protocol interface in *Interface
if the return status is EFI_SUCCESS or EFI_ALREADY_STARTED.
2) Interface is returned unmodified for all error conditions except
EFI_UNSUPPORTED and EFI_ALREADY_STARTED, NULL will be returned in
*Interface when EFI_UNSUPPORTED and Attributes is not
EFI_OPEN_PROTOCOL_TEST_PROTOCOL, the protocol interface will be
returned in *Interface when EFI_ALREADY_STARTED.
Change since v3:
1) Fixed issue when Attributes = EFI_OPEN_PROTOCOL_TEST_PROTOCOL
and Inteface = NULL case. [Reported by:star.zeng at intel.com]
Change Since v2:
1) Modified to use EFI_ERROR to get status code
Change since v1:
1) Fixed typo protocal to protocol
2) Fixed coding style
Cc: Laszlo Ersek <lersek@redhat.com> Cc: Amit Kumar <amit.ak@samsung.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Gabriel Somlo <gsomlo@gmail.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Amit Kumar <amit.ak@samsung.com> Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Gabriel Somlo <gsomlo@gmail.com>
For oneof/numeric/CheckBox(storage can be Bit VarStore)
If the question value can be updated and shown correctly
in UI page, we need do enhancements in following cases:
1. Parse the Ifr data to get the bit VarStore info correctly.
2. Set/get value to/from bit VarStore correctly.
Cc: Eric Dong <eric.dong@intel.com> Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
For oneof/numeric/checkbox, their storage may be bit field.
When generating <ConfigAltResp> string to get default value
for these questions, we need to parse the Ifr data to get
the bit Varstore info,and then generating the correct
<ConfigAltResp> string.
Cc: Eric Dong <eric.dong@intel.com> Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
Enhance VfrCompiler to parse following case:
1. EFI/Buffer VarStore can contain bit fields in their structure.
2. For question Oneof/Checkbox/numeric, their storage can be
bit fields of an EFI VarStore/Buffer VarStore.
Cc: Eric Dong <eric.dong@intel.com> Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
As mentioned in the above Bugzilla link by Steven, within the function
PathCleanUpDirectories(), when executing command:
"cd ."
under Shell, the input parameter 'Path' string will have string length
less than 2. Hence, it is possible for the below statement:
"if (StrCmp (Path + StrLen (Path) - 2, L"\\.") == 0) {"
to read contents before the string boundary.
This commit adds additional checks to avoid this.
Cc: Steven Shi <steven.shi@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <liming.gao@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>
From GCD perspective, its SetMemorySpaceAttributes() method doesn't accept page
related attributes. That means users cannot use it to change page attributes,
and have to turn to CPU arch protocol to do it, which is not be allowed by PI
spec.
Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Suggested-by: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
UefiCpuPkg/CpuDxe: Fix out-of-sync issue in page attributes
From CpuDxe driver perspective, it doesn't update GCD memory attributes from
current page table setup during its initialization. So the memory attributes in
GCD might not reflect all memory attributes in real world.
Cc: Eric Dong <eric.dong@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Suggested-by: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
OvmfPkg/QemuVideoDxe/VbeShim: handle PAM1 register on Q35 correctly
In commit db27e9f3d8f0 ("OvmfPkg/LegacyRegion: Support legacy region
manipulation of Q35", 2016-03-15), Ray extended the
OvmfPkg/Csm/CsmSupportLib PAM register manipulation to Q35. However, we
missed that the same should be done to the QemuVideoDxe VBE Shim as well.
The omission has caused no problems in practice on Q35, because QEMU has
let us write to the ROM area, regardless of the PAM1 setting, all this
time. This has now changed with recent QEMU commit 208fa0e43645 ("pc: make
'pc.rom' readonly when machine has PCI enabled", 2017-07-28). The QEMU
commit exposes the OVMF bug when Windows 7 is started on Q35, using QEMU
2.10 -- the VBE Shim is no longer put in place and Windows 7 cannot find
it.
To remedy this, assign the "Pam1Address" local variable a PciLib address
that matches the board type (i440fx vs. q35).
Regarding the PcdLib dependency: QemuVideoDxe already uses PcdLib, both
directly (see "PcdDriverSupportedEfiVersion") and indirectly (e.g. via the
DxePciLibI440FxQ35 PciLib instance). Add PcdLib to [LibraryClasses] for
completeness.
Cc: Aleksei Kovura <alex3kov@zoho.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Ref: https://bugs.launchpad.net/qemu/+bug/1715700 Reported-by: Aleksei Kovura <alex3kov@zoho.com> Special-thanks-to: Gerd Hoffmann <kraxel@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Aleksei Kovura <alex3kov@zoho.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
OvmfPkg/CsmSupportLib: move PAM register addresses to IndustryStandard
* Introduce the PIIX4_PAM* and MCH_PAM* macros under
"OvmfPkg/Include/IndustryStandard". These macros capture the PAM
register offsets (in PCI config space) on the respective Memory
Controller B/D/F, from the respective data sheets.
* Under IndustryStandard, introduce the PMC_REGISTER_PIIX4() macro for
PIIX4. (For Q35, we already have DRAMC_REGISTER_Q35().) In both cases,
the B/D/F is 0/0/0.
* Under CsmSupportLib, replace the "PAMRegOffset" field (UINT8) in the
PAM_REGISTER_VALUE structure with "PAMRegPciLibAddress" (UINTN). The new
field contains the return value of the PCI_LIB_ADDRESS() macro.
* Under CsmSupportLib, replace the "mRegisterValues440" elements as
follows:
* Under CsmSupportLib, remove the PAM_PCI_* and REG_PAM*_OFFSET_* macros.
Technically speaking, these changes could be split into three patches
(IndustryStandard macro additions, CsmSupportLib code updates,
CsmSupportLib macro removals). However, the patch is not big, and in this
case it is actually helpful to present the code movement / refactoring in
one step, for easier verification.
Cc: Aleksei Kovura <alex3kov@zoho.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Ref: https://bugs.launchpad.net/qemu/+bug/1715700
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Aleksei Kovura <alex3kov@zoho.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
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>
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>
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.
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.
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.
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>
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.
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>
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>
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.
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>
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.
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.
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.
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.
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.
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.
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].
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>
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)".
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>
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>
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>
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.
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".
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>
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>
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>
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>
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>
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>
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>
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.
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).
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>
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.
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.
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.
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.
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>
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>
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>
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.
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".
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.
projects / mirror_edk2.git / log