public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: "Yao, Jiewen" <jiewen.yao@intel.com>
Cc: "Kinney, Michael D" <michael.d.kinney@intel.com>,
	"Ni, Ruiyu" <ruiyu.ni@intel.com>, Leo Duran <leo.duran@amd.com>,
	"edk2-devel@lists.01.org" <edk2-devel@lists.01.org>,
	 Brijesh Singh <brijesh.singh@amd.com>
Subject: Re: [PATCH 1/3] MdeModulePkg/Include: Add IOMMU protocol definition.
Date: Wed, 29 Mar 2017 15:22:35 +0100	[thread overview]
Message-ID: <CAKv+Gu8EdVDEVvbbErxDB0-TTfy6WQ8QDbNqKd0EPB4jkXxd1w@mail.gmail.com> (raw)
In-Reply-To: <74D8A39837DF1E4DA445A8C0B3885C503A916565@shsmsx102.ccr.corp.intel.com>

On 29 March 2017 at 00:45, Yao, Jiewen <jiewen.yao@intel.com> 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)

So in RootBridgeIoMap(), for instance, we have this condition

  PhysicalAddress = (EFI_PHYSICAL_ADDRESS) (UINTN) HostAddress;
  if ((!RootBridge->DmaAbove4G ||
       (Operation != EfiPciOperationBusMasterRead64 &&
        Operation != EfiPciOperationBusMasterWrite64 &&
        Operation != 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.

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.

Thanks,
Ard.


  reply	other threads:[~2017-03-29 14:22 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-25  9:28 [RFC] [PATCH 0/3] Add IOMMU support Jiewen Yao
2017-03-25  9:28 ` [PATCH 1/3] MdeModulePkg/Include: Add IOMMU protocol definition Jiewen Yao
2017-03-28 22:38   ` Ard Biesheuvel
2017-03-28 23:02     ` Kinney, Michael D
2017-03-28 23:45       ` Yao, Jiewen
2017-03-29 14:22         ` Ard Biesheuvel [this message]
2017-03-30 12:37           ` Yao, Jiewen
2017-03-30 13:54             ` Ard Biesheuvel
2017-03-25  9:28 ` [RFC] [PATCH 2/3] MdeModulePkg/PciHostBridge: Add IOMMU support Jiewen Yao
2017-03-27  5:31   ` Ni, Ruiyu
2017-03-27  6:01     ` Yao, Jiewen
2017-03-27  6:18       ` Ni, Ruiyu
2017-03-27  6:23         ` Yao, Jiewen
2017-03-27  6:25           ` Ni, Ruiyu
2017-03-25  9:28 ` [RFC] [PATCH 3/3] MdeModulePkg/PciBus: " Jiewen Yao
2017-03-27  5:39   ` Ni, Ruiyu
2017-03-27  6:15     ` Yao, Jiewen
2017-03-27  6:23       ` Ni, Ruiyu
2017-03-27 19:50 ` [RFC] [PATCH 0/3] " Duran, Leo
2017-03-28  1:40   ` Yao, Jiewen
2017-03-28  1:54     ` Yao, Jiewen
2017-03-28  2:24       ` Ni, Ruiyu
2017-03-28  2:32         ` Yao, Jiewen
  -- strict thread matches above, loose matches on Subject: below --
2017-04-29 13:48 [RFC] [PATCH V4 " Jiewen Yao
2017-04-29 13:48 ` [PATCH 1/3] MdeModulePkg/Include: Add IOMMU protocol definition Jiewen Yao
2017-05-02  9:56   ` Ard Biesheuvel
2017-05-02 12:54     ` Yao, Jiewen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAKv+Gu8EdVDEVvbbErxDB0-TTfy6WQ8QDbNqKd0EPB4jkXxd1w@mail.gmail.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox