From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id E6FC982213 for ; Thu, 2 Mar 2017 22:12:54 -0800 (PST) Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Mar 2017 22:12:54 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.35,235,1484035200"; d="scan'208,217";a="231782884" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by fmsmga004.fm.intel.com with ESMTP; 02 Mar 2017 22:12:54 -0800 Received: from fmsmsx126.amr.corp.intel.com (10.18.125.43) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 2 Mar 2017 22:12:54 -0800 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by FMSMSX126.amr.corp.intel.com (10.18.125.43) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 2 Mar 2017 22:12:54 -0800 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.88]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.204]) with mapi id 14.03.0248.002; Fri, 3 Mar 2017 14:12:49 +0800 From: "Yao, Jiewen" To: "Ni, Ruiyu" , Leo Duran , "edk2-devel@ml01.01.org" CC: "Yao, Jiewen" Thread-Topic: [edk2] [PATCH v4 0/6] DxeBmDmaLib (BmDmaLib class) library Thread-Index: AQHSk4VnIFT8L9lYGEqhOWCWvu7636GB18+AgAC73QA= Date: Fri, 3 Mar 2017 06:12:49 +0000 Message-ID: <74D8A39837DF1E4DA445A8C0B3885C503A8F8D82@shsmsx102.ccr.corp.intel.com> References: <1488480396-32358-1-git-send-email-leo.duran@amd.com> <734D49CCEBEEF84792F5B80ED585239D5B8BE9E0@SHSMSX104.ccr.corp.intel.com> In-Reply-To: <734D49CCEBEEF84792F5B80ED585239D5B8BE9E0@SHSMSX104.ccr.corp.intel.com> Accept-Language: zh-CN, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 Subject: Re: [PATCH v4 0/6] DxeBmDmaLib (BmDmaLib class) library X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 06:12:55 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Thanks for your patient. 1) I think it is good to abstract the DMA operation. However, the problem on doing this in PciHostBridge driver is that: We lose= the information on which PCI device submits the Map/Ummap() request. For example, we can allocate one DMA memory for an ATA device, and we do no= t want USB device access this DMA memory. For Intel VTd, we need this information. Is that possible to share your feature code to help me understand how this = API is used on your side? Or if it is hard to share the code, is that possible to help us evaluate if= we can move this library or hook to the PciBus driver ? 2) Back to the API, I have a little concern on having "DmaAbove4GB" in BmDm= aMap() and BmDmaAllocateBuffer(). Per my understanding: - The PciHostBridgeDxe driver is the core module. - The PciHostBridgeLib is the silicon hardware layout abstraction. The prod= ucer should be silicon driver. - The BmDmaLib is the PCI feature abstraction. The producer could be a core= module or a platform module. I think we had better make the BmDmaLib API be similar to the API defined i= n UEFI spec. I discussed with Ruiyu, and we have some idea to eliminate "DmaAbove4GB" an= d make API consistent with UEFI spec. 3) I am not sure if BmDmaLib API need a way to distinguish which PCI_ROOT_B= RIDGE_IO it is handling. That is an open question. Thank you Yao Jiewen From: Ni, Ruiyu Sent: Friday, March 3, 2017 10:04 AM To: Leo Duran ; edk2-devel@ml01.01.org Cc: Yao, Jiewen Subject: RE: [edk2] [PATCH v4 0/6] DxeBmDmaLib (BmDmaLib class) library Leo, I talked with Jiewen in office today. He felt that Intel might have a simil= ar need of such layer of abstraction (BmDmaLib). We are investigating it. Can you please wait for several days? We'd like to review the current interfaces of BmDmaLib to make sure it's ge= neral enough to meet any potential needs. Sorry about the delay. Regards, Ray >-----Original Message----- >From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Leo= Duran >Sent: Friday, March 3, 2017 2:47 AM >To: edk2-devel@ml01.01.org >Cc: Leo Duran > >Subject: [edk2] [PATCH v4 0/6] DxeBmDmaLib (BmDmaLib class) library > >This series provides an abstraction layer for Bus-master DMA operations as >currently implemented by the PciHostBridgeDxe driver. The intent is to the= n >allow override of this library as may be required by specific hardware >implementations, such as AMD's Secure Encrypted Virtualization (SEV). > >Please refer to the RFC discussion for SEV here: >http://marc.info/?l=3Dlinux-mm&m=3D147190814023863&w=3D2 > >This new BmDmaLib class library is cloned from the existing DmaLib with >an additional DmaAbove4GB (BOOLEAN) parameter for the Map and Allocate >interfaces, so that decisions can be made about the need to allocate DMA >buffers below the 4GB boundary. > >NOTE: The abstraction layer is intended for Bus-master (DMA capable) >devices, and not restricted to the PCI Root-Bridge use-case. Thus the >rationale for not using EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL_OPERATION types. > >Changes since v3: >- Add copyright notice on changed files. >- Re-order parameters on BmDmaFreeBuffer(), consistent with gBS->FreePages= (). > >Leo Duran (6): > MdeModulePkg: Add DxeBmDmaLib (BmDmaLib class) library > ArmVirtPkg: Resolve BmDmaLib class for PciHostBridgeDxe driver > CorebootPayloadPkg: Resolve BmDmaLib class for PciHostBridgeDxe driver > MdeModulePkg: Resolve BmDmaLib class for PciHostBridgeDxe driver > OvmfPkg: Resolve BmDmaLib class for PciHostBridgeDxe driver > MdeModulePkg: Modify PciHostBridgeDxe to use new BmDmaLib class > library > > ArmVirtPkg/ArmVirtQemu.dsc | 2 + > ArmVirtPkg/ArmVirtQemuKernel.dsc | 2 + > CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc | 3 + > CorebootPayloadPkg/CorebootPayloadPkgIa32X64.dsc | 3 + > .../Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf | 1 + > .../Bus/Pci/PciHostBridgeDxe/PciRootBridge.h | 15 +- > .../Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c | 274 ++++------------ > MdeModulePkg/Include/Library/BmDmaLib.h | 161 ++++++++++ > MdeModulePkg/Library/DxeBmDmaLib/DxeBmDmaLib.c | 351 ++++++++++++++++= +++++ > MdeModulePkg/Library/DxeBmDmaLib/DxeBmDmaLib.inf | 41 +++ > MdeModulePkg/MdeModulePkg.dsc | 3 + > OvmfPkg/OvmfPkgIa32.dsc | 2 + > OvmfPkg/OvmfPkgIa32X64.dsc | 2 + > OvmfPkg/OvmfPkgX64.dsc | 2 + > 14 files changed, 642 insertions(+), 220 deletions(-) > create mode 100644 MdeModulePkg/Include/Library/BmDmaLib.h > create mode 100644 MdeModulePkg/Library/DxeBmDmaLib/DxeBmDmaLib.c > create mode 100644 MdeModulePkg/Library/DxeBmDmaLib/DxeBmDmaLib.inf > >-- >2.7.4 > >_______________________________________________ >edk2-devel mailing list >edk2-devel@lists.01.org >https://lists.01.org/mailman/listinfo/edk2-devel