summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2017-09-06MdeModulePkg: Fix GCC build error.Fu Siyuan1-1/+1
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Fu Siyuan <siyuan.fu@intel.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2017-09-06NetworkPkg/Ip6Dxe: fix a bug in IP6 driver for IpSec protocol notify.Fu Siyuan2-18/+14
The IP driver uses EfiCreateProtocolNotifyEvent() to register notify callback function for IpSec protocol, but it didn't notice that the callback will always be executed at least once, even the protocol wasn't in handle database. As a result, the Ip6IpSecProcessPacket() will still always call LocateProtocol() even the IpSec protocol is not installed, which will impact the network performance. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Fu Siyuan <siyuan.fu@intel.com> Reviewed-by: Ye Ting <ting.ye@intel.com>
2017-09-06MdeModulePkg/Ip4Dxe: fix a bug in IP4 driver for IpSec protocol notify.Fu Siyuan2-11/+13
The IP driver uses EfiCreateProtocolNotifyEvent() to register notify callback function for IpSec protocol, but it didn't notice that the callback will always be executed at least once, even the protocol wasn't in handle database. As a result, the Ip4IpSecProcessPacket() will still always call LocateProtocol() even the IpSec protocol is not installed, which will impact the network performance. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Fu Siyuan <siyuan.fu@intel.com> Reviewed-by: Ye Ting <ting.ye@intel.com>
2017-09-06MdePkg/PiMmCis.h: Fix build failure.Eric Dong1-0/+1
Include the missed header file to fix build failure. Cc: Liming Gao <liming.gao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
2017-09-06MdePkg: Add UEFI 2.7 defined GUID and structure for AIP network media type.Wang Fan1-1/+20
Reviewed-by: Fu Siyuan <siyuan.fu@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Wang Fan <fan.wang@intel.com>
2017-09-06IntelSiliconPkg/VTd: improve debug message.Jiewen Yao1-2/+2
Add /n for debug message to make error more readable. Suggested-by: Star Zeng <star.zeng@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
2017-09-06IntelFramdworkModulePkg/LegacyBios: Add IoMmu Support.Jiewen Yao3-1/+73
If IOMMU is enabled, the legacy BIOS need allow the legacy memory access by the legacy device. The legacy memory is below 1M memory and HighPmm memory. Cc: Star Zeng <star.zeng@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
2017-09-06IntelSiliconPkg/Vtd: Support CSM usage.Jiewen Yao2-5/+5
Remove zero address check in IoMmuMap. The reason is that a CSM legacy driver may use legacy memory for DMA. As such, the legacyBios need allow below 1M to the legacy device. This patch also fixed some typo. Cc: Star Zeng <star.zeng@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
2017-09-06MdePkg/PciSegmentLibSegmentInfo: fix typo in PciSegmentBitFieldAnd*()Ruiyu Ni1-3/+3
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2017-09-06MdeModulePkg/UefiBootManagerLib: Generate boot description for SD/eMMCHao Wu2-0/+24
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=620 Adds the support for SD/eMMC device path to show as a boot option. The CID register content (returned from DiskInfo->Inquiry) seems do not provide very useful/readable 'OEM/Application ID' and 'Product name' field. For SD devices, the OID is a 2-character ASCII string and the Product name is a 5-character ASCII string. For eMMC devices, the OID is an 8-bit binary number and the Product name is a 6-character ASCII string. These strings are relatively short and do not provide a very readable description. Hence, this commit uses general 'SD (eMMC) Device' for the boot option description. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
2017-09-05Pkcs7VerifyDxe: Don't allow Pkcs7Verify to install protocols twicePeter Jones1-2/+11
This patch makes Pkcs7VerifyDxe check that it has not already been installed before installing its protocols. This prevents the case where loading it as an external driver (either manually, through Driver#### variables, etc.) will refuse to add a second provider of the API. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Peter Jones <pjones@redhat.com> Reviewed-by: Michael Kinney <michael.d.kinney@intel.com> Reviewed-by: Long Qin <qin.long@intel.com>
2017-09-05SecurityPkg/Pkcs7Verify: Complete the Pkcs7VerifyDxe protocolLong Qin1-3/+376
VerifySignature can be implemented using a mirror of the AuthenticodeVerify function that's already in use in the ImageVerificationDXE environment, so this patch simply wires up VerifySignature using that code. <NOTE: Only Authenticode-signature verification was supported by this VerifySignature() implementation now.) Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> Reviewed-by: Long Qin <qin.long@intel.com>
2017-09-05UefiCpuPkg/Lmce.c Remove useless file.Eric Dong1-97/+0
Merge the code to MachineCheck.c file, remove this file. Cc: Ruiyu Ni <ruiyu.ni@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
2017-09-05UefiCpuPkg: ApicLibLeo Duran2-94/+30
GetProcessorLocationByApicId () - Use max possible thread count to decode InitialApicId on AMD processor. - Clean-up on C Coding standards. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Jeff Fan <jeff.fan@intel.com> Cc: Liming Gao <liming.gao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Leo Duran <leo.duran@amd.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
2017-09-05BaseTools: update help info for -Y option to include 'HASH'Yonghong Zhu1-1/+1
Per build spec,the default set of flags for -Y option include 'HASH', so this patch to update the help info. Cc: Liming Gao <liming.gao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Yonghong Zhu <yonghong.zhu@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
2017-09-04MdePkg PeiMemoryAllocationLib: Update InternalAllocateAlignedPagesStar Zeng1-132/+40
Update InternalAllocateAlignedPages to use PeiServicesFreePages. Let the InternalAllocateAlignedPages in PeiMemoryAllocationLib use same algorithm with InternalAllocateAlignedPages in UefiMemoryAllocationLib. Cc: Liming Gao <liming.gao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
2017-09-04MdePkg PeiMemoryAllocationLib: Update Free(Aligned)PagesStar Zeng1-7/+9
Update Free(Aligned)Pages to use PeiServicesFreePages. Cc: Liming Gao <liming.gao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
2017-09-04MdePkg PeiServicesLib: Add PeiServicesFreePagesStar Zeng2-11/+55
Add PeiServicesFreePages and update comments for PeiServicesAllocatePages. Cc: Liming Gao <liming.gao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
2017-09-04MdeModule PeiCore: Support pre memory page allocationStar Zeng5-53/+646
Support pre memory page allocation. Support FreePages. Allocation made prior to permanent memory will be migrated to permanent memory and the HOB updated. Cc: Liming Gao <liming.gao@intel.com> Cc: Ruiyu Ni <Ruiyu.Ni@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
2017-09-04MdePkg PiPeiCis.h: Add FreePages definitionStar Zeng1-0/+27
Follow PI 1.6 spec to add FreePages definition and comments for AllocatePages that will support pre permanent memory page allocation. Cc: Liming Gao <liming.gao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
2017-09-04SourceLevelDebugPkg/DebugCommLibUsb3: Remove IntelFrameworkPkg.decStar Zeng2-3/+1
Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Hao Wu <hao.a.wu@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Hao Wu <hao.a.wu@intel.com>
2017-09-04SourceLevelDebugPkg/DebugCommLibUsb3Pei: Make sure alloc physical memStar Zeng2-9/+24
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>
2017-09-04SourceLevelDebugPkg: Use Pcd for the revision of transfer protocolHao Wu7-10/+26
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>
2017-09-01OvmfPkg/VirtioGpuDxe: negotiate VIRTIO_F_IOMMU_PLATFORMLaszlo Ersek1-1/+1
VirtioGpuDxe is now IOMMU-clean; it translates system memory addresses to bus master device addresses. Negotiate VIRTIO_F_IOMMU_PLATFORM in parallel with VIRTIO_F_VERSION_1. (Note: the VirtIo GPU device, and this driver, are virtio-1.0 only (a.k.a. "modern-only").) Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com>
2017-09-01OvmfPkg/VirtioGpuDxe: map backing store to bus master device addressLaszlo Ersek3-20/+65
VirtioGpuDxe is a UEFI Bus driver (not a Device driver). This is because a UEFI graphics driver is expected to produce its GraphicsOutput protocol instance(s) on new child handle(s) of the video controller handle, one child handle (plus GOP) per video output (or, one child handle plus GOP per combination of multiple video outputs). In VirtioGpuDxe, we support a single VirtIo GPU head (scanout), namely head#0. This means that, with regard to a specific VirtIo GPU device, the driver may be in one of three states, at any time: [1] VirtioGpuDxe has not bound the device at all, [2] VirtioGpuDxe has bound the device, but not produced the sole child handle for head#0, [3] VirtioGpuDxe has bound the device, and produced the sole child handle for head#0, with a GOP instance on the child handle. (Which state the driver is in wrt. a given VirtIo GPU device depends on the VirtioGpuDriverBindingStart() / VirtioGpuDriverBindingStop() invocations issued by the ConnectController() / DisconnectController() boot services. In turn those come from BDS or e.g. the UEFI shell.) The concept of "current video mode" is technically tied to the GOP (i.e., the child handle, state [3] only), not the VirtIo GPU controller handle. This is why we manage the storage that backs the current video mode in our EFI_GRAPHICS_OUTPUT_PROTOCOL.SetMode() member implementation. GopSetMode() is first called *internally*, when we enter state [3] (that is, when we produce the child handle + GOP on it): VirtioGpuDriverBindingStart() [DriverBinding.c] InitVgpuGop() [DriverBinding.c] VgpuGop->Gop.SetMode() [Gop.c] When this happens, we allocate the backing store *without* having a preexistent backing store (due to no preexistent video mode and GOP). Skipping VirtIo GPU details not relevant for this patch, we just note that the backing store is exposed *permanently* to the VirtIo GPU device, with the RESOURCE_ATTACH_BACKING command. When external clients call the EFI_GRAPHICS_OUTPUT_PROTOCOL.Blt() member function -- called GopBlt() in this driver --, in state [3], the function operates on the backing store, and sends only small messages to the VirtIo GPU device. When external clients call GopSetMode() for switching between video modes -- in state [3] --, then - a new backing store is allocated and exposed to the device (attached to a new host-side VirtIo GPU resource), - head#0 is flipped to the new backing store, - on success, the ReleaseGopResources() function both detaches the previous backing store from the VirtIo GPU device, an releases it. The new backing store address and size are saved in our GOP object. (In other words, we "commit" to the new video mode.) When the DisconnectController() boot service asks us to leave state [3] -- we can leave it directly only for state [2] --, then the ReleaseGopResources() function is called on a different path: VirtioGpuDriverBindingStop() [DriverBinding.c] UninitVgpuGop() [DriverBinding.c] ReleaseGopResources() [Gop.c] In this case, the backing store being released is still in use (we're not leaving it for a new mode -- head#0 has not been flipped "away" from it), so in ReleaseGopResources() we disable head#0 first. (The ReleaseGopResources() function is called the same way on the error path in InitVgpuGop(), if the first -- internal -- VgpuGop->Gop.SetMode() call succeeds, but the rest of InitVgpuGop() fails.) Based on the above, for IOMMU-compatibility, - in GopSetMode(), don't just allocate, but also map the backing store of the nascent video mode to a device address, for bus master common buffer operation, - (the VirtioGpuAllocateZeroAndMapBackingStore() helper function introduced in the last patch takes care of zeroing internally,) - pass the device address to the VirtIo GPU device in the RESOURCE_ATTACH_BACKING command, - if GopSetMode() succeeds, save the mapping token, - if GopSetMode() fails, don't just free but also unmap the still-born backing store, - in ReleaseGopResources(), don't just free but also unmap the backing store -- which is the previous backing store if we're mode-switching, and the current backing store if we're leaving state [3]. Finally, ExitBootServices() may be called when the driver is in either state [1], [2] or [3], wrt. a given VirtIo GPU device. (Of course we are only notified in states [2] and [3].) If we get the notification in state [3], then the current video mode's backing store has to be unmapped, but not released. (We must not change the UEFI memory map.) Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com>
2017-09-01OvmfPkg/VirtioGpuDxe: helpers for backing store (de)allocation+(un)mappingLaszlo Ersek4-2/+188
Introduce the VirtioGpuAllocateZeroAndMapBackingStore() and VirtioGpuUnmapAndFreeBackingStore() helper functions. These functions tie together the allocation, zeroing and mapping, and unmapping and deallocation, respectively, of memory that the virtio GPU will permanently reference after receiving the RESOURCE_ATTACH_BACKING command. With these functions we can keep the next patch simpler -- the GOP implementation in "Gop.c" retains its error handling structure, and remains oblivious to VIRTIO_DEVICE_PROTOCOL and VirtioLib. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com>
2017-09-01OvmfPkg/VirtioGpuDxe: take EFI_PHYSICAL_ADDRESS in ResourceAttachBacking()Laszlo Ersek3-13/+13
The RESOURCE_ATTACH_BACKING virtio GPU command assigns guest-side backing pages to a host-side resource that was created earlier with the RESOURCE_CREATE_2D command. We compose the RESOURCE_ATTACH_BACKING command in the VirtioGpuResourceAttachBacking() function. Currently this function takes the parameter IN VOID *FirstBackingPage This is only appropriate as long as we pass a (guest-phys) system memory address to the device. In preparation for a mapped bus master device address, change the above parameter to IN EFI_PHYSICAL_ADDRESS BackingStoreDeviceAddress In order to keep the current call site functional, move the (VOID*) to (UINTN) conversion out of the function, to the call site. The "Request.Entry.Addr" field already has type UINT64. This patch is similar to commit 4b725858de68 ("OvmfPkg/VirtioLib: change the parameter of VirtioAppendDesc() to UINT64", 2017-08-23). Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com>
2017-09-01OvmfPkg/VirtioGpuDxe: map virtio GPU command objects to device addressesLaszlo Ersek1-8/+75
Every virtio GPU command used by VirtioGpuDxe is synchronous and formatted as a two-descriptor chain: request, response. The internal workhorse function that all the command-specific functions call for such messaging is VirtioGpuSendCommand(). In VirtioGpuSendCommand(), map the request from system memory to bus master device address for BusMasterRead operation, and map the response from system memory to bus master device address for BusMasterWrite operation. Pass the bus master device addresses to VirtioAppendDesc(). (See also commit 4b725858de68, "OvmfPkg/VirtioLib: change the parameter of VirtioAppendDesc() to UINT64", 2017-08-23.) Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com>
2017-09-01OvmfPkg/VirtioGpuDxe: map VRING for bus master common buffer operationLaszlo Ersek2-3/+30
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.) Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com>
2017-09-01OvmfPkg/IoMmuDxe: IoMmuFreeBuffer(): clean up DEBUG messageLaszlo Ersek1-8/+8
Log all relevant IN parameters on entry. (There are only IN parameters.) Beautify the format string. Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com>
2017-09-01OvmfPkg/IoMmuDxe: IoMmuAllocateBuffer(): nicer and more informative DEBUGsLaszlo Ersek1-2/+11
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). Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com>
2017-09-01OvmfPkg/IoMmuDxe: IoMmuUnmap(): clean up DEBUG messageLaszlo Ersek1-10/+2
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. Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com>
2017-09-01OvmfPkg/IoMmuDxe: IoMmuMap(): log nicer and more informative DEBUG msgsLaszlo Ersek1-3/+28
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). Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com>
2017-09-01OvmfPkg/BaseMemEncryptSevLib: fix typos in DEBUG messagesLaszlo Ersek1-2/+2
Replace "spliting" with "splitting". Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com>
2017-09-01OvmfPkg/BaseMemEncryptSevLib: clean up upper-case / lower-case in DEBUGsLaszlo Ersek1-3/+3
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.) Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com>
2017-09-01OvmfPkg/BaseMemEncryptSevLib: promote DEBUG_WARN levels to DEBUG_ERRORLaszlo Ersek1-8/+8
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. Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com>
2017-09-01OvmfPkg/BaseMemEncryptSevLib: clean up debug logging of PhysicalAddressLaszlo Ersek1-8/+9
In the SetMemoryEncDec() function, the way we currently report PhysicalAddress is not uniform: - mostly we say "for %lx", - in one spot we say "at %lx" (even though the 2MB page being split does not live *at* PhysicalAddress, instead it maps PhysicalAddress), - in another spot we don't log PhysicalAddress at all (when splitting a 1GB page). Unify this, using the format string "for Physical=0x%Lx". Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com>
2017-09-01OvmfPkg/BaseMemEncryptSevLib: clean up DEBUG prefixesLaszlo Ersek1-7/+7
The prefix for the SetMemoryEncDec() DEBUG messages should be "ModuleName:FunctionName: " not "ModuleName:FunctionName " Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com>
2017-09-01OvmfPkg/BaseMemEncryptSevLib: break DEBUG calls to multiple linesLaszlo Ersek1-20/+48
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. Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com>
2017-09-01OvmfPkg/BaseMemEncryptSevLib: unify encrypt/decrypt DEBUG messagesLaszlo Ersek1-8/+12
Unify the debug messages between InternalMemEncryptSevSetMemoryEncrypted() and InternalMemEncryptSevSetMemoryDecrypted(). Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Brijesh Singh <brijesh.singh@amd.com> Tested-by: Brijesh Singh <brijesh.singh@amd.com>
2017-09-01ArmPkg: remove ArmDmaLibArd Biesheuvel3-529/+0
Now that we have a generic DmaLib implementation for non-coherent DMA, let's get rid of the ARM specific one. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
2017-09-01EmbeddedPkg: MmcDxe - Recieve response was missing after CMD12Meenakshi Aggarwal1-0/+1
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>
2017-08-31OvmfPkg/VirtioScsiDxe: negotiate VIRTIO_F_IOMMU_PLATFORMBrijesh Singh1-2/+3
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. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com>
2017-08-31OvmfPkg/VirtioScsiDxe: map virtio-scsi request and response buffersBrijesh Singh1-16/+205
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>
2017-08-31OvmfPkg/VirtioScsiDxe: add helper to create a fake host adapter errorBrijesh Singh1-7/+33
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). Suggested-by: Laszlo Ersek <lersek@redhat.com> 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: fix style & typo in ReportHostAdapterError() comment] Reviewed-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com>
2017-08-31OvmfPkg/VirtioScsiDxe: map VRING using VirtioRingMap()Brijesh Singh2-10/+38
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. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com>
2017-08-31ShellBinPkg: AARCH64/ARM Shell binary update.Leif Lindholm4-0/+0
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2017-08-31ArmPkg: remove UncachedMemoryAllocationLibArd Biesheuvel5-1440/+0
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. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
2017-08-31BaseTools/Gcc ARM AARCH64: add support for building device tree binariesArd Biesheuvel2-0/+33
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: DeviceTree.inf: [Defines] INF_VERSION = 0x00010019 BASE_NAME = SomePlatformDeviceTree FILE_GUID = 25462CDA-221F-47DF-AC1D-259CFAA4E326 # gDtPlatformDefaultDtbFileGuid MODULE_TYPE = USER_DEFINED VERSION_STRING = 1.0 [Sources] SomePlatform.dts [Packages] MdePkg/MdePkg.dec SomePlatform.fdf: INF RuleOverride = DTB xxx/yyy/DeviceTree.inf [Rule.Common.USER_DEFINED.DTB] FILE FREEFORM = $(NAMED_GUID) { RAW BIN |.dtb } where it can be picked at runtime by the DTB loader that may refer to it using gDtPlatformDefaultDtbFileGuid. Note that this is very similar to how ACPI tables may be emitted into a FFS file with a known GUID and picked up by AcpiTableDxe at runtime. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org> Reviewed-by: Liming Gao <liming.gao@intel.com>
2017-08-31BaseTools: Enable --whole-archive in GCC tool chain as the default optionLiming Gao1-2/+2
https://bugzilla.tianocore.org/show_bug.cgi?id=581 Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Yonghong Zhu <yonghong.zhu@intel.com>