Star Zeng [Thu, 23 Feb 2017 10:16:09 +0000 (18:16 +0800)]
MdeModule PeiCore: Support pre memory page allocation
Support pre memory page allocation.
Support FreePages.
Allocation made prior to permanent memory will be
migrated to permanent memory and the HOB updated.
Star Zeng [Thu, 31 Aug 2017 08:53:16 +0000 (16:53 +0800)]
SourceLevelDebugPkg/DebugCommLibUsb3Pei: Make sure alloc physical mem
PI 1.6 has supported pre permanent memory page allocation,
to make sure the allocated memory is physical memory for DMA,
the patch is to check memory discovered PPI installed or not first
before calling AllocatePages.
Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Hao Wu <hao.a.wu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Hao Wu <hao.a.wu@intel.com>
SourceLevelDebugPkg: Use Pcd for the revision of transfer protocol
V3 changes:
Add detailed description for the usage of the Pcd in package DEC file.
Update the comment for the introduced Pcd in module INF files.
V2 changes:
Instead of using a global variable, use a Pcd for transfer protocol
revision.
Previously, the revision of the debug agent transfer protocol is
reflected by a macro.
This commit introduces a Pcd to reflect the revision in order to avoid the
comparison of two macros, which will generate a constant result detected
by code checkers.
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
VirtioGpuDxe is now IOMMU-clean; it translates system memory addresses to
bus master device addresses. Negotiate VIRTIO_F_IOMMU_PLATFORM in parallel
with VIRTIO_F_VERSION_1. (Note: the VirtIo GPU device, and this driver,
are virtio-1.0 only (a.k.a. "modern-only").)
Laszlo Ersek [Sat, 26 Aug 2017 16:12:15 +0000 (18:12 +0200)]
OvmfPkg/VirtioGpuDxe: map backing store to bus master device address
VirtioGpuDxe is a UEFI Bus driver (not a Device driver). This is because a
UEFI graphics driver is expected to produce its GraphicsOutput protocol
instance(s) on new child handle(s) of the video controller handle, one
child handle (plus GOP) per video output (or, one child handle plus GOP
per combination of multiple video outputs).
In VirtioGpuDxe, we support a single VirtIo GPU head (scanout), namely
head#0. This means that, with regard to a specific VirtIo GPU device, the
driver may be in one of three states, at any time:
[1] VirtioGpuDxe has not bound the device at all,
[2] VirtioGpuDxe has bound the device, but not produced the sole child
handle for head#0,
[3] VirtioGpuDxe has bound the device, and produced the sole child handle
for head#0, with a GOP instance on the child handle.
(Which state the driver is in wrt. a given VirtIo GPU device depends on
the VirtioGpuDriverBindingStart() / VirtioGpuDriverBindingStop()
invocations issued by the ConnectController() / DisconnectController()
boot services. In turn those come from BDS or e.g. the UEFI shell.)
The concept of "current video mode" is technically tied to the GOP (i.e.,
the child handle, state [3] only), not the VirtIo GPU controller handle.
This is why we manage the storage that backs the current video mode in our
EFI_GRAPHICS_OUTPUT_PROTOCOL.SetMode() member implementation.
GopSetMode() is first called *internally*, when we enter state [3] (that
is, when we produce the child handle + GOP on it):
When this happens, we allocate the backing store *without* having a
preexistent backing store (due to no preexistent video mode and GOP).
Skipping VirtIo GPU details not relevant for this patch, we just note that
the backing store is exposed *permanently* to the VirtIo GPU device, with
the RESOURCE_ATTACH_BACKING command.
When external clients call the EFI_GRAPHICS_OUTPUT_PROTOCOL.Blt() member
function -- called GopBlt() in this driver --, in state [3], the function
operates on the backing store, and sends only small messages to the VirtIo
GPU device.
When external clients call GopSetMode() for switching between video modes
-- in state [3] --, then
- a new backing store is allocated and exposed to the device (attached to
a new host-side VirtIo GPU resource),
- head#0 is flipped to the new backing store,
- on success, the ReleaseGopResources() function both detaches the
previous backing store from the VirtIo GPU device, an releases it. The
new backing store address and size are saved in our GOP object. (In
other words, we "commit" to the new video mode.)
When the DisconnectController() boot service asks us to leave state [3] --
we can leave it directly only for state [2] --, then the
ReleaseGopResources() function is called on a different path:
In this case, the backing store being released is still in use (we're not
leaving it for a new mode -- head#0 has not been flipped "away" from it),
so in ReleaseGopResources() we disable head#0 first.
(The ReleaseGopResources() function is called the same way on the error
path in InitVgpuGop(), if the first -- internal -- VgpuGop->Gop.SetMode()
call succeeds, but the rest of InitVgpuGop() fails.)
Based on the above, for IOMMU-compatibility,
- in GopSetMode(), don't just allocate, but also map the backing store of
the nascent video mode to a device address, for bus master common buffer
operation,
- (the VirtioGpuAllocateZeroAndMapBackingStore() helper function
introduced in the last patch takes care of zeroing internally,)
- pass the device address to the VirtIo GPU device in the
RESOURCE_ATTACH_BACKING command,
- if GopSetMode() succeeds, save the mapping token,
- if GopSetMode() fails, don't just free but also unmap the still-born
backing store,
- in ReleaseGopResources(), don't just free but also unmap the backing
store -- which is the previous backing store if we're mode-switching,
and the current backing store if we're leaving state [3].
Finally, ExitBootServices() may be called when the driver is in either
state [1], [2] or [3], wrt. a given VirtIo GPU device. (Of course we are
only notified in states [2] and [3].) If we get the notification in state
[3], then the current video mode's backing store has to be unmapped, but
not released. (We must not change the UEFI memory map.)
Laszlo Ersek [Sat, 26 Aug 2017 20:15:46 +0000 (22:15 +0200)]
OvmfPkg/VirtioGpuDxe: helpers for backing store (de)allocation+(un)mapping
Introduce the VirtioGpuAllocateZeroAndMapBackingStore() and
VirtioGpuUnmapAndFreeBackingStore() helper functions. These functions tie
together the allocation, zeroing and mapping, and unmapping and
deallocation, respectively, of memory that the virtio GPU will permanently
reference after receiving the RESOURCE_ATTACH_BACKING command.
With these functions we can keep the next patch simpler -- the GOP
implementation in "Gop.c" retains its error handling structure, and
remains oblivious to VIRTIO_DEVICE_PROTOCOL and VirtioLib.
Laszlo Ersek [Sat, 26 Aug 2017 17:54:49 +0000 (19:54 +0200)]
OvmfPkg/VirtioGpuDxe: take EFI_PHYSICAL_ADDRESS in ResourceAttachBacking()
The RESOURCE_ATTACH_BACKING virtio GPU command assigns guest-side backing
pages to a host-side resource that was created earlier with the
RESOURCE_CREATE_2D command.
We compose the RESOURCE_ATTACH_BACKING command in the
VirtioGpuResourceAttachBacking() function. Currently this function takes
the parameter
IN VOID *FirstBackingPage
This is only appropriate as long as we pass a (guest-phys) system memory
address to the device. In preparation for a mapped bus master device
address, change the above parameter to
IN EFI_PHYSICAL_ADDRESS BackingStoreDeviceAddress
In order to keep the current call site functional, move the (VOID*) to
(UINTN) conversion out of the function, to the call site.
The "Request.Entry.Addr" field already has type UINT64.
This patch is similar to commit 4b725858de68 ("OvmfPkg/VirtioLib: change
the parameter of VirtioAppendDesc() to UINT64", 2017-08-23).
Laszlo Ersek [Sat, 26 Aug 2017 15:34:51 +0000 (17:34 +0200)]
OvmfPkg/VirtioGpuDxe: map virtio GPU command objects to device addresses
Every virtio GPU command used by VirtioGpuDxe is synchronous and formatted
as a two-descriptor chain: request, response. The internal workhorse
function that all the command-specific functions call for such messaging
is VirtioGpuSendCommand().
In VirtioGpuSendCommand(), map the request from system memory to bus
master device address for BusMasterRead operation, and map the response
from system memory to bus master device address for BusMasterWrite
operation.
Pass the bus master device addresses to VirtioAppendDesc(). (See also
commit 4b725858de68, "OvmfPkg/VirtioLib: change the parameter of
VirtioAppendDesc() to UINT64", 2017-08-23.)
Laszlo Ersek [Sat, 26 Aug 2017 14:00:30 +0000 (16:00 +0200)]
OvmfPkg/VirtioGpuDxe: map VRING for bus master common buffer operation
VirtioGpuDxe uses one virtio ring, for VIRTIO_GPU_CONTROL_QUEUE.
Map it for bus master common buffer operation with VirtioRingMap(), so
that it can be accessed equally by both guest and hypervisor even if an
IOMMU is used. (VirtioRingInit() already allocates the ring suitably for
this, see commit b0338c53297c, "OvmfPkg/VirtioLib: alloc VRING buffer with
AllocateSharedPages()", 2017-08-23).
Pass the resultant translation offset ("RingBaseShift"), from system
memory address to bus master device address, to VIRTIO_SET_QUEUE_ADDRESS.
Unmap the ring in all contexts where the ring becomes unused (these
contexts are mutually exclusive):
- in VirtioGpuInit(): the ring has been mapped, but we cannot complete the
virtio initialization for another reason,
- in VirtioGpuUninit(): the virtio initialization has succeeded, but
VirtioGpuDriverBindingStart() fails for another reason, or
VirtioGpuDriverBindingStop() unbinds the device after use,
- in VirtioGpuExitBoot(): ExitBootServices() is called after
VirtioGpuDriverBindingStart() has successfully bound the device.
(Unmapping the ring does not change the UEFI memory map.)
Laszlo Ersek [Wed, 30 Aug 2017 12:35:58 +0000 (14:35 +0200)]
OvmfPkg/IoMmuDxe: IoMmuAllocateBuffer(): nicer and more informative DEBUGs
Log all relevant IN and IN OUT parameters on entry.
(Note that the HostAddress parameter is IN OUT rather than OUT due to
historical reasons. The "IN EFI_ALLOCATE_TYPE Type" parameter is now to be
ignored, but historically it could be set to AllocateMaxAddress for
example, and for that HostAddress had to be IN OUT.)
When exiting with success, log all relevant OUT parameters (i.e.,
HostAddress). Also log the new (internal) StashBuffer address, on which
IoMmuMap() and IoMmuUnmap() rely on, for BusMasterCommonBuffer operations
(in-place decryption and encryption, respectively).
Laszlo Ersek [Wed, 30 Aug 2017 12:15:30 +0000 (14:15 +0200)]
OvmfPkg/IoMmuDxe: IoMmuUnmap(): clean up DEBUG message
The only important external information for this function, and for the
human looking at the log, is the Mapping input parameter. Log it on entry.
Stop logging the contents of the MAP_INFO structure pointed-to by Mapping.
Thanks to the previous patch, we can now associate IoMmuUnmap() messages
with IoMmuMap() messages -- and thereby with MAP_INFO contents -- purely
via Mapping.
Laszlo Ersek [Wed, 30 Aug 2017 12:00:58 +0000 (14:00 +0200)]
OvmfPkg/IoMmuDxe: IoMmuMap(): log nicer and more informative DEBUG msgs
Log all relevant IN and IN OUT parameters on entry.
When exiting with success, log all relevant OUT and IN OUT parameters.
Don't log OUT and IN OUT parameters that are never set or changed after
entering the function (i.e., *NumberOfBytes).
Laszlo Ersek [Wed, 30 Aug 2017 11:38:52 +0000 (13:38 +0200)]
OvmfPkg/BaseMemEncryptSevLib: clean up upper-case / lower-case in DEBUGs
Debug messages that start as natural (English) language phrases (after the
debug prefix) should uniformly begin with lower-case or upper-case. In
SetMemoryEncDec() we have a mixture now. Stick with lower-case.
(Upper-case is better for full sentences that also end with punctuation.)
Laszlo Ersek [Wed, 30 Aug 2017 11:31:30 +0000 (13:31 +0200)]
OvmfPkg/BaseMemEncryptSevLib: promote DEBUG_WARN levels to DEBUG_ERROR
In SetMemoryEncDec(), we have four locations where we (a) log a message on
the DEBUG_WARN level that says "ERROR", (b) return the status code
RETURN_NO_MAPPING right after.
These messages clearly describe actual errors (bad PML4, PDPE, PDE, PTE).
Promote their debug levels to DEBUG_ERROR, and remove the word "ERROR"
from the messages.
Laszlo Ersek [Wed, 30 Aug 2017 11:08:11 +0000 (13:08 +0200)]
OvmfPkg/BaseMemEncryptSevLib: break DEBUG calls to multiple lines
None of the DEBUG macro invocations in SetMemoryEncDec() fit on a single
line. Break them to multiple lines, for (a) conforming to the coding style
spec, (b) easier modification in later patches.
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".
projects / mirror_edk2.git / log