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

2017-05-04 Thread 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

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

2017-05-04 Thread 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

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

2017-05-03 Thread 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

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

2017-05-02 Thread 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

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

2017-05-02 Thread 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

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

2017-05-02 Thread 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

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

2017-05-02 Thread 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

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

2017-05-02 Thread Yao, Jiewen
, 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>>

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

2017-05-02 Thread 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

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

2017-04-29 Thread 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

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

2017-04-29 Thread 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