audk/SourceLevelDebugPkg/Library/DebugCommunicationLibUsb3/DebugCommunicationLibUsb3Pei.c

275 lines
7.4 KiB
C
Raw Normal View History

/** @file
Debug Port Library implementation based on usb3 debug port.
SourceLevelDebugPkg DebugUsb3: Re-Support IOMMU de8373fa07f87ca735139bb86c51e2c29fb1d956 could not handle two cases. 1. For the case that the USB3 debug port instance and DMA buffers are from PEI HOB with IOMMU enabled, it was to reallocate the DMA buffers by AllocateAddress with the memory type accessible by SMM environment. But reallocating the DMA buffers by AllocateAddress may fail. 2. At S3 resume, after the code is transferred to PiSmmCpuDxeSmm from S3Resume2Pei, HOB is still needed to be used for DMA operation, but PiSmmCpuDxeSmm has no way to get the HOB at S3 resume. The patch is to re-support IOMMU. For PEI, allocate granted DMA buffer from IOMMU PPI, register IOMMU PPI notification to reinitialize hardware with granted DMA buffer if IOMMU PPI is not present yet. For DXE, map DMA buffer by PciIo in PciIo notification for early DXE, and register DxeSmmReadyToLock notification to reinitialize hardware with granted DXE DMA buffer accessible by SMM environment for late DXE. DebugAgentLib has been managing the instance as Handle in HOB/SystemTable. The Handle(instance) from DebugAgentLib can be used directly in DebugCommunicationLibUsb3. Then DebugCommunicationLibUsb3 could get consistent Handle(instance) from DebugAgentLib. 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>
2018-03-14 10:12:22 +01:00
Copyright (c) 2014 - 2018, Intel Corporation. All rights reserved.<BR>
SPDX-License-Identifier: BSD-2-Clause-Patent
**/
#include <PiPei.h>
#include <Library/PeiServicesLib.h>
SourceLevelDebugPkg DebugUsb3: Re-Support IOMMU de8373fa07f87ca735139bb86c51e2c29fb1d956 could not handle two cases. 1. For the case that the USB3 debug port instance and DMA buffers are from PEI HOB with IOMMU enabled, it was to reallocate the DMA buffers by AllocateAddress with the memory type accessible by SMM environment. But reallocating the DMA buffers by AllocateAddress may fail. 2. At S3 resume, after the code is transferred to PiSmmCpuDxeSmm from S3Resume2Pei, HOB is still needed to be used for DMA operation, but PiSmmCpuDxeSmm has no way to get the HOB at S3 resume. The patch is to re-support IOMMU. For PEI, allocate granted DMA buffer from IOMMU PPI, register IOMMU PPI notification to reinitialize hardware with granted DMA buffer if IOMMU PPI is not present yet. For DXE, map DMA buffer by PciIo in PciIo notification for early DXE, and register DxeSmmReadyToLock notification to reinitialize hardware with granted DXE DMA buffer accessible by SMM environment for late DXE. DebugAgentLib has been managing the instance as Handle in HOB/SystemTable. The Handle(instance) from DebugAgentLib can be used directly in DebugCommunicationLibUsb3. Then DebugCommunicationLibUsb3 could get consistent Handle(instance) from DebugAgentLib. 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>
2018-03-14 10:12:22 +01:00
#include <Library/HobLib.h>
#include <Ppi/MemoryDiscovered.h>
SourceLevelDebugPkg DebugUsb3: Re-Support IOMMU de8373fa07f87ca735139bb86c51e2c29fb1d956 could not handle two cases. 1. For the case that the USB3 debug port instance and DMA buffers are from PEI HOB with IOMMU enabled, it was to reallocate the DMA buffers by AllocateAddress with the memory type accessible by SMM environment. But reallocating the DMA buffers by AllocateAddress may fail. 2. At S3 resume, after the code is transferred to PiSmmCpuDxeSmm from S3Resume2Pei, HOB is still needed to be used for DMA operation, but PiSmmCpuDxeSmm has no way to get the HOB at S3 resume. The patch is to re-support IOMMU. For PEI, allocate granted DMA buffer from IOMMU PPI, register IOMMU PPI notification to reinitialize hardware with granted DMA buffer if IOMMU PPI is not present yet. For DXE, map DMA buffer by PciIo in PciIo notification for early DXE, and register DxeSmmReadyToLock notification to reinitialize hardware with granted DXE DMA buffer accessible by SMM environment for late DXE. DebugAgentLib has been managing the instance as Handle in HOB/SystemTable. The Handle(instance) from DebugAgentLib can be used directly in DebugCommunicationLibUsb3. Then DebugCommunicationLibUsb3 could get consistent Handle(instance) from DebugAgentLib. 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>
2018-03-14 10:12:22 +01:00
#include <Ppi/IoMmu.h>
#include "DebugCommunicationLibUsb3Internal.h"
GUID gUsb3DbgGuid = USB3_DBG_GUID;
SourceLevelDebugPkg DebugUsb3: Re-Support IOMMU de8373fa07f87ca735139bb86c51e2c29fb1d956 could not handle two cases. 1. For the case that the USB3 debug port instance and DMA buffers are from PEI HOB with IOMMU enabled, it was to reallocate the DMA buffers by AllocateAddress with the memory type accessible by SMM environment. But reallocating the DMA buffers by AllocateAddress may fail. 2. At S3 resume, after the code is transferred to PiSmmCpuDxeSmm from S3Resume2Pei, HOB is still needed to be used for DMA operation, but PiSmmCpuDxeSmm has no way to get the HOB at S3 resume. The patch is to re-support IOMMU. For PEI, allocate granted DMA buffer from IOMMU PPI, register IOMMU PPI notification to reinitialize hardware with granted DMA buffer if IOMMU PPI is not present yet. For DXE, map DMA buffer by PciIo in PciIo notification for early DXE, and register DxeSmmReadyToLock notification to reinitialize hardware with granted DXE DMA buffer accessible by SMM environment for late DXE. DebugAgentLib has been managing the instance as Handle in HOB/SystemTable. The Handle(instance) from DebugAgentLib can be used directly in DebugCommunicationLibUsb3. Then DebugCommunicationLibUsb3 could get consistent Handle(instance) from DebugAgentLib. 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>
2018-03-14 10:12:22 +01:00
/**
USB3 IOMMU PPI notify.
@param[in] PeiServices Pointer to PEI Services Table.
@param[in] NotifyDesc Pointer to the descriptor for the Notification event that
caused this function to execute.
@param[in] Ppi Pointer to the PPI data associated with this function.
@retval EFI_STATUS Always return EFI_SUCCESS
**/
EFI_STATUS
EFIAPI
Usb3IoMmuPpiNotify (
IN EFI_PEI_SERVICES **PeiServices,
IN EFI_PEI_NOTIFY_DESCRIPTOR *NotifyDesc,
IN VOID *Ppi
)
{
USB3_DEBUG_PORT_HANDLE *Instance;
SourceLevelDebugPkg DebugUsb3: Re-Support IOMMU de8373fa07f87ca735139bb86c51e2c29fb1d956 could not handle two cases. 1. For the case that the USB3 debug port instance and DMA buffers are from PEI HOB with IOMMU enabled, it was to reallocate the DMA buffers by AllocateAddress with the memory type accessible by SMM environment. But reallocating the DMA buffers by AllocateAddress may fail. 2. At S3 resume, after the code is transferred to PiSmmCpuDxeSmm from S3Resume2Pei, HOB is still needed to be used for DMA operation, but PiSmmCpuDxeSmm has no way to get the HOB at S3 resume. The patch is to re-support IOMMU. For PEI, allocate granted DMA buffer from IOMMU PPI, register IOMMU PPI notification to reinitialize hardware with granted DMA buffer if IOMMU PPI is not present yet. For DXE, map DMA buffer by PciIo in PciIo notification for early DXE, and register DxeSmmReadyToLock notification to reinitialize hardware with granted DXE DMA buffer accessible by SMM environment for late DXE. DebugAgentLib has been managing the instance as Handle in HOB/SystemTable. The Handle(instance) from DebugAgentLib can be used directly in DebugCommunicationLibUsb3. Then DebugCommunicationLibUsb3 could get consistent Handle(instance) from DebugAgentLib. 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>
2018-03-14 10:12:22 +01:00
DEBUG ((DEBUG_INFO, "%a()\n", __FUNCTION__));
Instance = GetUsb3DebugPortInstance ();
ASSERT (Instance != NULL);
if (!Instance->Ready) {
return EFI_SUCCESS;
}
Instance->InNotify = TRUE;
//
// Reinitialize USB3 debug port with granted DMA buffer from IOMMU PPI.
//
InitializeUsbDebugHardware (Instance);
//
// Wait some time for host to be ready after re-initialization.
//
MicroSecondDelay (1000000);
Instance->InNotify = FALSE;
return EFI_SUCCESS;
}
EFI_PEI_NOTIFY_DESCRIPTOR mUsb3IoMmuPpiNotifyDesc = {
SourceLevelDebugPkg DebugUsb3: Re-Support IOMMU de8373fa07f87ca735139bb86c51e2c29fb1d956 could not handle two cases. 1. For the case that the USB3 debug port instance and DMA buffers are from PEI HOB with IOMMU enabled, it was to reallocate the DMA buffers by AllocateAddress with the memory type accessible by SMM environment. But reallocating the DMA buffers by AllocateAddress may fail. 2. At S3 resume, after the code is transferred to PiSmmCpuDxeSmm from S3Resume2Pei, HOB is still needed to be used for DMA operation, but PiSmmCpuDxeSmm has no way to get the HOB at S3 resume. The patch is to re-support IOMMU. For PEI, allocate granted DMA buffer from IOMMU PPI, register IOMMU PPI notification to reinitialize hardware with granted DMA buffer if IOMMU PPI is not present yet. For DXE, map DMA buffer by PciIo in PciIo notification for early DXE, and register DxeSmmReadyToLock notification to reinitialize hardware with granted DXE DMA buffer accessible by SMM environment for late DXE. DebugAgentLib has been managing the instance as Handle in HOB/SystemTable. The Handle(instance) from DebugAgentLib can be used directly in DebugCommunicationLibUsb3. Then DebugCommunicationLibUsb3 could get consistent Handle(instance) from DebugAgentLib. 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>
2018-03-14 10:12:22 +01:00
(EFI_PEI_PPI_DESCRIPTOR_NOTIFY_CALLBACK | EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST),
&gEdkiiIoMmuPpiGuid,
Usb3IoMmuPpiNotify
};
/**
Allocates pages that are suitable for an OperationBusMasterCommonBuffer or
OperationBusMasterCommonBuffer64 mapping.
@param IoMmu Pointer to IOMMU PPI.
@param Pages The number of pages to allocate.
@param HostAddress A pointer to store the base system memory address of the
allocated range.
@param DeviceAddress The resulting map address for the bus master PCI controller to use to
access the hosts HostAddress.
@param Mapping A resulting value to pass to Unmap().
@retval EFI_SUCCESS The requested memory pages were allocated.
@retval EFI_UNSUPPORTED Attributes is unsupported. The only legal attribute bits are
MEMORY_WRITE_COMBINE and MEMORY_CACHED.
@retval EFI_INVALID_PARAMETER One or more parameters are invalid.
@retval EFI_OUT_OF_RESOURCES The memory pages could not be allocated.
**/
EFI_STATUS
IoMmuAllocateBuffer (
IN EDKII_IOMMU_PPI *IoMmu,
IN UINTN Pages,
OUT VOID **HostAddress,
OUT EFI_PHYSICAL_ADDRESS *DeviceAddress,
OUT VOID **Mapping
)
{
EFI_STATUS Status;
UINTN NumberOfBytes;
SourceLevelDebugPkg DebugUsb3: Re-Support IOMMU de8373fa07f87ca735139bb86c51e2c29fb1d956 could not handle two cases. 1. For the case that the USB3 debug port instance and DMA buffers are from PEI HOB with IOMMU enabled, it was to reallocate the DMA buffers by AllocateAddress with the memory type accessible by SMM environment. But reallocating the DMA buffers by AllocateAddress may fail. 2. At S3 resume, after the code is transferred to PiSmmCpuDxeSmm from S3Resume2Pei, HOB is still needed to be used for DMA operation, but PiSmmCpuDxeSmm has no way to get the HOB at S3 resume. The patch is to re-support IOMMU. For PEI, allocate granted DMA buffer from IOMMU PPI, register IOMMU PPI notification to reinitialize hardware with granted DMA buffer if IOMMU PPI is not present yet. For DXE, map DMA buffer by PciIo in PciIo notification for early DXE, and register DxeSmmReadyToLock notification to reinitialize hardware with granted DXE DMA buffer accessible by SMM environment for late DXE. DebugAgentLib has been managing the instance as Handle in HOB/SystemTable. The Handle(instance) from DebugAgentLib can be used directly in DebugCommunicationLibUsb3. Then DebugCommunicationLibUsb3 could get consistent Handle(instance) from DebugAgentLib. 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>
2018-03-14 10:12:22 +01:00
*HostAddress = NULL;
SourceLevelDebugPkg DebugUsb3: Re-Support IOMMU de8373fa07f87ca735139bb86c51e2c29fb1d956 could not handle two cases. 1. For the case that the USB3 debug port instance and DMA buffers are from PEI HOB with IOMMU enabled, it was to reallocate the DMA buffers by AllocateAddress with the memory type accessible by SMM environment. But reallocating the DMA buffers by AllocateAddress may fail. 2. At S3 resume, after the code is transferred to PiSmmCpuDxeSmm from S3Resume2Pei, HOB is still needed to be used for DMA operation, but PiSmmCpuDxeSmm has no way to get the HOB at S3 resume. The patch is to re-support IOMMU. For PEI, allocate granted DMA buffer from IOMMU PPI, register IOMMU PPI notification to reinitialize hardware with granted DMA buffer if IOMMU PPI is not present yet. For DXE, map DMA buffer by PciIo in PciIo notification for early DXE, and register DxeSmmReadyToLock notification to reinitialize hardware with granted DXE DMA buffer accessible by SMM environment for late DXE. DebugAgentLib has been managing the instance as Handle in HOB/SystemTable. The Handle(instance) from DebugAgentLib can be used directly in DebugCommunicationLibUsb3. Then DebugCommunicationLibUsb3 could get consistent Handle(instance) from DebugAgentLib. 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>
2018-03-14 10:12:22 +01:00
*DeviceAddress = 0;
*Mapping = NULL;
SourceLevelDebugPkg DebugUsb3: Re-Support IOMMU de8373fa07f87ca735139bb86c51e2c29fb1d956 could not handle two cases. 1. For the case that the USB3 debug port instance and DMA buffers are from PEI HOB with IOMMU enabled, it was to reallocate the DMA buffers by AllocateAddress with the memory type accessible by SMM environment. But reallocating the DMA buffers by AllocateAddress may fail. 2. At S3 resume, after the code is transferred to PiSmmCpuDxeSmm from S3Resume2Pei, HOB is still needed to be used for DMA operation, but PiSmmCpuDxeSmm has no way to get the HOB at S3 resume. The patch is to re-support IOMMU. For PEI, allocate granted DMA buffer from IOMMU PPI, register IOMMU PPI notification to reinitialize hardware with granted DMA buffer if IOMMU PPI is not present yet. For DXE, map DMA buffer by PciIo in PciIo notification for early DXE, and register DxeSmmReadyToLock notification to reinitialize hardware with granted DXE DMA buffer accessible by SMM environment for late DXE. DebugAgentLib has been managing the instance as Handle in HOB/SystemTable. The Handle(instance) from DebugAgentLib can be used directly in DebugCommunicationLibUsb3. Then DebugCommunicationLibUsb3 could get consistent Handle(instance) from DebugAgentLib. 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>
2018-03-14 10:12:22 +01:00
Status = IoMmu->AllocateBuffer (
IoMmu,
EfiRuntimeServicesData,
Pages,
HostAddress,
0
);
if (EFI_ERROR (Status)) {
return EFI_OUT_OF_RESOURCES;
}
NumberOfBytes = EFI_PAGES_TO_SIZE (Pages);
Status = IoMmu->Map (
IoMmu,
EdkiiIoMmuOperationBusMasterCommonBuffer,
*HostAddress,
&NumberOfBytes,
DeviceAddress,
Mapping
);
SourceLevelDebugPkg DebugUsb3: Re-Support IOMMU de8373fa07f87ca735139bb86c51e2c29fb1d956 could not handle two cases. 1. For the case that the USB3 debug port instance and DMA buffers are from PEI HOB with IOMMU enabled, it was to reallocate the DMA buffers by AllocateAddress with the memory type accessible by SMM environment. But reallocating the DMA buffers by AllocateAddress may fail. 2. At S3 resume, after the code is transferred to PiSmmCpuDxeSmm from S3Resume2Pei, HOB is still needed to be used for DMA operation, but PiSmmCpuDxeSmm has no way to get the HOB at S3 resume. The patch is to re-support IOMMU. For PEI, allocate granted DMA buffer from IOMMU PPI, register IOMMU PPI notification to reinitialize hardware with granted DMA buffer if IOMMU PPI is not present yet. For DXE, map DMA buffer by PciIo in PciIo notification for early DXE, and register DxeSmmReadyToLock notification to reinitialize hardware with granted DXE DMA buffer accessible by SMM environment for late DXE. DebugAgentLib has been managing the instance as Handle in HOB/SystemTable. The Handle(instance) from DebugAgentLib can be used directly in DebugCommunicationLibUsb3. Then DebugCommunicationLibUsb3 could get consistent Handle(instance) from DebugAgentLib. 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>
2018-03-14 10:12:22 +01:00
if (EFI_ERROR (Status)) {
IoMmu->FreeBuffer (IoMmu, Pages, *HostAddress);
*HostAddress = NULL;
return EFI_OUT_OF_RESOURCES;
}
SourceLevelDebugPkg DebugUsb3: Re-Support IOMMU de8373fa07f87ca735139bb86c51e2c29fb1d956 could not handle two cases. 1. For the case that the USB3 debug port instance and DMA buffers are from PEI HOB with IOMMU enabled, it was to reallocate the DMA buffers by AllocateAddress with the memory type accessible by SMM environment. But reallocating the DMA buffers by AllocateAddress may fail. 2. At S3 resume, after the code is transferred to PiSmmCpuDxeSmm from S3Resume2Pei, HOB is still needed to be used for DMA operation, but PiSmmCpuDxeSmm has no way to get the HOB at S3 resume. The patch is to re-support IOMMU. For PEI, allocate granted DMA buffer from IOMMU PPI, register IOMMU PPI notification to reinitialize hardware with granted DMA buffer if IOMMU PPI is not present yet. For DXE, map DMA buffer by PciIo in PciIo notification for early DXE, and register DxeSmmReadyToLock notification to reinitialize hardware with granted DXE DMA buffer accessible by SMM environment for late DXE. DebugAgentLib has been managing the instance as Handle in HOB/SystemTable. The Handle(instance) from DebugAgentLib can be used directly in DebugCommunicationLibUsb3. Then DebugCommunicationLibUsb3 could get consistent Handle(instance) from DebugAgentLib. 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>
2018-03-14 10:12:22 +01:00
Status = IoMmu->SetAttribute (
IoMmu,
*Mapping,
EDKII_IOMMU_ACCESS_READ | EDKII_IOMMU_ACCESS_WRITE
);
if (EFI_ERROR (Status)) {
IoMmu->Unmap (IoMmu, *Mapping);
IoMmu->FreeBuffer (IoMmu, Pages, *HostAddress);
*Mapping = NULL;
SourceLevelDebugPkg DebugUsb3: Re-Support IOMMU de8373fa07f87ca735139bb86c51e2c29fb1d956 could not handle two cases. 1. For the case that the USB3 debug port instance and DMA buffers are from PEI HOB with IOMMU enabled, it was to reallocate the DMA buffers by AllocateAddress with the memory type accessible by SMM environment. But reallocating the DMA buffers by AllocateAddress may fail. 2. At S3 resume, after the code is transferred to PiSmmCpuDxeSmm from S3Resume2Pei, HOB is still needed to be used for DMA operation, but PiSmmCpuDxeSmm has no way to get the HOB at S3 resume. The patch is to re-support IOMMU. For PEI, allocate granted DMA buffer from IOMMU PPI, register IOMMU PPI notification to reinitialize hardware with granted DMA buffer if IOMMU PPI is not present yet. For DXE, map DMA buffer by PciIo in PciIo notification for early DXE, and register DxeSmmReadyToLock notification to reinitialize hardware with granted DXE DMA buffer accessible by SMM environment for late DXE. DebugAgentLib has been managing the instance as Handle in HOB/SystemTable. The Handle(instance) from DebugAgentLib can be used directly in DebugCommunicationLibUsb3. Then DebugCommunicationLibUsb3 could get consistent Handle(instance) from DebugAgentLib. 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>
2018-03-14 10:12:22 +01:00
*HostAddress = NULL;
return Status;
}
return Status;
}
/**
USB3 get IOMMU PPI.
@return Pointer to IOMMU PPI.
**/
EDKII_IOMMU_PPI *
Usb3GetIoMmu (
VOID
)
{
EFI_STATUS Status;
EDKII_IOMMU_PPI *IoMmu;
SourceLevelDebugPkg DebugUsb3: Re-Support IOMMU de8373fa07f87ca735139bb86c51e2c29fb1d956 could not handle two cases. 1. For the case that the USB3 debug port instance and DMA buffers are from PEI HOB with IOMMU enabled, it was to reallocate the DMA buffers by AllocateAddress with the memory type accessible by SMM environment. But reallocating the DMA buffers by AllocateAddress may fail. 2. At S3 resume, after the code is transferred to PiSmmCpuDxeSmm from S3Resume2Pei, HOB is still needed to be used for DMA operation, but PiSmmCpuDxeSmm has no way to get the HOB at S3 resume. The patch is to re-support IOMMU. For PEI, allocate granted DMA buffer from IOMMU PPI, register IOMMU PPI notification to reinitialize hardware with granted DMA buffer if IOMMU PPI is not present yet. For DXE, map DMA buffer by PciIo in PciIo notification for early DXE, and register DxeSmmReadyToLock notification to reinitialize hardware with granted DXE DMA buffer accessible by SMM environment for late DXE. DebugAgentLib has been managing the instance as Handle in HOB/SystemTable. The Handle(instance) from DebugAgentLib can be used directly in DebugCommunicationLibUsb3. Then DebugCommunicationLibUsb3 could get consistent Handle(instance) from DebugAgentLib. 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>
2018-03-14 10:12:22 +01:00
IoMmu = NULL;
SourceLevelDebugPkg DebugUsb3: Re-Support IOMMU de8373fa07f87ca735139bb86c51e2c29fb1d956 could not handle two cases. 1. For the case that the USB3 debug port instance and DMA buffers are from PEI HOB with IOMMU enabled, it was to reallocate the DMA buffers by AllocateAddress with the memory type accessible by SMM environment. But reallocating the DMA buffers by AllocateAddress may fail. 2. At S3 resume, after the code is transferred to PiSmmCpuDxeSmm from S3Resume2Pei, HOB is still needed to be used for DMA operation, but PiSmmCpuDxeSmm has no way to get the HOB at S3 resume. The patch is to re-support IOMMU. For PEI, allocate granted DMA buffer from IOMMU PPI, register IOMMU PPI notification to reinitialize hardware with granted DMA buffer if IOMMU PPI is not present yet. For DXE, map DMA buffer by PciIo in PciIo notification for early DXE, and register DxeSmmReadyToLock notification to reinitialize hardware with granted DXE DMA buffer accessible by SMM environment for late DXE. DebugAgentLib has been managing the instance as Handle in HOB/SystemTable. The Handle(instance) from DebugAgentLib can be used directly in DebugCommunicationLibUsb3. Then DebugCommunicationLibUsb3 could get consistent Handle(instance) from DebugAgentLib. 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>
2018-03-14 10:12:22 +01:00
Status = PeiServicesLocatePpi (
&gEdkiiIoMmuPpiGuid,
0,
NULL,
(VOID **)&IoMmu
SourceLevelDebugPkg DebugUsb3: Re-Support IOMMU de8373fa07f87ca735139bb86c51e2c29fb1d956 could not handle two cases. 1. For the case that the USB3 debug port instance and DMA buffers are from PEI HOB with IOMMU enabled, it was to reallocate the DMA buffers by AllocateAddress with the memory type accessible by SMM environment. But reallocating the DMA buffers by AllocateAddress may fail. 2. At S3 resume, after the code is transferred to PiSmmCpuDxeSmm from S3Resume2Pei, HOB is still needed to be used for DMA operation, but PiSmmCpuDxeSmm has no way to get the HOB at S3 resume. The patch is to re-support IOMMU. For PEI, allocate granted DMA buffer from IOMMU PPI, register IOMMU PPI notification to reinitialize hardware with granted DMA buffer if IOMMU PPI is not present yet. For DXE, map DMA buffer by PciIo in PciIo notification for early DXE, and register DxeSmmReadyToLock notification to reinitialize hardware with granted DXE DMA buffer accessible by SMM environment for late DXE. DebugAgentLib has been managing the instance as Handle in HOB/SystemTable. The Handle(instance) from DebugAgentLib can be used directly in DebugCommunicationLibUsb3. Then DebugCommunicationLibUsb3 could get consistent Handle(instance) from DebugAgentLib. 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>
2018-03-14 10:12:22 +01:00
);
if (!EFI_ERROR (Status) && (IoMmu != NULL)) {
return IoMmu;
}
return NULL;
}
/**
Return USB3 debug instance address pointer.
**/
SourceLevelDebugPkg DebugUsb3: Re-Support IOMMU de8373fa07f87ca735139bb86c51e2c29fb1d956 could not handle two cases. 1. For the case that the USB3 debug port instance and DMA buffers are from PEI HOB with IOMMU enabled, it was to reallocate the DMA buffers by AllocateAddress with the memory type accessible by SMM environment. But reallocating the DMA buffers by AllocateAddress may fail. 2. At S3 resume, after the code is transferred to PiSmmCpuDxeSmm from S3Resume2Pei, HOB is still needed to be used for DMA operation, but PiSmmCpuDxeSmm has no way to get the HOB at S3 resume. The patch is to re-support IOMMU. For PEI, allocate granted DMA buffer from IOMMU PPI, register IOMMU PPI notification to reinitialize hardware with granted DMA buffer if IOMMU PPI is not present yet. For DXE, map DMA buffer by PciIo in PciIo notification for early DXE, and register DxeSmmReadyToLock notification to reinitialize hardware with granted DXE DMA buffer accessible by SMM environment for late DXE. DebugAgentLib has been managing the instance as Handle in HOB/SystemTable. The Handle(instance) from DebugAgentLib can be used directly in DebugCommunicationLibUsb3. Then DebugCommunicationLibUsb3 could get consistent Handle(instance) from DebugAgentLib. 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>
2018-03-14 10:12:22 +01:00
EFI_PHYSICAL_ADDRESS *
GetUsb3DebugPortInstanceAddrPtr (
VOID
)
{
USB3_DEBUG_PORT_HANDLE *Instance;
EFI_PHYSICAL_ADDRESS *AddrPtr;
EFI_PEI_HOB_POINTERS Hob;
EFI_STATUS Status;
SourceLevelDebugPkg DebugUsb3: Re-Support IOMMU de8373fa07f87ca735139bb86c51e2c29fb1d956 could not handle two cases. 1. For the case that the USB3 debug port instance and DMA buffers are from PEI HOB with IOMMU enabled, it was to reallocate the DMA buffers by AllocateAddress with the memory type accessible by SMM environment. But reallocating the DMA buffers by AllocateAddress may fail. 2. At S3 resume, after the code is transferred to PiSmmCpuDxeSmm from S3Resume2Pei, HOB is still needed to be used for DMA operation, but PiSmmCpuDxeSmm has no way to get the HOB at S3 resume. The patch is to re-support IOMMU. For PEI, allocate granted DMA buffer from IOMMU PPI, register IOMMU PPI notification to reinitialize hardware with granted DMA buffer if IOMMU PPI is not present yet. For DXE, map DMA buffer by PciIo in PciIo notification for early DXE, and register DxeSmmReadyToLock notification to reinitialize hardware with granted DXE DMA buffer accessible by SMM environment for late DXE. DebugAgentLib has been managing the instance as Handle in HOB/SystemTable. The Handle(instance) from DebugAgentLib can be used directly in DebugCommunicationLibUsb3. Then DebugCommunicationLibUsb3 could get consistent Handle(instance) from DebugAgentLib. 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>
2018-03-14 10:12:22 +01:00
Hob.Raw = GetFirstGuidHob (&gUsb3DbgGuid);
if (Hob.Raw == NULL) {
//
// Build HOB for the local instance and the buffer to save instance address pointer.
// Use the local instance in HOB temporarily.
//
AddrPtr = BuildGuidHob (
&gUsb3DbgGuid,
sizeof (EFI_PHYSICAL_ADDRESS) + sizeof (USB3_DEBUG_PORT_HANDLE)
);
ASSERT (AddrPtr != NULL);
ZeroMem (AddrPtr, sizeof (EFI_PHYSICAL_ADDRESS) + sizeof (USB3_DEBUG_PORT_HANDLE));
Instance = (USB3_DEBUG_PORT_HANDLE *)(AddrPtr + 1);
*AddrPtr = (EFI_PHYSICAL_ADDRESS)(UINTN)Instance;
Instance->FromHob = TRUE;
SourceLevelDebugPkg DebugUsb3: Re-Support IOMMU de8373fa07f87ca735139bb86c51e2c29fb1d956 could not handle two cases. 1. For the case that the USB3 debug port instance and DMA buffers are from PEI HOB with IOMMU enabled, it was to reallocate the DMA buffers by AllocateAddress with the memory type accessible by SMM environment. But reallocating the DMA buffers by AllocateAddress may fail. 2. At S3 resume, after the code is transferred to PiSmmCpuDxeSmm from S3Resume2Pei, HOB is still needed to be used for DMA operation, but PiSmmCpuDxeSmm has no way to get the HOB at S3 resume. The patch is to re-support IOMMU. For PEI, allocate granted DMA buffer from IOMMU PPI, register IOMMU PPI notification to reinitialize hardware with granted DMA buffer if IOMMU PPI is not present yet. For DXE, map DMA buffer by PciIo in PciIo notification for early DXE, and register DxeSmmReadyToLock notification to reinitialize hardware with granted DXE DMA buffer accessible by SMM environment for late DXE. DebugAgentLib has been managing the instance as Handle in HOB/SystemTable. The Handle(instance) from DebugAgentLib can be used directly in DebugCommunicationLibUsb3. Then DebugCommunicationLibUsb3 could get consistent Handle(instance) from DebugAgentLib. 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>
2018-03-14 10:12:22 +01:00
Instance->Initialized = USB3DBG_UNINITIALIZED;
if (Usb3GetIoMmu () == NULL) {
Status = PeiServicesNotifyPpi (&mUsb3IoMmuPpiNotifyDesc);
ASSERT_EFI_ERROR (Status);
}
} else {
AddrPtr = GET_GUID_HOB_DATA (Hob.Guid);
}
return AddrPtr;
}
/**
Allocate aligned memory for XHC's usage.
SourceLevelDebugPkg DebugUsb3: Re-Support IOMMU de8373fa07f87ca735139bb86c51e2c29fb1d956 could not handle two cases. 1. For the case that the USB3 debug port instance and DMA buffers are from PEI HOB with IOMMU enabled, it was to reallocate the DMA buffers by AllocateAddress with the memory type accessible by SMM environment. But reallocating the DMA buffers by AllocateAddress may fail. 2. At S3 resume, after the code is transferred to PiSmmCpuDxeSmm from S3Resume2Pei, HOB is still needed to be used for DMA operation, but PiSmmCpuDxeSmm has no way to get the HOB at S3 resume. The patch is to re-support IOMMU. For PEI, allocate granted DMA buffer from IOMMU PPI, register IOMMU PPI notification to reinitialize hardware with granted DMA buffer if IOMMU PPI is not present yet. For DXE, map DMA buffer by PciIo in PciIo notification for early DXE, and register DxeSmmReadyToLock notification to reinitialize hardware with granted DXE DMA buffer accessible by SMM environment for late DXE. DebugAgentLib has been managing the instance as Handle in HOB/SystemTable. The Handle(instance) from DebugAgentLib can be used directly in DebugCommunicationLibUsb3. Then DebugCommunicationLibUsb3 could get consistent Handle(instance) from DebugAgentLib. 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>
2018-03-14 10:12:22 +01:00
@param BufferSize The size, in bytes, of the Buffer.
@return A pointer to the allocated buffer or NULL if allocation fails.
**/
VOID *
AllocateAlignBuffer (
IN UINTN BufferSize
)
{
VOID *Buf;
EFI_PHYSICAL_ADDRESS Address;
EFI_STATUS Status;
VOID *MemoryDiscoveredPpi;
EDKII_IOMMU_PPI *IoMmu;
VOID *HostAddress;
VOID *Mapping;
Buf = NULL;
//
// Make sure the allocated memory is physical memory.
//
Status = PeiServicesLocatePpi (
&gEfiPeiMemoryDiscoveredPpiGuid,
0,
NULL,
(VOID **)&MemoryDiscoveredPpi
);
if (!EFI_ERROR (Status)) {
SourceLevelDebugPkg DebugUsb3: Re-Support IOMMU de8373fa07f87ca735139bb86c51e2c29fb1d956 could not handle two cases. 1. For the case that the USB3 debug port instance and DMA buffers are from PEI HOB with IOMMU enabled, it was to reallocate the DMA buffers by AllocateAddress with the memory type accessible by SMM environment. But reallocating the DMA buffers by AllocateAddress may fail. 2. At S3 resume, after the code is transferred to PiSmmCpuDxeSmm from S3Resume2Pei, HOB is still needed to be used for DMA operation, but PiSmmCpuDxeSmm has no way to get the HOB at S3 resume. The patch is to re-support IOMMU. For PEI, allocate granted DMA buffer from IOMMU PPI, register IOMMU PPI notification to reinitialize hardware with granted DMA buffer if IOMMU PPI is not present yet. For DXE, map DMA buffer by PciIo in PciIo notification for early DXE, and register DxeSmmReadyToLock notification to reinitialize hardware with granted DXE DMA buffer accessible by SMM environment for late DXE. DebugAgentLib has been managing the instance as Handle in HOB/SystemTable. The Handle(instance) from DebugAgentLib can be used directly in DebugCommunicationLibUsb3. Then DebugCommunicationLibUsb3 could get consistent Handle(instance) from DebugAgentLib. 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>
2018-03-14 10:12:22 +01:00
IoMmu = Usb3GetIoMmu ();
if (IoMmu != NULL) {
Status = IoMmuAllocateBuffer (
IoMmu,
EFI_SIZE_TO_PAGES (BufferSize),
&HostAddress,
&Address,
&Mapping
);
if (!EFI_ERROR (Status)) {
ASSERT (Address == ((EFI_PHYSICAL_ADDRESS)(UINTN)HostAddress));
Buf = (VOID *)(UINTN)Address;
SourceLevelDebugPkg DebugUsb3: Re-Support IOMMU de8373fa07f87ca735139bb86c51e2c29fb1d956 could not handle two cases. 1. For the case that the USB3 debug port instance and DMA buffers are from PEI HOB with IOMMU enabled, it was to reallocate the DMA buffers by AllocateAddress with the memory type accessible by SMM environment. But reallocating the DMA buffers by AllocateAddress may fail. 2. At S3 resume, after the code is transferred to PiSmmCpuDxeSmm from S3Resume2Pei, HOB is still needed to be used for DMA operation, but PiSmmCpuDxeSmm has no way to get the HOB at S3 resume. The patch is to re-support IOMMU. For PEI, allocate granted DMA buffer from IOMMU PPI, register IOMMU PPI notification to reinitialize hardware with granted DMA buffer if IOMMU PPI is not present yet. For DXE, map DMA buffer by PciIo in PciIo notification for early DXE, and register DxeSmmReadyToLock notification to reinitialize hardware with granted DXE DMA buffer accessible by SMM environment for late DXE. DebugAgentLib has been managing the instance as Handle in HOB/SystemTable. The Handle(instance) from DebugAgentLib can be used directly in DebugCommunicationLibUsb3. Then DebugCommunicationLibUsb3 could get consistent Handle(instance) from DebugAgentLib. 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>
2018-03-14 10:12:22 +01:00
}
} else {
Status = PeiServicesAllocatePages (
EfiACPIMemoryNVS,
EFI_SIZE_TO_PAGES (BufferSize),
&Address
);
if (!EFI_ERROR (Status)) {
Buf = (VOID *)(UINTN)Address;
SourceLevelDebugPkg DebugUsb3: Re-Support IOMMU de8373fa07f87ca735139bb86c51e2c29fb1d956 could not handle two cases. 1. For the case that the USB3 debug port instance and DMA buffers are from PEI HOB with IOMMU enabled, it was to reallocate the DMA buffers by AllocateAddress with the memory type accessible by SMM environment. But reallocating the DMA buffers by AllocateAddress may fail. 2. At S3 resume, after the code is transferred to PiSmmCpuDxeSmm from S3Resume2Pei, HOB is still needed to be used for DMA operation, but PiSmmCpuDxeSmm has no way to get the HOB at S3 resume. The patch is to re-support IOMMU. For PEI, allocate granted DMA buffer from IOMMU PPI, register IOMMU PPI notification to reinitialize hardware with granted DMA buffer if IOMMU PPI is not present yet. For DXE, map DMA buffer by PciIo in PciIo notification for early DXE, and register DxeSmmReadyToLock notification to reinitialize hardware with granted DXE DMA buffer accessible by SMM environment for late DXE. DebugAgentLib has been managing the instance as Handle in HOB/SystemTable. The Handle(instance) from DebugAgentLib can be used directly in DebugCommunicationLibUsb3. Then DebugCommunicationLibUsb3 could get consistent Handle(instance) from DebugAgentLib. 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>
2018-03-14 10:12:22 +01:00
}
}
}
return Buf;
}