EmbeddedPkg: MmcDxe - Recieve response was missing after CMD12
We are not recieving the response from memory card after
sending CMD 12. It was not resulting in any failure but
we should recieve response after sending a command.
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>
VirtioScsiDxe 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.
Brijesh Singh [Thu, 31 Aug 2017 14:25:27 +0000 (10:25 -0400)]
OvmfPkg/VirtioScsiDxe: map virtio-scsi request and response buffers
When device is behind the IOMMU, driver is require to pass the device
address of virtio request, response and any memory referenced by those
request/response to the bus master.
The patch uses IOMMU-like member functions from VIRTIO_DEVICE_PROTOCOL to
map request and response buffers system physical address to the device
address.
- If the buffer need to be accessed by both the processor and a bus
master then map with BusMasterCommonBuffer.
- If the buffer need to be accessed for a write operation by a bus master
then map with BusMasterWrite.
However, after a BusMasterWrite Unmap() failure, error reporting via
EFI_EXT_SCSI_PASS_THRU_SCSI_REQUEST_PACKET would be very complex,
therefore we map such buffers too with BusMasterCommonBuffer.
- If the buffer need to be accessed for a read operation by a bus master
then map with BusMasterRead.
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>
[lersek@redhat.com: restore lost sentence/paragraph in commit message]
[lersek@redhat.com: reindent/reflow "InDataBuffer" comment block]
[lersek@redhat.com: cast arg, not result, of EFI_SIZE_TO_PAGES() to UINTN] Reviewed-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com>
Brijesh Singh [Thu, 31 Aug 2017 14:25:27 +0000 (10:25 -0400)]
OvmfPkg/VirtioScsiDxe: add helper to create a fake host adapter error
When virtio request fails we return EFI_DEVICE_ERROR, as per the spec
EFI_EXT_SCSI_PASS_THRU_PROTOCOL.PassThru() member function is required
to implement elaborated error reporting.
The patch refactors out entire block of the code that creates the host
adapter error into a separate helper function (ReportHostAdapterError).
Brijesh Singh [Thu, 31 Aug 2017 14:25:26 +0000 (10:25 -0400)]
OvmfPkg/VirtioScsiDxe: map VRING 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 to device address.
Ard Biesheuvel [Thu, 24 Aug 2017 19:37:01 +0000 (20:37 +0100)]
ArmPkg: remove UncachedMemoryAllocationLib
Now that ArmDmaLib can take care of its own memory allocation needs,
let's get rid of UncachedMemoryAllocationLib entirely. This forces
platforms to declare the required semantics (non-cache coherent DMA,
whichever way it is implemented), rather than using uncached memory
allocations directly, which may not always be the right choice, and
prevents sharing of drivers between platforms if one is cache coherent
and the other is not.
Ard Biesheuvel [Tue, 29 Aug 2017 13:21:02 +0000 (14:21 +0100)]
BaseTools/Gcc ARM AARCH64: add support for building device tree binaries
While modern AARCH64 server systems use ACPI for describing the platform
topology to the OS, ARM systems and AARCH64 outside of the server space
mostly use device tree binaries, which are compiled from device tree
source files using the device tree compiler.
Currently, such source files and binaries may be kept in the EDK2 platform
trees, but are not integrated with the build, which means they need to be
kept in sync and recompiled manually, which is cumbersome.
So let's wire up BaseTools support for them: add tool definitions for the
DTC compiler and preprocessor flags that allow these source files to use
FixedPcd expressions and other macros defined by AutoGen.h
This way, a device tree binary can be built from source and emitted into
a FFS file automatically using something like:
Eric Dong [Mon, 28 Aug 2017 03:05:00 +0000 (11:05 +0800)]
UefiCpuPkg/Mplib.c: Perform complete initialization when enable AP.
PI has description said If an AP is enabled, then the implementation must
guarantee that a complete initialization sequence is performed on the AP,
so the AP is in a state that is compatible with an MP operating system.
Current implementation just set the AP to idle state when enable this AP
which is not follow spec. This patch fix it.
Cc: Michael Kinney <michael.d.kinney@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: Ruiyu Ni <ruiyu.ni@intel.com>
Brijesh Singh [Wed, 30 Aug 2017 16:28:29 +0000 (12:28 -0400)]
OvmfPkg/VirtioBlkDxe: Check the return status of unmap data buffer
when "RequestIsWrite" is FALSE -- i.e., the CPU wants data from
the device, we map "Buffer" for VirtioOperationBusMasterWrite. In
this case, checking the return status of
Ard Biesheuvel [Wed, 30 Aug 2017 07:21:59 +0000 (08:21 +0100)]
EmbeddedPkg: implement NonCoherentDmaLib based on ArmDmaLib
The non-coherent DmaLib implementation in ArmDmaLib no longer relies on
anything in ArmPkg. So clone it into EmbeddedPkg, and rename it to
NonCoherentDmaLib.
Ard Biesheuvel [Wed, 30 Aug 2017 06:57:40 +0000 (07:57 +0100)]
EmbeddedPkg: rename NullDmaLib to CoherentDmaLib
The name NullDmaLib suggests that this library is a placeholder that
only exists to fulfil formal dependencies on the DmaLib library class
without providing an actual implementation. This is not the case, though:
NullDmaLib does implement DmaLib fully, but doing so simply requires very
little effort on a cache coherent platform. So let's rename it to
CoherentDmaLib instead.
Leif Lindholm [Wed, 30 Aug 2017 11:26:42 +0000 (12:26 +0100)]
EmbeddedPkg/EmbeddedPkg.dsc: fix build for non-ARM architectures
EmbeddedPkg should be architecture agnostic, but a few issues were
preventing other architectures to build individual components directly
from the .dsc:
- The AndroidBoot/AndroidFastBoot support have a dependency on BdsLib,
which only has resolutions for ARM/AARCH64. Move them to an
arch-restricted Components section.
- The Isp1761UsbDxe driver is not 64-bit compatible. It should be
converted to UEFI driver model, but for now just move it to a new
Components.ARM section. (Also delete non-useful declaration for
AARCH64 in EmbeddedPkg.dec.)
- Lan9118Dxe has an unused ArmLib entry. Drop it.
Ard Biesheuvel [Wed, 30 Aug 2017 07:25:51 +0000 (08:25 +0100)]
ArmVirtPkg: remove DmaLib library class resolution
The virt targets never use non-coherent DMA, so there is no point
in having a shared DmaLib library class resolution pointing to
ArmDmaLib. So drop it.
Huajing Li [Mon, 28 Aug 2017 06:12:33 +0000 (14:12 +0800)]
ShellPkg: Update CWD and current mapping when commands return
Some commands may cause current directory or even current mapping
become invalid. For example, "MAP" after unplugging the USB thumb
key may cause current mapping "FS0:" disappear.
This patch updates the CWD and current mapping when commands return.
It also causes the command prompt change to default "Shell>".
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Huajing Li <huajing.li@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by Jaben Carsey <jaben.carsey@intel.com>
Huajing Li [Mon, 28 Aug 2017 03:47:52 +0000 (11:47 +0800)]
ShellPkg: Fix bug that fails to change CWD after "map -r".
When "map -r" runs, the mapping list is re-created but
gShellCurMapping still points to the old mapping list which
is already destroyed.
The patch updates the gShellCurMapping to point to the correct
location in the new mapping list.
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Huajing Li <huajing.li@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by Jaben Carsey <jaben.carsey@intel.com>
Adding ARM and AARCH64 to SUPPORTED_ARCHITECTURES in SecurityPkg.dsc
to enable RngTest module build, since this is one platform-independent
application.
Laszlo Ersek [Mon, 28 Aug 2017 09:48:00 +0000 (11:48 +0200)]
OvmfPkg/QemuFwCfgDxeLib: SEV: zero FW_CFG_DMA_ACCESS before decrypting it
There's a small window between
- AllocFwCfgDmaAccessBuffer() mapping the new FW_CFG_DMA_ACCESS object for
common buffer operation (i.e., decrypting it), and
- InternalQemuFwCfgDmaBytes() setting the fields of the object.
In this window, earlier garbage in the object is "leaked" to the
hypervisor. So zero the object before we decrypt it.
(This commit message references AMD SEV directly, because QemuFwCfgDxeLib
is not *generally* enabled for IOMMU operation just yet, unlike our goal
for the virtio infrastructure. Instead, QemuFwCfgDxeLib uses
MemEncryptSevLib explicitly to detect SEV, and then relies on IOMMU
protocol behavior that is specific to SEV. At this point, this is by
design.)
Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com>
Ard Biesheuvel [Thu, 24 Aug 2017 19:05:48 +0000 (20:05 +0100)]
EmbeddedPkg/DmaLib: add routine to allocate aligned buffers
DmaLib's purpose is to manage memory that is shared between the host
and DMA capable devices. In some cases, this requires a larger alignment
than page size, and we currently don't cater for that in DmaLib. So add
a variant of DmaAllocateBuffer () that takes an alignment parameter.
For string opcode,when checking the valid string length,
it should exclude the Null-terminated character.
And for string in NameValue storage, need to exclude
the varname and also need to convert the Config string
length to Unicode string length.
Cc: Eric Dong <eric.dong@intel.com> Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
Eric Dong [Mon, 28 Aug 2017 06:35:08 +0000 (14:35 +0800)]
MdePkg: Reference new definitions for Management Mode.
In PI 1.5 version, system management mode name(SMM) has been changed
to Management Mode(MM). It impacts the current code which still use
SMM/Smram/SMI keywords. This patch update the original files which
related to old SMM modules, also keep the compatible with old SMM
related drivers.
Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
Eric Dong [Mon, 28 Aug 2017 06:20:31 +0000 (14:20 +0800)]
MdePkg: Add new definitions for Management Mode.
In PI 1.5 version, system management mode name(SMM) has been changed
to Management Mode(MM). It impacts the current code which still use
SMM/Smram/SMI keywords. This patch add new definition which use
MM/MmRam/MMI keywords to follow new spec definitions.
Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
Liming Gao [Fri, 25 Aug 2017 08:51:49 +0000 (16:51 +0800)]
BaseTools: Update toolsetup.bat to support the case without EDK_TOOLS_BIN
When EDK_TOOLS_BIN is not set, %EDK_TOOLS_PATH%\Bin\Win32 will be used as the
binary tool directory. But, %EDK_TOOLS_PATH%\Bin\Win32 may not exist. On this
case, toolsetup.bat should continue to do the other setting, such VS tool
chain and tool conf file copy.
Don't enable this option in the default setting, because it may cause VS2015
linker crash. Platform can enable this option in PlatformPkg.dsc like below:
[BuildOptions]
*_*_*_DLINK2_FLAGS = /WHOLEARCHIVE
VirtioBlkDxe 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.
Brijesh Singh [Sun, 27 Aug 2017 22:53:25 +0000 (18:53 -0400)]
Ovmfpkg/VirtioBlkDxe: map virtio-blk request and response buffers
When device is behind the IOMMU, driver is require to pass the device
address of virtio request, response and any memory referenced by those
request/response to the bus master.
The patch uses IOMMU-like member functions from VIRTIO_DEVICE_PROTOCOL to
map request and response buffers system physical address to the device
address.
- If the buffer need to be accessed by both the processor and a bus
master then map with BusMasterCommonBuffer.
- If the buffer need to be accessed for a write operation by a bus master
then map with BusMasterWrite.
- If the buffer need to be accessed for a read operation by a bus master
then map with BusMasterRead.
Brijesh Singh [Sun, 27 Aug 2017 22:53:17 +0000 (18:53 -0400)]
OvmfPkg/VirtioBlkDxe: map VRING 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 to device address.
Ruiyu Ni [Fri, 4 Aug 2017 05:23:24 +0000 (13:23 +0800)]
MdePkg/S3PciSegmentLib: Add S3PciSegmentLib class and instance.
The patch adds the new library class S3PciSegmentLib to carry out
PCI configuration and enable the PCI operations to be replayed during
an S3 resume. This library class maps directly on top of the
PciSegmentLib class.
Ruiyu Ni [Fri, 4 Aug 2017 05:18:37 +0000 (13:18 +0800)]
MdePkg/PciSegmentLib: Add instances that consumes PciSegmentInfoLib
The patch adds two PciSegmentLib instances that consumes
PciSegmentInfoLib to provide multiple segments PCI configuration
access.
BasePciSegmentLibSegmentInfo instance is a BASE library.
DxeRuntimePciSegmentLibSegmentInfo instance is to be linked with
runtime drivers to provide not only boot time but also runtime
PCI configuration access.
Ruiyu Ni [Fri, 4 Aug 2017 05:10:59 +0000 (13:10 +0800)]
MdePkg/PciSegmentInfoLib: Add PciSegmentInfoLib class and instance.
The patch adds PciSegmentInfoLib library class which is used
by PciSegmentLib (commit in next patch) to support multiple
segment PCI configuration access.
BasePciSegmentInfoLibNull instance is added but it shouldn't be
used by any real platform.
Any single segment platform that wants to use PciSegmentLib could
use BasePciSegmentLibPci instance.
Ruiyu Ni [Fri, 4 Aug 2017 05:02:14 +0000 (13:02 +0800)]
MdePkg/PciExpress: Add macro PCI_ECAM_ADDRESS
The patch adds new macro PCI_ECAM_ADDRESS into PciExpress21.h,
to align to the PCIE spec, and also update PciExpressLib.h to
redirect PCI_EXPRESS_LIB_ADDRESS to the new macro.
1. Handle flexible exception list format.
1.1 Handle DeviceScope based device info.
1.2 Handle PciDeviceId based device info.
2. Reorg the PCI_DEVICE_INFORMATION
2.1 Merge data pointer reduce allocation times
2.2 Add PCI device id to PCI_DEVICE_INFORMATION
2.3 Rename PciDescriptor to avoid confusing.
3. Fix the debug message too long issue.
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>
Eric Dong [Thu, 17 Aug 2017 03:40:38 +0000 (11:40 +0800)]
UefiCpuPkg/CpuCommonFeaturesLib: Merge machine check code to same file.
Original code about Local Machine Check exception feature saves in a
discrete file, because features related to machine check architecture
all saved in MachineCheck.c file. This patch moved LMCE logic to same
file for easy maintenance.
Cc: Michael Kinney <michael.d.kinney@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: Ruiyu Ni <ruiyu.ni@intel.com>
mLegacyBootOptionPrivate pointer is initialized in Constructor function
with if condition check, but it's used in Destructor function directly
without any check. Now add the NULL pointer check.
Cc: Eric Dong <eric.dong@intel.com> Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
Eric Dong [Fri, 18 Aug 2017 03:19:03 +0000 (11:19 +0800)]
UefiCpuPkg/CpuCommonFeaturesLib: Use MSR data structure when change MSR value.
When update MSR values, current code use BITxx to modify it. Enhance the code
to use corresponding MSR's data structures to make it more user friendly.
V2: Move architecturalMsr.h file. definition to architecturalMsr.h file.
Use structure members to do value assignment.
Cc: Michael Kinney <michael.d.kinney@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: Michael Kinney <michael.d.kinney@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=624 reports
memory protection crash in PiSmmCpuDxeSmm, Ia32 build with
RAM above 4GB (of which 2GB are placed in 64-bit address).
It is because UEFI builds identity mapping page tables,
>4G address is not supported at Ia32 build.
This patch is to get the PhysicalAddressBits that is used
to build in PageTbl.c(Ia32/X64), and use it to check whether
the address is supported or not in ConvertMemoryPageAttributes().
Daniel Verkamp [Mon, 21 Aug 2017 08:26:26 +0000 (16:26 +0800)]
BaseTools/EfiRom: Add multiple device id support
This is a patch to implement writing and dumping of PCI 3.0 Device ID
lists in EFI option ROMs in the EfiRom tool.
Using this modification, multiple space-delimited device IDs can be
specified after -i. The first device in the list is used for the main
PCI ROM header Device ID field and is also written in the list. The
list is only written when more than one device ID has been specified;
when only one device ID is given on the command line, the EfiRom output
should be identical to the current code.
TianoCore BZ#671 <https://bugzilla.tianocore.org/show_bug.cgi?id=671> has
been fixed in commit 2f7f1e73c10f ("BaseTools: Add the missing -pie link
option in GCC tool chain", 2017-08-23), so we can return to the GCC5
toolchain with gcc-7.*.
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: Jordan Justen <jordan.l.justen@intel.com>
VirtioRngDxe 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.
Brijesh Singh [Fri, 25 Aug 2017 10:37:46 +0000 (06:37 -0400)]
OvmfPkg/Virtio10: define VIRTIO_F_IOMMU_PLATFORM feature bit
This feature indicates that the device is behind an IOMMU that translates
bus addresses from the device into physical addresses in memory. If this
feature bit is set to 0, then the device emits physical addresses which
are not translated further, even though an IOMMU may be present.
see [1] for more infromation
Brijesh Singh [Wed, 23 Aug 2017 10:57:19 +0000 (06:57 -0400)]
OvmfPkg/VirtioRngDxe: map host address to device address
patch maps the host address to a device address for buffers (including
rings, device specifc request and response pointed by vring descriptor,
and any further memory reference by those request and response).
Brijesh Singh [Wed, 23 Aug 2017 10:57:19 +0000 (06:57 -0400)]
OvmfPkg/VirtioLib: change the parameter of VirtioAppendDesc() to UINT64
The patch change the "BufferPhysAddr" parameter of VirtioAppendDesc()
from type UINTN to UINT64.
UINTN is appropriate as long as we pass system memory references. After
the introduction of bus master device addresses, that's no longer the case
in general. Should we implement "real" IOMMU support at some point, UINTN
could break in 32-bit builds of OVMF.
Brijesh Singh [Wed, 23 Aug 2017 10:57:18 +0000 (06:57 -0400)]
OvmfPkg/VirtioLib: alloc VRING buffer with AllocateSharedPages()
The VRING buffer is a communication area between guest and hypervisor.
Allocate it using VIRTIO_DEVICE_PROTOCOL.AllocateSharedPages() so that
it can be mapped later with VirtioRingMap() for bi-directional access.
Brijesh Singh [Wed, 23 Aug 2017 10:57:17 +0000 (06:57 -0400)]
OvmfPkg/Virtio10Dxe: add the RingBaseShift offset
virtio drivers use VIRTIO_DEVICE_PROTOCOL.MapSharedBuffer() to map the
ring buffer host address to a device address. If an IOMMU is present then
RingBaseShift contains the offset from the host address.
Brijesh Singh [Wed, 23 Aug 2017 10:57:17 +0000 (06:57 -0400)]
OvmfPkg/Virtio: take RingBaseShift in SetQueueAddress()
For the case when an IOMMU is used for translating system physical
addresses to DMA bus master addresses, the transport-independent
virtio device drivers will be required to map their VRING areas to
bus addresses with VIRTIO_DEVICE_PROTOCOL.MapSharedBuffer() calls.
- MMIO and legacy virtio transport do not support IOMMU to translate the
addresses hence RingBaseShift will always be set to zero.
- modern virtio transport supports IOMMU to translate the address, in
next patch we will update the Virtio10Dxe to use RingBaseShift offset.
Brijesh Singh [Wed, 23 Aug 2017 10:57:16 +0000 (06:57 -0400)]
OvmfPkg/VirtioLib: add VirtioMapAllBytesInSharedBuffer() helper function
The function can be used for mapping the system physical address to virtio
device address using VIRTIO_DEVICE_PROTOCOL.MapSharedBuffer (). The
function helps with centralizing error handling, and it allows the caller
to pass in constant or other evaluated expressions for NumberOfBytes.
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>
[lersek@redhat.com: s/This/VirtIo/ in the new function's comment blocks] Reviewed-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
Brijesh Singh [Wed, 23 Aug 2017 10:57:15 +0000 (06:57 -0400)]
OvmfPkg: introduce IOMMU-like member functions to VIRTIO_DEVICE_PROTOCOL
The patch extends VIRTIO_DEVICE_PROTOCOL to provide the following new
member functions:
- AllocateSharedPages : allocate a memory region suitable for sharing
between guest and hypervisor (e.g ring buffer).
- FreeSharedPages: free the memory allocated using AllocateSharedPages ().
- MapSharedBuffer: map a host address to device address suitable to share
with device for bus master operations.
- UnmapSharedBuffer: unmap the device address obtained through the
MapSharedBuffer().
We're free to extend the protocol structure without changing the protocol
GUID, or bumping any protocol version fields (of which we currently have
none), because VIRTIO_DEVICE_PROTOCOL is internal to edk2 by design --
see the disclaimers in "VirtioDevice.h".
Song, BinX [Mon, 21 Aug 2017 08:44:58 +0000 (16:44 +0800)]
IntelFsp2Pkg: Fix build error with WHOLEARCHIVE option
Add empty TempRamInitApi function to fix
build error with WHOLEARCHIVE option
Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Bell Song <binx.song@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Liming Gao [Wed, 23 Aug 2017 08:04:04 +0000 (16:04 +0800)]
BaseTools: Add the missing -pie link option in GCC tool chain
https://bugzilla.tianocore.org/show_bug.cgi?id=671
GCC tool chain uses -fpie in CC_FLAGS. So, add -pie in DLINK_FLAGS.
More discussion in
https://lists.01.org/pipermail/edk2-devel/2017-August/013508.html
3.13 Options for Linking
========================
'-pie'
Produce a position independent executable on targets that support
it. For predictable results, you must also specify the same set
of options used for compilation ('-fpie', '-fPIE', or model
suboptions) when you specify this linker option.
3.18 Options for Code Generation Conventions
============================================
'-fpie'
'-fPIE'
These options are similar to '-fpic' and '-fPIC', but generated
position independent code can be only linked into executables.
Usually these options are used when '-pie' GCC option is used
during linking.
'-fpie' and '-fPIE' both define the macros '__pie__' and
'__PIE__'. The macros have the value 1 for '-fpie' and 2 for
'-fPIE'.
Leif Lindholm [Thu, 24 Aug 2017 16:20:04 +0000 (17:20 +0100)]
ArmVirtPkg: drop unused Pcds from ArmVirt.dsc.inc
A block of settings has been copied around ARM platforms for years.
These are consumed only by Ebl, and since none of the ArmVirtPkg
platforms use that, drop them.
Ard Biesheuvel [Thu, 24 Aug 2017 16:57:05 +0000 (17:57 +0100)]
ArmPkg/ArmDmaLib: remove dependency on UncachedMemoryAllocationLib
Now that ArmDmaLib no longer uses uncached mappings for short-lived
bounce buffers used for streaming DMA, the only place we allocate
uncached memory is in DmaAllocateBuffer (), which is used for static
mappings shared between the host and the device, e.g., for packet
descriptor rings etc.
There is no performance concern around such long lived mappings, and
so we can really do without the overhead of UncachedMemoryAllocationLib,
which is a sizable chunk of poorly maintained code that never actually
releases any memory, and despite the fact that it implements pool based
routines, it always performs page based allocations anyway.
So let's invoke the DXE services directly to manage memory attributes
on allocations, and keep track of the allocations in a linked list so
we can restore the attributes and free the memory properly after use.
Ard Biesheuvel [Tue, 22 Aug 2017 16:30:13 +0000 (17:30 +0100)]
ArmVirtPkg: remove QemuVideoDxe from ArmVirtQemu and ArmVirtQemuKernel
One of the reasons for introducing virtio-gpu support to OvmfPkg and
ArmVirtpkg was the fact that under KVM virtualization on ARM, the
legacy VGA cannot be used reliably. This is due to an implementation
detail of QEMU+KVM, which remaps cached host memory into the guest
address space as a framebuffer behind a PCI BAR. Given that the purpose
of a memory mapped framebuffer is its side effects, such BARs should
never be mapped cacheable in the guest, and the mismatched attributes
between host and guest result in a loss of coherency, visible as
corruption in the framebuffer image.
This issue does not occur under TCG emulation, nor did we expect it to
actually bring down the guest under KVM, and so it was deemed harmless
to keep support for the VGA device as well. However, as it turns out,
the fact that the framebuffer BAR is mapped using device semantics by
default may result in unalignment faults when we use the ordinary string
copy routines on the contents. In theory, we could work around this by
remapping the BAR as write combining, but it appears the generic PCI
bus driver does not actually implement this.
So let's remove the QemuVideoDxe driver altogether. This may result
in loss of functionality for use cases that rely on the framebuffer
to be directly addressable (such as EFIFB), but given that this never
worked reliably under KVM in the first place, let's not let that stop
us from dropping support for it.
Liming Gao [Tue, 22 Aug 2017 05:58:57 +0000 (13:58 +0800)]
BaseTools: Roll back GenFw Change to keep unknown field in RSDS debug entry
https://lists.01.org/pipermail/edk2-devel/2017-August/013488.html
These fields are actually a GUID and DWORD respectively: the GUID identifies
the PDB to make it possible to verify that a given PDB matches the PE file,
and the DWORD is the "age" of the PDB which is simply a helper value that is
incremented by 1 by the linker every time the file is remade. Wiping the
GUID will cause PDB parsers (such as the MS DIA SDK that IDA and most other
tools use) to treat the PDB as a mismatch and refuse to load it.
Jun Nie [Thu, 17 Aug 2017 12:58:59 +0000 (20:58 +0800)]
EmbeddedPkg/AndroidBoot: boot android kernel from storage
Add an android kernel loader that could load kernel from storage
device.
This android boot image BDS add addtitional cmdline/dtb/ramfs
support besides kernel that is introduced by Android boot header.
This patch is derived from Haojian's code as below link.
https://patches.linaro.org/patch/94683/
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jun Nie <jun.nie@linaro.org> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Laszlo Ersek [Fri, 18 Aug 2017 02:30:40 +0000 (04:30 +0200)]
MdeModulePkg/ScsiBusDxe: don't produce ScsiIo for nonexistent LUNs, part 2
The SPC-4 says about INQUIRY,
> In response to an INQUIRY command received by an incorrect logical unit,
> the SCSI target device shall return the INQUIRY data with the peripheral
> qualifier set to the value defined in 6.4.2. The INQUIRY command shall
> return CHECK CONDITION status only when the device server is unable to
> return the requested INQUIRY data.
When a device server takes the second branch, and returns CHECK CONDITION
for a nonexistent LUN, the InquiryData structure in the
DiscoverScsiDevice() function remains filled with the original zeros.
DiscoverScsiDevice() then sees zero in both Peripheral_Qualifier and
Peripheral_Type, and therefore ScsiBusDxe produces a ScsiIo protocol
instance with device type zero, for the nonexistent LUN.
Device type zero is EFI_SCSI_TYPE_DISK. Thus ScsiDiskDxe binds the bogus
ScsiIo protocol interface, and produces a similarly bogus BlockIo
interface on top. This ripples up to BDS, where UefiBootManagerLib can
auto-generate bogus UEFI boot options for the nonexistent LUNs.
This has been encountered with QEMU, after commit ded6ddc5a7b9 ("scsi:
clarify sense codes for LUN0 emulation", 2017-08-04). QEMU now answers
INQUIRY commands that were directed to nonexistent LUNs with:
According to SPC-4 "Table 41 -- Sense key descriptions (part 2 of 2)",
ILLEGAL REQUEST is justified when "the command was addressed to an
incorrect logical unit number".
Thus, recognize this kind of answer for nonexistent LUNs.
(
Checking the status fields and the sense data is justified anyway,
according to the documentation of ScsiInquiryCommand():
> @retval EFI_SUCCESS The command was executed
> successfully. See
> HostAdapterStatus,
> TargetStatus, SenseDataLength,
> and SenseData in that order for
> additional status information.
)
Cc: Eric Dong <eric.dong@intel.com> Cc: Feng Tian <feng.tian@intel.com> Cc: Hannes Reinecke <hare@suse.com> Cc: Paolo Bonzini <pbonzini@redhat.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>
Laszlo Ersek [Fri, 18 Aug 2017 02:07:01 +0000 (04:07 +0200)]
MdeModulePkg/ScsiBusDxe: remove redundant "else" after "break" statement
The code after the "if" statement is only reachable if the first branch
with the "break" is not taken. Therefore we can move the "else" branch
after the "if" statement, simplifying the code.
Cc: Eric Dong <eric.dong@intel.com> Cc: Feng Tian <feng.tian@intel.com> Cc: Hannes Reinecke <hare@suse.com> Cc: Paolo Bonzini <pbonzini@redhat.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>
Laszlo Ersek [Fri, 18 Aug 2017 01:22:06 +0000 (03:22 +0200)]
MdeModulePkg/ScsiBusDxe: don't produce ScsiIo for nonexistent LUNs, part 1
The SPC-4 spec says about the INQUIRY data, in "Table 138 -- Peripheral
qualifier":
> Qualifier = 011b The device server is not capable of supporting a
> peripheral device on this logical unit. For this
> peripheral qualifier the peripheral device type shall
> be set to 1Fh. All other peripheral device type values
> are reserved for this peripheral qualifier.
Accordingly, the DiscoverScsiDevice() function returns FALSE if
Peripheral_Qualifier is 3 decimal, but Peripheral_Type differs from 1Fh.
This is a valid sanity check -- such combinations are reserved.
When Peripheral_Qualifier is 3, and Peripheral_Type is 1Fh, then
DiscoverScsiDevice() returns TRUE. While this combination is not reserved,
returning TRUE for it is incorrect: Peripheral_Type 1Fh stands for
"Unknown or no device type", and this combination is returned in
particular when the INQUIRY command was directed to a nonexistent LUN.
Quoting the spec:
> In response to an INQUIRY command received by an incorrect logical unit,
> the SCSI target device shall return the INQUIRY data with the peripheral
> qualifier set to the value defined in 6.4.2. [...]
>
> [...]
>
> The PERIPHERAL QUALIFIER field and PERIPHERAL DEVICE TYPE field identify
> the peripheral device connected to the logical unit. If the SCSI target
> device is not capable of supporting a peripheral device connected to
> this logical unit, the device server shall set these fields to 7Fh
> (i.e., PERIPHERAL QUALIFIER field set to 011b and PERIPHERAL DEVICE TYPE
> field set to 1Fh).
The consequence of this bug is that for each nonexistent Target/LUN pair,
we produce a useless ScsiIo protocol interface. The internal
"ScsiIoDevice->ScsiDeviceType" field will be set to 0x1f, and it will be
returned to higher-level SCSI drivers when they call
ScsiIo->GetDeviceType().
Given that 0x1f means "Unknown or no device type", no higher-level driver
can ever support it, so these ScsiIo protocol interfaces are useless.
The fix is to return FALSE for the (Peripheral_Qualifier=3,
Peripheral_Type=0x1f) combination. With that however we reject the whole
Peripheral_Qualifier=3 space (justifiedly -- see the definition above),
which lets us simplify the code.
Cc: Eric Dong <eric.dong@intel.com> Cc: Feng Tian <feng.tian@intel.com> Cc: Hannes Reinecke <hare@suse.com> Cc: Paolo Bonzini <pbonzini@redhat.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>
Ard Biesheuvel [Thu, 17 Aug 2017 12:16:58 +0000 (13:16 +0100)]
ArmPkg/ArmDmaLib: use double buffering only for bus master write
The ArmPkg implementation of DmaLib uses double buffering to ensure
that any attempt to perform non-coherent DMA on unaligned buffers cannot
corrupt adjacent unrelated data which happens to share cachelines with
the data we are exchanging with the device.
Such corruption can only occur on bus master write, in which case we have
to invalidate the caches to ensure the CPU will see the data written to
memory by the device. In the bus master read case, we can simply clean
and invalidate at the same time, which may purge unrelated adjacent data
from the caches, but will not corrupt its contents.
Also, this double buffer does not necessarily have to be allocated from
uncached memory: by the same reasoning, we can perform cache invalidation
on an ordinary pool allocation as long as we take the same alignment
constraints into account.
So update our code accordingly: remove double buffering from the bus
master read path, and switch to a pool allocation for the double buffer.
Laszlo Ersek [Wed, 16 Aug 2017 10:45:59 +0000 (12:45 +0200)]
ArmVirtPkg/FdtPL011SerialPortLib: call PL011UartLib in all SerialPortLib APIs
With the SerialDxe change in commit 4cf3f37c87ba ("MdeModulePkg SerialDxe:
Process timeout consistently in SerialRead", 2017-07-18), setting
EFI_SERIAL_INPUT_BUFFER_EMPTY in the "Control" output parameter, in the
GetControl() SerialPortLib function, is no longer a "small optimization".
Namely, due to the SerialDxe change, the GetOneKeyFromSerial() call in
TerminalDxe's TerminalConInTimerHandler() can take very long if the input
queue is empty, even if GetOneKeyFromSerial()'s return value causes the
loop to be exited right after, in the first iteration.
This issue causes a boot hang in ArmVirtQemu: with the input queue empty,
TerminalConInTimerHandler() takes so long to return that, by the time it
returns, there's another execution queued already (due to the associated
timer event being signaled meanwhile). The boot process is stuck in the
timer event handler.
Therefore even the first GetOneKeyFromSerial() iteration must be prevented
in TerminalConInTimerHandler() if the input queue is empty, and that
requires implementing GetControl() for real.
Implement the SetAttributes(), SetControl() and GetControl() APIs (of
SerialPortExtLib origin) in FdtPL011SerialPortLib with calls to matching
PL011UartLib functions. This follows the example of
"ArmPlatformPkg/Library/PL011SerialPortLib" and also matches Star's
original idea under [1].
The patch can be considered a continuation of commit ad7f6bc2e116
("ArmVirtPkg: Use SerialDxe in MdeModulePkg instead of EmbeddedPkg",
2015-11-26), based on the mailing list threads [1] [2] [3].
Laszlo Ersek [Tue, 15 Aug 2017 16:09:57 +0000 (18:09 +0200)]
OvmfPkg/build.sh: select the GCC49 toolchain settings for gcc-7.*
When UefiCpuPkg/MpInitLib is built for X64 with gcc-7, using the DEBUG
build target and the GCC5 toolchain settings, a C-language assignment is
miscompiled such that the initial AP startup hangs in CpuMpPei (X64) or
CpuDxe (Ia32X64). See <https://bugzilla.tianocore.org/show_bug.cgi?id=671>
for a detailed analysis of the symptoms, and for mailing list links.
This issue has been reported several times (one example is
<https://bugzilla.tianocore.org/show_bug.cgi?id=657>). Until we (or the
upstream gcc developers) figure out how to dissuade gcc-7 from the
miscompilation, pick the GCC49 toolchain in "build.sh" for gcc-7.*.
Cc: Alex Williamson <alex.williamson@redhat.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: Jordan Justen <jordan.l.justen@intel.com>
projects / mirror_edk2.git / log