Re: [edk2] [RFC] [PATCH V4 0/3] Add IOMMU support.

[Yao, Jiewen]

Thanks. I agree.

From: Ni, Ruiyu
Sent: Thursday, May 4, 2017 3:02 PM
To: Yao, Jiewen ; edk2-devel@lists.01.org
Cc: Leo Duran ; Brijesh Singh ; Ard 
Biesheuvel 
Subject: RE: [RFC] [PATCH V4 0/3] Add IOMMU support.

Jiewen,
All 3 patches are good to me.
When you post V5 to retire one of the SetxxxAttribute() interfaces from IO_MMU 
protocol,
I suggest we keep the Mapping version, but rename the function name to 
SetAttribute().
As the 2 changes in below:

typedef
EFI_STATUS
(EFIAPI *EDKII_IOMMU_SET_ATTRIBUTE)( // <-- 1. Remove the _MAPPING
  IN EDKII_IOMMU_PROTOCOL  *This,
  IN EFI_HANDLEDeviceHandle,
  IN VOID  *Mapping,
  IN UINT64IoMmuAccess
  );

///
/// IOMMU Protocol structure.
///
struct _EDKII_IOMMU_PROTOCOL {
  UINT64  Revision;
  EDKII_IOMMU_SET_ATTRIBUTE   SetAttribute;
  EDKII_IOMMU_MAP Map;
  EDKII_IOMMU_UNMAP   Unmap;
  EDKII_IOMMU_ALLOCATE_BUFFER AllocateBuffer;
  EDKII_IOMMU_FREE_BUFFER FreeBuffer;
  // <-- 2. Remove the SetMappingAttribute interface.
};

Thanks/Ray

> -Original Message-
> From: Yao, Jiewen
> Sent: Saturday, April 29, 2017 9:48 PM
> To: edk2-devel@lists.01.org
> Cc: Ni, Ruiyu >; Leo Duran 
> >; Brijesh
> Singh >; Ard Biesheuvel 
> >
> Subject: [RFC] [PATCH V4 0/3] Add IOMMU support.
>
>  V4 ==
> Refine the EDKII_IOMMU_PROTOCOL.
>
> 1) Add AllocateBuffer/FreeBuffer/Map/Unmap() API.
> They are similar to DmaLib in EmbeddedPkg and similar to the previous
> BmDmaLib (by leo.du...@amd.com).
>
> These APIs are invoked by PciHostBridge driver to allocate DMA memory.
>
> The PciHostBridge driver (IOMMU consumer) is simplified:
> It uses IOMMU, if IOMMU protocol is present.
> Else it uses original logic.
>
> 2) Add SetMappingAttribute() API.
> It is similar to SetAttribute() API in V1.
>
> This API is invoked by PciBus driver to set DMA access attribute (read/write) 
> for
> device.
>
> The PciBus driver (IOMMU consumer) is simplified:
> It sets access attribute in Map/Unmap,
> if IOMMU protocol is present.
>
> 3) Remove SetRemapAddress/GetRemapAddress() API.
> Because PciHostBridge/PciBus can call the APIs defined above, there is no need
> to provide remap capability.
>
> -- Sample producer drivers:
> 1) The sample VTd driver (IOMMU producer) is at
> https://github.com/jyao1/edk2/tree/dma_v4/IntelSiliconPkg/IntelVTdDxe
>
> It is added to show the concept. It is not fully implemented yet.
> It will not be checked in in this patch.
>
> 2) The sample AMD SEV driver (IOMMU producer) is at
> https://github.com/jyao1/edk2/tree/dma_v4/IntelSiliconPkg/SampleAmdSevDx
> e
> (code is borrowed from leo.du...@amd.com and 
> brijesh.si...@amd.com)
>
> This is not a right place to put this driver.
>
> It is added to show the concept.
> It is not fully implemented. It will not be checked in.
> Please do not use it directly.
>
> 3) The sample STYX driver (IOMMU producer) is at
> https://github.com/jyao1/edk2/tree/dma_v4/IntelSiliconPkg/SampleStyxDxe
> (code is borrowed from 
> ard.biesheu...@linaro.org)
>
> This is not a right place to put this driver.
>
> It is added to show the concept.
> It is not fully implemented. It will not be checked in.
> Please do not use it directly.
>
>
>  V3 ==
> 1) Add Remap capability (from Ard Biesheuvel) Add
> EDKII_IOMMU_REMAP_ADDRESS API in IOMMU_PROTOCOL.
>
> NOTE: The code is not fully validated yet.
> The purpose is to collect feedback to decide the next step.
>
>  V2 ==
> 1) Enhance Unmap() in PciIo (From Ruiyu Ni) Maintain a local list of MapInfo 
> and
> match it in Unmap.
>
> 2) CopyMem for ReadOperation in PciIo after SetAttribute (Leo Duran) Fix a bug
> in V1 that copy mem for read happen before SetAttribute, which will break AMD
> SEV solution.
>
>  V1 ==
>
> This patch series adds IOMMU protocol and updates the consumer to support
> IOMMU based DMA access in UEFI.
>
> This patch series can support the BmDmaLib request for AMD SEV.
> submitted by Duran, Leo > and 
> Brijesh Singh
> >.
> https://lists.01.org/pipermail/edk2-devel/2017-March/008109.html, and
> https://lists.01.org/pipermail/edk2-devel/2017-March/008820.html.
> We can have an AMD SEV specific IOMMU driver to produce IOMMU protocol,
> and clear SEV in IOMMU->SetAttribute().
>
> This patch series can also 

Re: [edk2] [RFC] [PATCH V4 0/3] Add IOMMU support.

[Ni, Ruiyu]

Jiewen,
All 3 patches are good to me.
When you post V5 to retire one of the SetxxxAttribute() interfaces from IO_MMU 
protocol,
I suggest we keep the Mapping version, but rename the function name to 
SetAttribute().
As the 2 changes in below:

typedef
EFI_STATUS
(EFIAPI *EDKII_IOMMU_SET_ATTRIBUTE)( // <-- 1. Remove the _MAPPING
  IN EDKII_IOMMU_PROTOCOL  *This,
  IN EFI_HANDLEDeviceHandle,
  IN VOID  *Mapping,
  IN UINT64IoMmuAccess
  );

///
/// IOMMU Protocol structure.
///
struct _EDKII_IOMMU_PROTOCOL {
  UINT64  Revision;
  EDKII_IOMMU_SET_ATTRIBUTE   SetAttribute;
  EDKII_IOMMU_MAP Map;
  EDKII_IOMMU_UNMAP   Unmap;
  EDKII_IOMMU_ALLOCATE_BUFFER AllocateBuffer;
  EDKII_IOMMU_FREE_BUFFER FreeBuffer;
  // <-- 2. Remove the SetMappingAttribute interface.
};

Thanks/Ray

> -Original Message-
> From: Yao, Jiewen
> Sent: Saturday, April 29, 2017 9:48 PM
> To: edk2-devel@lists.01.org
> Cc: Ni, Ruiyu ; Leo Duran ; Brijesh
> Singh ; Ard Biesheuvel 
> Subject: [RFC] [PATCH V4 0/3] Add IOMMU support.
> 
>  V4 ==
> Refine the EDKII_IOMMU_PROTOCOL.
> 
> 1) Add AllocateBuffer/FreeBuffer/Map/Unmap() API.
> They are similar to DmaLib in EmbeddedPkg and similar to the previous
> BmDmaLib (by leo.du...@amd.com).
> 
> These APIs are invoked by PciHostBridge driver to allocate DMA memory.
> 
> The PciHostBridge driver (IOMMU consumer) is simplified:
> It uses IOMMU, if IOMMU protocol is present.
> Else it uses original logic.
> 
> 2) Add SetMappingAttribute() API.
> It is similar to SetAttribute() API in V1.
> 
> This API is invoked by PciBus driver to set DMA access attribute (read/write) 
> for
> device.
> 
> The PciBus driver (IOMMU consumer) is simplified:
> It sets access attribute in Map/Unmap,
> if IOMMU protocol is present.
> 
> 3) Remove SetRemapAddress/GetRemapAddress() API.
> Because PciHostBridge/PciBus can call the APIs defined above, there is no need
> to provide remap capability.
> 
> -- Sample producer drivers:
> 1) The sample VTd driver (IOMMU producer) is at
> https://github.com/jyao1/edk2/tree/dma_v4/IntelSiliconPkg/IntelVTdDxe
> 
> It is added to show the concept. It is not fully implemented yet.
> It will not be checked in in this patch.
> 
> 2) The sample AMD SEV driver (IOMMU producer) is at
> https://github.com/jyao1/edk2/tree/dma_v4/IntelSiliconPkg/SampleAmdSevDx
> e
> (code is borrowed from leo.du...@amd.com and brijesh.si...@amd.com)
> 
> This is not a right place to put this driver.
> 
> It is added to show the concept.
> It is not fully implemented. It will not be checked in.
> Please do not use it directly.
> 
> 3) The sample STYX driver (IOMMU producer) is at
> https://github.com/jyao1/edk2/tree/dma_v4/IntelSiliconPkg/SampleStyxDxe
> (code is borrowed from ard.biesheu...@linaro.org)
> 
> This is not a right place to put this driver.
> 
> It is added to show the concept.
> It is not fully implemented. It will not be checked in.
> Please do not use it directly.
> 
> 
>  V3 ==
> 1) Add Remap capability (from Ard Biesheuvel) Add
> EDKII_IOMMU_REMAP_ADDRESS API in IOMMU_PROTOCOL.
> 
> NOTE: The code is not fully validated yet.
> The purpose is to collect feedback to decide the next step.
> 
>  V2 ==
> 1) Enhance Unmap() in PciIo (From Ruiyu Ni) Maintain a local list of MapInfo 
> and
> match it in Unmap.
> 
> 2) CopyMem for ReadOperation in PciIo after SetAttribute (Leo Duran) Fix a bug
> in V1 that copy mem for read happen before SetAttribute, which will break AMD
> SEV solution.
> 
>  V1 ==
> 
> This patch series adds IOMMU protocol and updates the consumer to support
> IOMMU based DMA access in UEFI.
> 
> This patch series can support the BmDmaLib request for AMD SEV.
> submitted by Duran, Leo  and Brijesh Singh
> .
> https://lists.01.org/pipermail/edk2-devel/2017-March/008109.html, and
> https://lists.01.org/pipermail/edk2-devel/2017-March/008820.html.
> We can have an AMD SEV specific IOMMU driver to produce IOMMU protocol,
> and clear SEV in IOMMU->SetAttribute().
> 
> This patch series can also support Intel VTd based DMA protection, requested 
> by
> Jiewen Yao , discussed in
> https://lists.01.org/pipermail/edk2-devel/2017-March/008157.html.
> We can have an Intel VTd specific IOMMU driver to produce IOMMU protocol,
> and update VTd engine to grant or deny access in IOMMU->SetAttribute().
> 
> This patch series does not provide a full Intel VTd driver, which will be 
> provide in
> other patch in the future.
> 
> The purpose of this patch series to review if this IOMMU protocol design can
> meet all DMA access and management requirement.
> 
> Cc: Ruiyu Ni 
> Cc: 

Re: [edk2] [RFC] [PATCH V4 0/3] Add IOMMU support.

[Duran, Leo]

Hi Yao,
We're OK so far (as noted below).
Leo

From: Yao, Jiewen [mailto:jiewen@intel.com]
Sent: Tuesday, May 02, 2017 8:33 PM
To: Duran, Leo ; edk2-devel@lists.01.org
Cc: Ni, Ruiyu ; Singh, Brijesh ; Ard 
Biesheuvel 
Subject: RE: [RFC] [PATCH V4 0/3] Add IOMMU support.

It is a good question.

I did consider that before.
In our scenario, we need support VTd dynamic opt-in/opt-out. I hope to keep all 
these logic inside of VTd driver.
If we need a default path-through driver, a platform need more complex logic to 
decide when to run the default pass-through and when to run the real VTd 
driver. It is a burden.

I think we do use optional protocols in PciBus driver (such as 
EFI_INCOMPATIBLE_PCI_DEVICE_SUPPORT_PROTOCOL, EFI_PCI_PLATFORM_PROTOCOL, 
EFI_PCI_OVERRIDE_PROTOCOL)

In V4, I am using protocol notification for PciHostBridge, so that we do not 
need locate IOMMU protocol at each function call.
Do you run into any issue on using protocol notification?
[Duran, Leo] Nope, no issues found as of yet.

Thank you
Yao Jiewen


From: Duran, Leo [mailto:leo.du...@amd.com]
Sent: Wednesday, May 3, 2017 2:42 AM
To: Yao, Jiewen >; 
edk2-devel@lists.01.org
Cc: Ni, Ruiyu >; Singh, Brijesh 
>; Ard Biesheuvel 
>
Subject: RE: [RFC] [PATCH V4 0/3] Add IOMMU support.

Hi Yao,

Would it make sense to have a default protocol producer driver that provides 
pass-thru functionality?
This way consumers of the protocol may add a dependency on it, ensuring that 
the protocol provider always run first.
(In the SEV sample driver we run first because we added the driver to the 
APRIORI list, but it seems like a Depex would be more elegant)

Leo.

> -Original Message-
> From: Jiewen Yao [mailto:jiewen@intel.com]
> Sent: Saturday, April 29, 2017 8:51 AM
> To: edk2-devel@lists.01.org
> Cc: Ruiyu Ni >; Duran, Leo 
> >;
> Singh, Brijesh >; Ard 
> Biesheuvel
> >
> Subject: [RFC] [PATCH V4 0/3] Add IOMMU support.
>
>  V4 ==
> Refine the EDKII_IOMMU_PROTOCOL.
>
> 1) Add AllocateBuffer/FreeBuffer/Map/Unmap() API.
> They are similar to DmaLib in EmbeddedPkg and similar to the previous
> BmDmaLib (by leo.du...@amd.com).
>
> These APIs are invoked by PciHostBridge driver to allocate DMA memory.
>
> The PciHostBridge driver (IOMMU consumer) is simplified:
> It uses IOMMU, if IOMMU protocol is present.
> Else it uses original logic.
>
> 2) Add SetMappingAttribute() API.
> It is similar to SetAttribute() API in V1.
>
> This API is invoked by PciBus driver to set DMA access attribute (read/write)
> for device.
>
> The PciBus driver (IOMMU consumer) is simplified:
> It sets access attribute in Map/Unmap,
> if IOMMU protocol is present.
>
> 3) Remove SetRemapAddress/GetRemapAddress() API.
> Because PciHostBridge/PciBus can call the APIs defined above, there is no
> need to provide remap capability.
>
> -- Sample producer drivers:
> 1) The sample VTd driver (IOMMU producer) is at
> https://github.com/jyao1/edk2/tree/dma_v4/IntelSiliconPkg/IntelVTdDxe
>
> It is added to show the concept. It is not fully implemented yet.
> It will not be checked in in this patch.
>
> 2) The sample AMD SEV driver (IOMMU producer) is at
> https://github.com/jyao1/edk2/tree/dma_v4/IntelSiliconPkg/SampleAmdSe
> vDxe
> (code is borrowed from leo.du...@amd.com and 
> brijesh.si...@amd.com)
>
> This is not a right place to put this driver.
>
> It is added to show the concept.
> It is not fully implemented. It will not be checked in.
> Please do not use it directly.
>
> 3) The sample STYX driver (IOMMU producer) is at
> https://github.com/jyao1/edk2/tree/dma_v4/IntelSiliconPkg/SampleStyxDx
> e
> (code is borrowed from 
> ard.biesheu...@linaro.org)
>
> This is not a right place to put this driver.
>
> It is added to show the concept.
> It is not fully implemented. It will not be checked in.
> Please do not use it directly.
>
>
>  V3 ==
> 1) Add Remap capability (from Ard Biesheuvel) Add
> EDKII_IOMMU_REMAP_ADDRESS API in IOMMU_PROTOCOL.
>
> NOTE: The code is not fully validated yet.
> The purpose is to collect feedback to decide the next step.
>
>  V2 ==
> 1) Enhance Unmap() in PciIo (From Ruiyu Ni) Maintain a local list of MapInfo
> and match it in Unmap.
>
> 2) CopyMem for ReadOperation in PciIo after 

Re: [edk2] [RFC] [PATCH V4 0/3] Add IOMMU support.

[Yao, Jiewen]

It is a good question.

I did consider that before.
In our scenario, we need support VTd dynamic opt-in/opt-out. I hope to keep all 
these logic inside of VTd driver.
If we need a default path-through driver, a platform need more complex logic to 
decide when to run the default pass-through and when to run the real VTd 
driver. It is a burden.

I think we do use optional protocols in PciBus driver (such as 
EFI_INCOMPATIBLE_PCI_DEVICE_SUPPORT_PROTOCOL, EFI_PCI_PLATFORM_PROTOCOL, 
EFI_PCI_OVERRIDE_PROTOCOL)

In V4, I am using protocol notification for PciHostBridge, so that we do not 
need locate IOMMU protocol at each function call.
Do you run into any issue on using protocol notification?


Thank you
Yao Jiewen


From: Duran, Leo [mailto:leo.du...@amd.com]
Sent: Wednesday, May 3, 2017 2:42 AM
To: Yao, Jiewen ; edk2-devel@lists.01.org
Cc: Ni, Ruiyu ; Singh, Brijesh ; Ard 
Biesheuvel 
Subject: RE: [RFC] [PATCH V4 0/3] Add IOMMU support.

Hi Yao,

Would it make sense to have a default protocol producer driver that provides 
pass-thru functionality?
This way consumers of the protocol may add a dependency on it, ensuring that 
the protocol provider always run first.
(In the SEV sample driver we run first because we added the driver to the 
APRIORI list, but it seems like a Depex would be more elegant)

Leo.

> -Original Message-
> From: Jiewen Yao [mailto:jiewen@intel.com]
> Sent: Saturday, April 29, 2017 8:51 AM
> To: edk2-devel@lists.01.org
> Cc: Ruiyu Ni >; Duran, Leo 
> >;
> Singh, Brijesh >; Ard 
> Biesheuvel
> >
> Subject: [RFC] [PATCH V4 0/3] Add IOMMU support.
>
>  V4 ==
> Refine the EDKII_IOMMU_PROTOCOL.
>
> 1) Add AllocateBuffer/FreeBuffer/Map/Unmap() API.
> They are similar to DmaLib in EmbeddedPkg and similar to the previous
> BmDmaLib (by leo.du...@amd.com).
>
> These APIs are invoked by PciHostBridge driver to allocate DMA memory.
>
> The PciHostBridge driver (IOMMU consumer) is simplified:
> It uses IOMMU, if IOMMU protocol is present.
> Else it uses original logic.
>
> 2) Add SetMappingAttribute() API.
> It is similar to SetAttribute() API in V1.
>
> This API is invoked by PciBus driver to set DMA access attribute (read/write)
> for device.
>
> The PciBus driver (IOMMU consumer) is simplified:
> It sets access attribute in Map/Unmap,
> if IOMMU protocol is present.
>
> 3) Remove SetRemapAddress/GetRemapAddress() API.
> Because PciHostBridge/PciBus can call the APIs defined above, there is no
> need to provide remap capability.
>
> -- Sample producer drivers:
> 1) The sample VTd driver (IOMMU producer) is at
> https://github.com/jyao1/edk2/tree/dma_v4/IntelSiliconPkg/IntelVTdDxe
>
> It is added to show the concept. It is not fully implemented yet.
> It will not be checked in in this patch.
>
> 2) The sample AMD SEV driver (IOMMU producer) is at
> https://github.com/jyao1/edk2/tree/dma_v4/IntelSiliconPkg/SampleAmdSe
> vDxe
> (code is borrowed from leo.du...@amd.com and 
> brijesh.si...@amd.com)
>
> This is not a right place to put this driver.
>
> It is added to show the concept.
> It is not fully implemented. It will not be checked in.
> Please do not use it directly.
>
> 3) The sample STYX driver (IOMMU producer) is at
> https://github.com/jyao1/edk2/tree/dma_v4/IntelSiliconPkg/SampleStyxDx
> e
> (code is borrowed from 
> ard.biesheu...@linaro.org)
>
> This is not a right place to put this driver.
>
> It is added to show the concept.
> It is not fully implemented. It will not be checked in.
> Please do not use it directly.
>
>
>  V3 ==
> 1) Add Remap capability (from Ard Biesheuvel) Add
> EDKII_IOMMU_REMAP_ADDRESS API in IOMMU_PROTOCOL.
>
> NOTE: The code is not fully validated yet.
> The purpose is to collect feedback to decide the next step.
>
>  V2 ==
> 1) Enhance Unmap() in PciIo (From Ruiyu Ni) Maintain a local list of MapInfo
> and match it in Unmap.
>
> 2) CopyMem for ReadOperation in PciIo after SetAttribute (Leo Duran) Fix a
> bug in V1 that copy mem for read happen before SetAttribute, which will
> break AMD SEV solution.
>
>  V1 ==
>
> This patch series adds IOMMU protocol and updates the consumer to
> support IOMMU based DMA access in UEFI.
>
> This patch series can support the BmDmaLib request for AMD SEV.
> submitted by Duran, Leo > and 
> Brijesh Singh
> >.
> https://lists.01.org/pipermail/edk2-devel/2017-March/008109.html, 

Re: [edk2] [RFC] [PATCH V4 0/3] Add IOMMU support.

[Yao, Jiewen]

Awesome. Thank you!

From: Brijesh Singh [mailto:brijesh.si...@amd.com]
Sent: Wednesday, May 3, 2017 5:09 AM
To: Yao, Jiewen ; edk2-devel@lists.01.org
Cc: brijesh.si...@amd.com; Ni, Ruiyu ; Leo Duran 
; Ard Biesheuvel 
Subject: Re: [RFC] [PATCH V4 0/3] Add IOMMU support.

Hi Yao,


On 04/29/2017 08:51 AM, Jiewen Yao wrote:
>  V4 ==
> Refine the EDKII_IOMMU_PROTOCOL.
>
> 1) Add AllocateBuffer/FreeBuffer/Map/Unmap() API.
> They are similar to DmaLib in EmbeddedPkg and
> similar to the previous BmDmaLib (by 
> leo.du...@amd.com).
>
> These APIs are invoked by PciHostBridge driver
> to allocate DMA memory.
>
> The PciHostBridge driver (IOMMU consumer) is simplified:
> It uses IOMMU, if IOMMU protocol is present.
> Else it uses original logic.
>
> 2) Add SetMappingAttribute() API.
> It is similar to SetAttribute() API in V1.
>
> This API is invoked by PciBus driver to set DMA
> access attribute (read/write) for device.
>
> The PciBus driver (IOMMU consumer) is simplified:
> It sets access attribute in Map/Unmap,
> if IOMMU protocol is present.
>
> 3) Remove SetRemapAddress/GetRemapAddress() API.
> Because PciHostBridge/PciBus can call the APIs defined
> above, there is no need to provide remap capability.
>
> -- Sample producer drivers:
> 1) The sample VTd driver (IOMMU producer)
> is at https://github.com/jyao1/edk2/tree/dma_v4/IntelSiliconPkg/IntelVTdDxe
>
> It is added to show the concept. It is not fully implemented yet.
> It will not be checked in in this patch.
>
> 2) The sample AMD SEV driver (IOMMU producer)
> is at 
> https://github.com/jyao1/edk2/tree/dma_v4/IntelSiliconPkg/SampleAmdSevDxe
> (code is borrowed from leo.du...@amd.com and 
> brijesh.si...@amd.com)
>
> This is not a right place to put this driver.
>


I have reworked my SEV patch series to produce the IOMMU protocol (very similar 
to SampleAmdSevDxe)
when SEV is enabled. The model seems to work just fine. I am able to perform 
the DMA operations
inside the SEV guest. Thank you for the work.

Tested-by: Brijesh Singh >



> It is added to show the concept.
> It is not fully implemented. It will not be checked in.
> Please do not use it directly.
>
> 3) The sample STYX driver (IOMMU producer)
> is at https://github.com/jyao1/edk2/tree/dma_v4/IntelSiliconPkg/SampleStyxDxe
> (code is borrowed from 
> ard.biesheu...@linaro.org)
>
> This is not a right place to put this driver.
>
> It is added to show the concept.
> It is not fully implemented. It will not be checked in.
> Please do not use it directly.
>
>
>  V3 ==
> 1) Add Remap capability (from Ard Biesheuvel)
> Add EDKII_IOMMU_REMAP_ADDRESS API in IOMMU_PROTOCOL.
>
> NOTE: The code is not fully validated yet.
> The purpose is to collect feedback to decide the next step.
>
>  V2 ==
> 1) Enhance Unmap() in PciIo (From Ruiyu Ni)
> Maintain a local list of MapInfo and match it in Unmap.
>
> 2) CopyMem for ReadOperation in PciIo after SetAttribute (Leo Duran)
> Fix a bug in V1 that copy mem for read happen before SetAttribute,
> which will break AMD SEV solution.
>
>  V1 ==
>
> This patch series adds IOMMU protocol and updates the consumer
> to support IOMMU based DMA access in UEFI.
>
> This patch series can support the BmDmaLib request for AMD SEV.
> submitted by Duran, Leo > and 
> Brijesh Singh >.
> https://lists.01.org/pipermail/edk2-devel/2017-March/008109.html, and
> https://lists.01.org/pipermail/edk2-devel/2017-March/008820.html.
> We can have an AMD SEV specific IOMMU driver to produce IOMMU protocol,
> and clear SEV in IOMMU->SetAttribute().
>
> This patch series can also support Intel VTd based DMA protection,
> requested by Jiewen Yao >, 
> discussed in
> https://lists.01.org/pipermail/edk2-devel/2017-March/008157.html.
> We can have an Intel VTd specific IOMMU driver to produce IOMMU protocol,
> and update VTd engine to grant or deny access in IOMMU->SetAttribute().
>
> This patch series does not provide a full Intel VTd driver, which
> will be provide in other patch in the future.
>
> The purpose of this patch series to review if this IOMMU protocol design
> can meet all DMA access and management requirement.
>
> Cc: Ruiyu Ni >
> Cc: Leo Duran >
> Cc: Brijesh Singh >
> Cc: Ard Biesheuvel 
> >
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: 

Re: [edk2] [RFC] [PATCH V4 0/3] Add IOMMU support.

[Brijesh Singh]

Hi Yao,


On 04/29/2017 08:51 AM, Jiewen Yao wrote:

 V4 ==
Refine the EDKII_IOMMU_PROTOCOL.

1) Add AllocateBuffer/FreeBuffer/Map/Unmap() API.
They are similar to DmaLib in EmbeddedPkg and
similar to the previous BmDmaLib (by leo.du...@amd.com).

These APIs are invoked by PciHostBridge driver
to allocate DMA memory.

The PciHostBridge driver (IOMMU consumer) is simplified:
It uses IOMMU, if IOMMU protocol is present.
Else it uses original logic.

2) Add SetMappingAttribute() API.
It is similar to SetAttribute() API in V1.

This API is invoked by PciBus driver to set DMA
access attribute (read/write) for device.

The PciBus driver (IOMMU consumer) is simplified:
It sets access attribute in Map/Unmap,
if IOMMU protocol is present.

3) Remove SetRemapAddress/GetRemapAddress() API.
Because PciHostBridge/PciBus can call the APIs defined
above, there is no need to provide remap capability.

-- Sample producer drivers:
1) The sample VTd driver (IOMMU producer)
is at https://github.com/jyao1/edk2/tree/dma_v4/IntelSiliconPkg/IntelVTdDxe

It is added to show the concept. It is not fully implemented yet.
It will not be checked in in this patch.

2) The sample AMD SEV driver (IOMMU producer)
is at https://github.com/jyao1/edk2/tree/dma_v4/IntelSiliconPkg/SampleAmdSevDxe
(code is borrowed from leo.du...@amd.com and brijesh.si...@amd.com)

This is not a right place to put this driver.




I have reworked my SEV patch series to produce the IOMMU protocol (very similar 
to SampleAmdSevDxe)
when SEV is enabled. The model seems to work just fine. I am able to perform 
the DMA operations
inside the SEV guest. Thank you for the work.

Tested-by: Brijesh Singh 

 


It is added to show the concept.
It is not fully implemented. It will not be checked in.
Please do not use it directly.

3) The sample STYX driver (IOMMU producer)
is at https://github.com/jyao1/edk2/tree/dma_v4/IntelSiliconPkg/SampleStyxDxe
(code is borrowed from ard.biesheu...@linaro.org)

This is not a right place to put this driver.

It is added to show the concept.
It is not fully implemented. It will not be checked in.
Please do not use it directly.


 V3 ==
1) Add Remap capability (from Ard Biesheuvel)
Add EDKII_IOMMU_REMAP_ADDRESS API in IOMMU_PROTOCOL.

NOTE: The code is not fully validated yet.
The purpose is to collect feedback to decide the next step.

 V2 ==
1) Enhance Unmap() in PciIo (From Ruiyu Ni)
Maintain a local list of MapInfo and match it in Unmap.

2) CopyMem for ReadOperation in PciIo after SetAttribute (Leo Duran)
Fix a bug in V1 that copy mem for read happen before SetAttribute,
which will break AMD SEV solution.

 V1 ==

This patch series adds IOMMU protocol and updates the consumer
to support IOMMU based DMA access in UEFI.

This patch series can support the BmDmaLib request for AMD SEV.
submitted by Duran, Leo  and Brijesh Singh 
.
https://lists.01.org/pipermail/edk2-devel/2017-March/008109.html, and
https://lists.01.org/pipermail/edk2-devel/2017-March/008820.html.
We can have an AMD SEV specific IOMMU driver to produce IOMMU protocol,
and clear SEV in IOMMU->SetAttribute().

This patch series can also support Intel VTd based DMA protection,
requested by Jiewen Yao , discussed in
https://lists.01.org/pipermail/edk2-devel/2017-March/008157.html.
We can have an Intel VTd specific IOMMU driver to produce IOMMU protocol,
and update VTd engine to grant or deny access in IOMMU->SetAttribute().

This patch series does not provide a full Intel VTd driver, which
will be provide in other patch in the future.

The purpose of this patch series to review if this IOMMU protocol design
can meet all DMA access and management requirement.

Cc: Ruiyu Ni 
Cc: Leo Duran 
Cc: Brijesh Singh 
Cc: Ard Biesheuvel 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao 

Jiewen Yao (3):
  MdeModulePkg/Include: Add IOMMU protocol definition.
  MdeModulePkg/PciHostBridge: Add IOMMU support.
  MdeModulePkg/PciBus: Add IOMMU support.

 MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.c|   9 +
 MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.h|   1 +
 MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf   |   1 +
 MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c |  37 +++
 MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c  |  37 +++
 MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf |   2 +
 MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridge.h  |   2 +
 MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c|  61 
 MdeModulePkg/Include/Protocol/IoMmu.h  | 310 

 MdeModulePkg/MdeModulePkg.dec  |   3 +
 

Re: [edk2] [RFC] [PATCH V4 0/3] Add IOMMU support.

[Duran, Leo]

Hi Yao,

Would it make sense to have a default protocol producer driver that provides 
pass-thru functionality?
This way consumers of the protocol may add a dependency on it, ensuring that 
the protocol provider always run first.
(In the SEV sample driver we run first because we added the driver to the 
APRIORI list, but it seems like a Depex would be more elegant)

Leo.

> -Original Message-
> From: Jiewen Yao [mailto:jiewen@intel.com]
> Sent: Saturday, April 29, 2017 8:51 AM
> To: edk2-devel@lists.01.org
> Cc: Ruiyu Ni ; Duran, Leo ;
> Singh, Brijesh ; Ard Biesheuvel
> 
> Subject: [RFC] [PATCH V4 0/3] Add IOMMU support.
> 
>  V4 ==
> Refine the EDKII_IOMMU_PROTOCOL.
> 
> 1) Add AllocateBuffer/FreeBuffer/Map/Unmap() API.
> They are similar to DmaLib in EmbeddedPkg and similar to the previous
> BmDmaLib (by leo.du...@amd.com).
> 
> These APIs are invoked by PciHostBridge driver to allocate DMA memory.
> 
> The PciHostBridge driver (IOMMU consumer) is simplified:
> It uses IOMMU, if IOMMU protocol is present.
> Else it uses original logic.
> 
> 2) Add SetMappingAttribute() API.
> It is similar to SetAttribute() API in V1.
> 
> This API is invoked by PciBus driver to set DMA access attribute (read/write)
> for device.
> 
> The PciBus driver (IOMMU consumer) is simplified:
> It sets access attribute in Map/Unmap,
> if IOMMU protocol is present.
> 
> 3) Remove SetRemapAddress/GetRemapAddress() API.
> Because PciHostBridge/PciBus can call the APIs defined above, there is no
> need to provide remap capability.
> 
> -- Sample producer drivers:
> 1) The sample VTd driver (IOMMU producer) is at
> https://github.com/jyao1/edk2/tree/dma_v4/IntelSiliconPkg/IntelVTdDxe
> 
> It is added to show the concept. It is not fully implemented yet.
> It will not be checked in in this patch.
> 
> 2) The sample AMD SEV driver (IOMMU producer) is at
> https://github.com/jyao1/edk2/tree/dma_v4/IntelSiliconPkg/SampleAmdSe
> vDxe
> (code is borrowed from leo.du...@amd.com and brijesh.si...@amd.com)
> 
> This is not a right place to put this driver.
> 
> It is added to show the concept.
> It is not fully implemented. It will not be checked in.
> Please do not use it directly.
> 
> 3) The sample STYX driver (IOMMU producer) is at
> https://github.com/jyao1/edk2/tree/dma_v4/IntelSiliconPkg/SampleStyxDx
> e
> (code is borrowed from ard.biesheu...@linaro.org)
> 
> This is not a right place to put this driver.
> 
> It is added to show the concept.
> It is not fully implemented. It will not be checked in.
> Please do not use it directly.
> 
> 
>  V3 ==
> 1) Add Remap capability (from Ard Biesheuvel) Add
> EDKII_IOMMU_REMAP_ADDRESS API in IOMMU_PROTOCOL.
> 
> NOTE: The code is not fully validated yet.
> The purpose is to collect feedback to decide the next step.
> 
>  V2 ==
> 1) Enhance Unmap() in PciIo (From Ruiyu Ni) Maintain a local list of MapInfo
> and match it in Unmap.
> 
> 2) CopyMem for ReadOperation in PciIo after SetAttribute (Leo Duran) Fix a
> bug in V1 that copy mem for read happen before SetAttribute, which will
> break AMD SEV solution.
> 
>  V1 ==
> 
> This patch series adds IOMMU protocol and updates the consumer to
> support IOMMU based DMA access in UEFI.
> 
> This patch series can support the BmDmaLib request for AMD SEV.
> submitted by Duran, Leo  and Brijesh Singh
> .
> https://lists.01.org/pipermail/edk2-devel/2017-March/008109.html, and
> https://lists.01.org/pipermail/edk2-devel/2017-March/008820.html.
> We can have an AMD SEV specific IOMMU driver to produce IOMMU
> protocol, and clear SEV in IOMMU->SetAttribute().
> 
> This patch series can also support Intel VTd based DMA protection,
> requested by Jiewen Yao , discussed in
> https://lists.01.org/pipermail/edk2-devel/2017-March/008157.html.
> We can have an Intel VTd specific IOMMU driver to produce IOMMU
> protocol, and update VTd engine to grant or deny access in IOMMU-
> >SetAttribute().
> 
> This patch series does not provide a full Intel VTd driver, which will be
> provide in other patch in the future.
> 
> The purpose of this patch series to review if this IOMMU protocol design can
> meet all DMA access and management requirement.
> 
> Cc: Ruiyu Ni 
> Cc: Leo Duran 
> Cc: Brijesh Singh 
> Cc: Ard Biesheuvel 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jiewen Yao 
> 
> Jiewen Yao (3):
>   MdeModulePkg/Include: Add IOMMU protocol definition.
>   MdeModulePkg/PciHostBridge: Add IOMMU support.
>   MdeModulePkg/PciBus: Add IOMMU support.
> 
>  MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.c|   9 +
>  

Re: [edk2] [RFC] [PATCH V4 0/3] Add IOMMU support.

[Yao, Jiewen]

That is awesome!

I am glad to see a real example - GenericSmmuStaticPciDmaDxe

Let's continue the discussion on if we can make it simpler.

Thank you
Yao Jiewen

From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard 
Biesheuvel
Sent: Tuesday, May 2, 2017 6:15 PM
To: Yao, Jiewen <jiewen@intel.com>
Cc: Ni, Ruiyu <ruiyu...@intel.com>; edk2-devel@lists.01.org; Leo Duran 
<leo.du...@amd.com>
Subject: Re: [edk2] [RFC] [PATCH V4 0/3] Add IOMMU support.

On 29 April 2017 at 14:48, Jiewen Yao 
<jiewen@intel.com<mailto:jiewen@intel.com>> wrote:
>  V4 ==
> Refine the EDKII_IOMMU_PROTOCOL.
>
> 1) Add AllocateBuffer/FreeBuffer/Map/Unmap() API.
> They are similar to DmaLib in EmbeddedPkg and
> similar to the previous BmDmaLib (by 
> leo.du...@amd.com<mailto:leo.du...@amd.com>).
>
> These APIs are invoked by PciHostBridge driver
> to allocate DMA memory.
>
> The PciHostBridge driver (IOMMU consumer) is simplified:
> It uses IOMMU, if IOMMU protocol is present.
> Else it uses original logic.
>
> 2) Add SetMappingAttribute() API.
> It is similar to SetAttribute() API in V1.
>
> This API is invoked by PciBus driver to set DMA
> access attribute (read/write) for device.
>
> The PciBus driver (IOMMU consumer) is simplified:
> It sets access attribute in Map/Unmap,
> if IOMMU protocol is present.
>
> 3) Remove SetRemapAddress/GetRemapAddress() API.
> Because PciHostBridge/PciBus can call the APIs defined
> above, there is no need to provide remap capability.
>
> -- Sample producer drivers:
> 1) The sample VTd driver (IOMMU producer)
> is at https://github.com/jyao1/edk2/tree/dma_v4/IntelSiliconPkg/IntelVTdDxe
>
> It is added to show the concept. It is not fully implemented yet.
> It will not be checked in in this patch.
>
> 2) The sample AMD SEV driver (IOMMU producer)
> is at 
> https://github.com/jyao1/edk2/tree/dma_v4/IntelSiliconPkg/SampleAmdSevDxe
> (code is borrowed from leo.du...@amd.com<mailto:leo.du...@amd.com> and 
> brijesh.si...@amd.com<mailto:brijesh.si...@amd.com>)
>
> This is not a right place to put this driver.
>
> It is added to show the concept.
> It is not fully implemented. It will not be checked in.
> Please do not use it directly.
>
> 3) The sample STYX driver (IOMMU producer)
> is at https://github.com/jyao1/edk2/tree/dma_v4/IntelSiliconPkg/SampleStyxDxe
> (code is borrowed from 
> ard.biesheu...@linaro.org<mailto:ard.biesheu...@linaro.org>)
>
> This is not a right place to put this driver.
>
> It is added to show the concept.
> It is not fully implemented. It will not be checked in.
> Please do not use it directly.
>


With the issue in 3/3 addressed:

Tested-by: Ard Biesheuvel 
<ard.biesheu...@linaro.org<mailto:ard.biesheu...@linaro.org>>

on AMD Seattle, with a static remapping driver that I will send out shortly.

I am quite happy with this version, but I would like to continue the
discussion as to whether we really need SetAttribute() and
SetMappingAttribute()

--
Ard.


>
>  V3 ==
> 1) Add Remap capability (from Ard Biesheuvel)
> Add EDKII_IOMMU_REMAP_ADDRESS API in IOMMU_PROTOCOL.
>
> NOTE: The code is not fully validated yet.
> The purpose is to collect feedback to decide the next step.
>
>  V2 ==
> 1) Enhance Unmap() in PciIo (From Ruiyu Ni)
> Maintain a local list of MapInfo and match it in Unmap.
>
> 2) CopyMem for ReadOperation in PciIo after SetAttribute (Leo Duran)
> Fix a bug in V1 that copy mem for read happen before SetAttribute,
> which will break AMD SEV solution.
>
>  V1 ==
>
> This patch series adds IOMMU protocol and updates the consumer
> to support IOMMU based DMA access in UEFI.
>
> This patch series can support the BmDmaLib request for AMD SEV.
> submitted by Duran, Leo <leo.du...@amd.com<mailto:leo.du...@amd.com>> and 
> Brijesh Singh <brijesh.ksi...@gmail.com<mailto:brijesh.ksi...@gmail.com>>.
> https://lists.01.org/pipermail/edk2-devel/2017-March/008109.html, and
> https://lists.01.org/pipermail/edk2-devel/2017-March/008820.html.
> We can have an AMD SEV specific IOMMU driver to produce IOMMU protocol,
> and clear SEV in IOMMU->SetAttribute().
>
> This patch series can also support Intel VTd based DMA protection,
> requested by Jiewen Yao <jiewen@intel.com<mailto:jiewen@intel.com>>, 
> discussed in
> https://lists.01.org/pipermail/edk2-devel/2017-March/008157.html.
> We can have an Intel VTd specific IOMMU driver to produce IOMMU protocol,
> and update VTd engine to grant or deny access in IOMMU->SetAttribute().
>
> This patch series 

Re: [edk2] [RFC] [PATCH V4 0/3] Add IOMMU support.

[Ard Biesheuvel]

On 29 April 2017 at 14:48, Jiewen Yao  wrote:
>  V4 ==
> Refine the EDKII_IOMMU_PROTOCOL.
>
> 1) Add AllocateBuffer/FreeBuffer/Map/Unmap() API.
> They are similar to DmaLib in EmbeddedPkg and
> similar to the previous BmDmaLib (by leo.du...@amd.com).
>
> These APIs are invoked by PciHostBridge driver
> to allocate DMA memory.
>
> The PciHostBridge driver (IOMMU consumer) is simplified:
> It uses IOMMU, if IOMMU protocol is present.
> Else it uses original logic.
>
> 2) Add SetMappingAttribute() API.
> It is similar to SetAttribute() API in V1.
>
> This API is invoked by PciBus driver to set DMA
> access attribute (read/write) for device.
>
> The PciBus driver (IOMMU consumer) is simplified:
> It sets access attribute in Map/Unmap,
> if IOMMU protocol is present.
>
> 3) Remove SetRemapAddress/GetRemapAddress() API.
> Because PciHostBridge/PciBus can call the APIs defined
> above, there is no need to provide remap capability.
>
> -- Sample producer drivers:
> 1) The sample VTd driver (IOMMU producer)
> is at https://github.com/jyao1/edk2/tree/dma_v4/IntelSiliconPkg/IntelVTdDxe
>
> It is added to show the concept. It is not fully implemented yet.
> It will not be checked in in this patch.
>
> 2) The sample AMD SEV driver (IOMMU producer)
> is at 
> https://github.com/jyao1/edk2/tree/dma_v4/IntelSiliconPkg/SampleAmdSevDxe
> (code is borrowed from leo.du...@amd.com and brijesh.si...@amd.com)
>
> This is not a right place to put this driver.
>
> It is added to show the concept.
> It is not fully implemented. It will not be checked in.
> Please do not use it directly.
>
> 3) The sample STYX driver (IOMMU producer)
> is at https://github.com/jyao1/edk2/tree/dma_v4/IntelSiliconPkg/SampleStyxDxe
> (code is borrowed from ard.biesheu...@linaro.org)
>
> This is not a right place to put this driver.
>
> It is added to show the concept.
> It is not fully implemented. It will not be checked in.
> Please do not use it directly.
>


With the issue in 3/3 addressed:

Tested-by: Ard Biesheuvel 

on AMD Seattle, with a static remapping driver that I will send out shortly.

I am quite happy with this version, but I would like to continue the
discussion as to whether we really need SetAttribute() and
SetMappingAttribute()

-- 
Ard.


>
>  V3 ==
> 1) Add Remap capability (from Ard Biesheuvel)
> Add EDKII_IOMMU_REMAP_ADDRESS API in IOMMU_PROTOCOL.
>
> NOTE: The code is not fully validated yet.
> The purpose is to collect feedback to decide the next step.
>
>  V2 ==
> 1) Enhance Unmap() in PciIo (From Ruiyu Ni)
> Maintain a local list of MapInfo and match it in Unmap.
>
> 2) CopyMem for ReadOperation in PciIo after SetAttribute (Leo Duran)
> Fix a bug in V1 that copy mem for read happen before SetAttribute,
> which will break AMD SEV solution.
>
>  V1 ==
>
> This patch series adds IOMMU protocol and updates the consumer
> to support IOMMU based DMA access in UEFI.
>
> This patch series can support the BmDmaLib request for AMD SEV.
> submitted by Duran, Leo  and Brijesh Singh 
> .
> https://lists.01.org/pipermail/edk2-devel/2017-March/008109.html, and
> https://lists.01.org/pipermail/edk2-devel/2017-March/008820.html.
> We can have an AMD SEV specific IOMMU driver to produce IOMMU protocol,
> and clear SEV in IOMMU->SetAttribute().
>
> This patch series can also support Intel VTd based DMA protection,
> requested by Jiewen Yao , discussed in
> https://lists.01.org/pipermail/edk2-devel/2017-March/008157.html.
> We can have an Intel VTd specific IOMMU driver to produce IOMMU protocol,
> and update VTd engine to grant or deny access in IOMMU->SetAttribute().
>
> This patch series does not provide a full Intel VTd driver, which
> will be provide in other patch in the future.
>
> The purpose of this patch series to review if this IOMMU protocol design
> can meet all DMA access and management requirement.
>
> Cc: Ruiyu Ni 
> Cc: Leo Duran 
> Cc: Brijesh Singh 
> Cc: Ard Biesheuvel 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jiewen Yao 
>
> Jiewen Yao (3):
>   MdeModulePkg/Include: Add IOMMU protocol definition.
>   MdeModulePkg/PciHostBridge: Add IOMMU support.
>   MdeModulePkg/PciBus: Add IOMMU support.
>
>  MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.c|   9 +
>  MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.h|   1 +
>  MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf   |   1 +
>  MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c |  37 +++
>  MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c  |  37 +++
>  MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf |   2 +
>  

[edk2] [RFC] [PATCH V4 0/3] Add IOMMU support.

[Jiewen Yao]

 V4 ==
Refine the EDKII_IOMMU_PROTOCOL.

1) Add AllocateBuffer/FreeBuffer/Map/Unmap() API.
They are similar to DmaLib in EmbeddedPkg and
similar to the previous BmDmaLib (by leo.du...@amd.com).

These APIs are invoked by PciHostBridge driver
to allocate DMA memory.

The PciHostBridge driver (IOMMU consumer) is simplified:
It uses IOMMU, if IOMMU protocol is present.
Else it uses original logic.

2) Add SetMappingAttribute() API.
It is similar to SetAttribute() API in V1.

This API is invoked by PciBus driver to set DMA
access attribute (read/write) for device.

The PciBus driver (IOMMU consumer) is simplified:
It sets access attribute in Map/Unmap,
if IOMMU protocol is present.

3) Remove SetRemapAddress/GetRemapAddress() API.
Because PciHostBridge/PciBus can call the APIs defined
above, there is no need to provide remap capability.

-- Sample producer drivers:
1) The sample VTd driver (IOMMU producer)
is at https://github.com/jyao1/edk2/tree/dma_v4/IntelSiliconPkg/IntelVTdDxe

It is added to show the concept. It is not fully implemented yet.
It will not be checked in in this patch.

2) The sample AMD SEV driver (IOMMU producer)
is at https://github.com/jyao1/edk2/tree/dma_v4/IntelSiliconPkg/SampleAmdSevDxe
(code is borrowed from leo.du...@amd.com and brijesh.si...@amd.com)

This is not a right place to put this driver.

It is added to show the concept.
It is not fully implemented. It will not be checked in.
Please do not use it directly.

3) The sample STYX driver (IOMMU producer)
is at https://github.com/jyao1/edk2/tree/dma_v4/IntelSiliconPkg/SampleStyxDxe
(code is borrowed from ard.biesheu...@linaro.org)

This is not a right place to put this driver.

It is added to show the concept.
It is not fully implemented. It will not be checked in.
Please do not use it directly.


 V3 ==
1) Add Remap capability (from Ard Biesheuvel)
Add EDKII_IOMMU_REMAP_ADDRESS API in IOMMU_PROTOCOL.

NOTE: The code is not fully validated yet.
The purpose is to collect feedback to decide the next step.

 V2 ==
1) Enhance Unmap() in PciIo (From Ruiyu Ni)
Maintain a local list of MapInfo and match it in Unmap.

2) CopyMem for ReadOperation in PciIo after SetAttribute (Leo Duran)
Fix a bug in V1 that copy mem for read happen before SetAttribute,
which will break AMD SEV solution.

 V1 ==

This patch series adds IOMMU protocol and updates the consumer
to support IOMMU based DMA access in UEFI.

This patch series can support the BmDmaLib request for AMD SEV.
submitted by Duran, Leo  and Brijesh Singh 
.
https://lists.01.org/pipermail/edk2-devel/2017-March/008109.html, and
https://lists.01.org/pipermail/edk2-devel/2017-March/008820.html.
We can have an AMD SEV specific IOMMU driver to produce IOMMU protocol,
and clear SEV in IOMMU->SetAttribute().

This patch series can also support Intel VTd based DMA protection,
requested by Jiewen Yao , discussed in
https://lists.01.org/pipermail/edk2-devel/2017-March/008157.html.
We can have an Intel VTd specific IOMMU driver to produce IOMMU protocol,
and update VTd engine to grant or deny access in IOMMU->SetAttribute().

This patch series does not provide a full Intel VTd driver, which
will be provide in other patch in the future.

The purpose of this patch series to review if this IOMMU protocol design
can meet all DMA access and management requirement.

Cc: Ruiyu Ni 
Cc: Leo Duran 
Cc: Brijesh Singh 
Cc: Ard Biesheuvel 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao 

Jiewen Yao (3):
  MdeModulePkg/Include: Add IOMMU protocol definition.
  MdeModulePkg/PciHostBridge: Add IOMMU support.
  MdeModulePkg/PciBus: Add IOMMU support.

 MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.c|   9 +
 MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.h|   1 +
 MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf   |   1 +
 MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c |  37 +++
 MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c  |  37 +++
 MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf |   2 +
 MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridge.h  |   2 +
 MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c|  61 
 MdeModulePkg/Include/Protocol/IoMmu.h  | 310 

 MdeModulePkg/MdeModulePkg.dec  |   3 +
 10 files changed, 463 insertions(+)
 create mode 100644 MdeModulePkg/Include/Protocol/IoMmu.h

-- 
2.7.4.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [RFC] [PATCH V4 0/3] Add IOMMU support.

[Jiewen Yao]

 V4 ==
Refine the EDKII_IOMMU_PROTOCOL.

1) Add AllocateBuffer/FreeBuffer/Map/Unmap() API.
They are similar to DmaLib in EmbeddedPkg and
similar to the previous BmDmaLib (by leo.du...@amd.com).

These APIs are invoked by PciHostBridge driver
to allocate DMA memory.

The PciHostBridge driver (IOMMU consumer) is simplified:
It uses IOMMU, if IOMMU protocol is present.
Else it uses original logic.

2) Add SetMappingAttribute() API.
It is similar to SetAttribute() API in V1.

This API is invoked by PciBus driver to set DMA
access attribute (read/write) for device.

The PciBus driver (IOMMU consumer) is simplified:
It sets access attribute in Map/Unmap,
if IOMMU protocol is present.

3) Remove SetRemapAddress/GetRemapAddress() API.
Because PciHostBridge/PciBus can call the APIs defined
above, there is no need to provide remap capability.

-- Sample producer drivers:
1) The sample VTd driver (IOMMU producer)
is at https://github.com/jyao1/edk2/tree/dma_v4/IntelSiliconPkg/IntelVTdDxe

It is added to show the concept. It is not fully implemented yet.
It will not be checked in in this patch.

2) The sample AMD SEV driver (IOMMU producer)
is at https://github.com/jyao1/edk2/tree/dma_v4/IntelSiliconPkg/SampleAmdSevDxe
(code is borrowed from leo.du...@amd.com and brijesh.si...@amd.com)

This is not a right place to put this driver.

It is added to show the concept.
It is not fully implemented. It will not be checked in.
Please do not use it directly.

3) The sample STYX driver (IOMMU producer)
is at https://github.com/jyao1/edk2/tree/dma_v4/IntelSiliconPkg/SampleStyxDxe
(code is borrowed from ard.biesheu...@linaro.org)

This is not a right place to put this driver.

It is added to show the concept.
It is not fully implemented. It will not be checked in.
Please do not use it directly.


 V3 ==
1) Add Remap capability (from Ard Biesheuvel)
Add EDKII_IOMMU_REMAP_ADDRESS API in IOMMU_PROTOCOL.

NOTE: The code is not fully validated yet.
The purpose is to collect feedback to decide the next step.

 V2 ==
1) Enhance Unmap() in PciIo (From Ruiyu Ni)
Maintain a local list of MapInfo and match it in Unmap.

2) CopyMem for ReadOperation in PciIo after SetAttribute (Leo Duran)
Fix a bug in V1 that copy mem for read happen before SetAttribute,
which will break AMD SEV solution.

 V1 ==

This patch series adds IOMMU protocol and updates the consumer
to support IOMMU based DMA access in UEFI.

This patch series can support the BmDmaLib request for AMD SEV.
submitted by Duran, Leo  and Brijesh Singh 
.
https://lists.01.org/pipermail/edk2-devel/2017-March/008109.html, and
https://lists.01.org/pipermail/edk2-devel/2017-March/008820.html.
We can have an AMD SEV specific IOMMU driver to produce IOMMU protocol,
and clear SEV in IOMMU->SetAttribute().

This patch series can also support Intel VTd based DMA protection,
requested by Jiewen Yao , discussed in
https://lists.01.org/pipermail/edk2-devel/2017-March/008157.html.
We can have an Intel VTd specific IOMMU driver to produce IOMMU protocol,
and update VTd engine to grant or deny access in IOMMU->SetAttribute().

This patch series does not provide a full Intel VTd driver, which
will be provide in other patch in the future.

The purpose of this patch series to review if this IOMMU protocol design
can meet all DMA access and management requirement.

Cc: Ruiyu Ni 
Cc: Leo Duran 
Cc: Brijesh Singh 
Cc: Ard Biesheuvel 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao 

Jiewen Yao (3):
  MdeModulePkg/Include: Add IOMMU protocol definition.
  MdeModulePkg/PciHostBridge: Add IOMMU support.
  MdeModulePkg/PciBus: Add IOMMU support.

 MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.c|   9 +
 MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.h|   1 +
 MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf   |   1 +
 MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c |  37 +++
 MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c  |  37 +++
 MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf |   2 +
 MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridge.h  |   2 +
 MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c|  61 
 MdeModulePkg/Include/Protocol/IoMmu.h  | 310 

 MdeModulePkg/MdeModulePkg.dec  |   3 +
 10 files changed, 463 insertions(+)
 create mode 100644 MdeModulePkg/Include/Protocol/IoMmu.h

-- 
2.7.4.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel