From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 7C06B21DFA8FE for ; Thu, 30 Mar 2017 06:54:12 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id 190so74780449itm.0 for ; Thu, 30 Mar 2017 06:54:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=7gmHLwOWTS0bbX9EeW9KQzolNHIx2lz48J0GNtRrXr8=; b=Er6uy1w86m7Fh8XPhdeQTGUVyxZ+UuPk55EBOvICl5eQaGZ6lvtLtaJ+M9938N2DC5 KI46mg95M6i0FkmFuLM176bCG2u4BB9ARbFHrH7EOP4OFkr26GrD6f5H52lZe+26gZtN SMg8bEW4cqS6rdjU2z2JfN4M7aMpa5i1UX49c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=7gmHLwOWTS0bbX9EeW9KQzolNHIx2lz48J0GNtRrXr8=; b=OPTGPMP3LuH4sAjPAApqn4KHTBD01xp5Me9V6TuKK/G0yGO9JaGq/+ex49g1YbcuzG 97Tye1pkGfq+fMPVfAyyOKW5tT0jdKhgH0/xEnEX5QIH2V7KRviYPhztpIiD9NGmo5zJ +dyrc9MjKnxbWeH0sDjnIxAxRoL7HHZA6Vf8WKYlUomtBfyBWDdQHYoxbYib95vBFNj0 MBZvMGOjvRc9hiUGqom+awjk+PrmW6MDBvWYavGWbipT5FhWCqPOeD7iSDE3r8NgJGLE HJtFpbZHvft4oduLY972QsfeJO+MF33fhiwDg4r+sp1/6PKMJI6flWnVPyBdx8Cr3/A1 Wrwg== X-Gm-Message-State: AFeK/H0IWV6rk5cjgbaR45Pz5qT1/KsyidlHnSRItflnBP3esc+lbRUqV9S4LBTaxFQicyPEEPfDkx0g5a7UmCfF X-Received: by 10.36.207.212 with SMTP id y203mr480339itf.63.1490882051813; Thu, 30 Mar 2017 06:54:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.10.27 with HTTP; Thu, 30 Mar 2017 06:54:11 -0700 (PDT) In-Reply-To: <74D8A39837DF1E4DA445A8C0B3885C503A917A44@shsmsx102.ccr.corp.intel.com> References: <1490434122-16200-1-git-send-email-jiewen.yao@intel.com> <1490434122-16200-2-git-send-email-jiewen.yao@intel.com> <74D8A39837DF1E4DA445A8C0B3885C503A916565@shsmsx102.ccr.corp.intel.com> <74D8A39837DF1E4DA445A8C0B3885C503A917A44@shsmsx102.ccr.corp.intel.com> From: Ard Biesheuvel Date: Thu, 30 Mar 2017 14:54:11 +0100 Message-ID: To: "Yao, Jiewen" Cc: "Kinney, Michael D" , "Ni, Ruiyu" , Leo Duran , "edk2-devel@lists.01.org" , Brijesh Singh Subject: Re: [PATCH 1/3] MdeModulePkg/Include: Add IOMMU protocol definition. X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 13:54:12 -0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 30 March 2017 at 13:37, Yao, Jiewen wrote: > Thanks for the info. > > > > Comment inline. > > > > > > > > > > From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] > Sent: Wednesday, March 29, 2017 10:23 PM > To: Yao, Jiewen > Cc: Kinney, Michael D ; Ni, Ruiyu > ; Leo Duran ; > edk2-devel@lists.01.org; Brijesh Singh > Subject: Re: [edk2] [PATCH 1/3] MdeModulePkg/Include: Add IOMMU protocol > definition. > > > > On 29 March 2017 at 00:45, Yao, Jiewen wrote: >> Agree. That is a good idea. >> >> >> >> I will add that in V2 patch. >> > > Hello Jiewen, > > As a bit of background, what I have in mind is an enhancement of the > PCI root bridge I/O allocate, map and unmap methods so that situations > that would currently lead to failure or to suboptimal performance are > left for the IOMMU protocol to handle if one is present. Note that > this may imply having IOMMU protocol instances for each PCI root > bridge, and for other masters as well. (For example, AMD Seattle has > separate IOMMUs for PCI and for the networking controllers, which are > wired to the internal interconnect directly) > > > > [Jiewen] I am not very sure what do you mean. > > > > Fist, let me explain Intel platform. > > > > There might be multiple IOMMU engines on one platform. one for graphic an= d > one for rest PCI device (such as ATA/USB). > > But all IOMMU engines are reported by one =E2=80=9CDMAR=E2=80=9D ACPI tab= le. > > > > In such case, the Intel IOMMU driver just produces one IOMMU protocol, ba= sed > upon DMAR ACPI table. > > > > This IOMMU protocol provider can use UEFI device path to distinguish if t= he > device is graphic or ATA/USB, and find out corresponding IOMMU engine. > > > > I know AMD has =E2=80=9CIVRS=E2=80=9D ACPI table and ARM has =E2=80=9CIOR= T=E2=80=9D ACPI table. > > > > In such case, I assume AMD may have one IOMMU protocol based upon IVRS > table, and ARM may have one IOMMU protocol based upon IORT table. > > And this single IOMMU protocol provider can handle multiple IOMMU engines= on > one system. > > > > Is that understand same as yours? > OK, that works for me. > > > > > > > So in RootBridgeIoMap(), for instance, we have this condition > > PhysicalAddress =3D (EFI_PHYSICAL_ADDRESS) (UINTN) HostAddress; > if ((!RootBridge->DmaAbove4G || > (Operation !=3D EfiPciOperationBusMasterRead64 && > Operation !=3D EfiPciOperationBusMasterWrite64 && > Operation !=3D EfiPciOperationBusMasterCommonBuffer64)) && > ((PhysicalAddress + *NumberOfBytes) > SIZE_4GB)) { > > to decide whether bounce buffering is necessary (or even possible). > The mapping between DeviceAddress and HostAddress could be supplied by > the IOMMU protocol instance, which also means we should reinterpret > DmaAbove4G and other variables related to 32-bit addressing to apply > to the device address and not the physical address. > > Similarly, in RootBridgeIoAllocateBuffer(), a failure to allocate > below 4 GB may not be an error if the IOMMU protocol instance can > provide a 32-bit addressable mapping for it. > > [Jiewen] It is a good idea to remap based upon IOMMU. > > > > However, one potential problem is that the memory size if not IOMMU page > aligned. > > In such case, PciRootBridge driver has to allocate another IOMMU page > aligned memory for DMA buffer. > > > > I believe the benefit will be got, only if the device driver who submit D= MA > request allocate IOMMU page aligned memory for DMA request. > Well, allocating memory and remapping host memory into the PCI address space are not the same thing. In the absence of concerns about isolation, I don't think it should be a problem to round up IOMMU mappings to sizes it can handle [efficiently]. > > > > > > I am aware that this complicates matters for you, but having IOMMU > support in the generic PCI host bridge driver is extremely useful for > us. I am happy to help out in any way I can. > [Jiewen] Yes, I definitely need comment for ARM/AMD/other system > architecture. > > > > > > > Thanks, > Ard.