From: gary guo <heyi.guo@linaro.org>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Heyi Guo <heyi.guo@linaro.org>,
linaro-uefi <linaro-uefi@lists.linaro.org>,
"edk2-devel@lists.01.org" <edk2-devel@lists.01.org>,
Star Zeng <star.zeng@intel.com>, Eric Dong <eric.dong@intel.com>,
Ruiyu Ni <ruiyu.ni@intel.com>,
Jason Zhang <jason.zhang@linaro.org>
Subject: Re: [RFC] MdeModulePkg/PciHostBridge: Add address translation support
Date: Wed, 20 Dec 2017 23:17:04 +0800 [thread overview]
Message-ID: <20171220151704.GA2482@iwish> (raw)
In-Reply-To: <CAKv+Gu_HXLr4rpx0TXfDk=Oj47xTvb+Vic6b7ERHVmmboKUM=w@mail.gmail.com>
On Wed, Dec 20, 2017 at 09:13:58AM +0000, Ard Biesheuvel wrote:
> Hi Heyi,
>
> On 20 December 2017 at 08:21, Heyi Guo <heyi.guo@linaro.org> wrote:
> > PCIe on some ARM platforms requires address translation, not only for
> > legacy IO access, but also for 32bit memory BAR access as well. There
> > will be "Address Translation Unit" or something similar in PCI host
> > bridges to translation CPU address to PCI address and vice versa. So
> > we think it may be useful to add address translation support to the
> > generic PCI host bridge driver.
> >
>
> I agree. While unusual on a PC, it is quite common on other
> architectures to have more complex non 1:1 topologies, which currently
> require a forked PciHostBridgeDxe driver with local changes applied.
>
> > This RFC only contains one minor change to the definition of
> > PciHostBridgeLib, and there certainly will be a lot of other changes
> > to make it work, including:
> >
> > 1. Use CPU address for GCD space add and allocate operations, instead
> > of PCI address; also IO space will be changed to memory space if
> > translation exists.
> >
>
> For I/O space, the translation should simply be applied to the I/O
> range. I don't think it makes sense to use memory space here, given
> that it is specific to architectures that lack native port I/O.
>
I made an assumption here that platforms supporting real port IO space
do not need address translation, like IA32 and X64, and port IO
translation implies the platform does not support real port IO space.
Indeed the assumption is not so "generic", so I'll agree if you
recommend to support IO to IO translation as well. But I still hope to
have IO to memory translation support in PCI host bridge driver,
rather than in CPU IO protocol, since the faked IO space might only be
used for PCI host bridge and we may have overlapping IO ranges for
each host bridge, which is compatible with PCIe specification and PCIe
ACPI description.
How about adding a flag to indicate whether port IO is translated to
real port IO space or system memory space?
Thanks and regards,
Heyi
> > 2. RootBridgeIoMemRead/Write, RootBridgeIoRead/Write need to get
> > translation of the corresponding aperture, add the translation to the
> > input address, and then call CpuIo2 protocol; IO access will also be
> > converted to memory access if IO translation exists.
> >
>
> Again, why is this necessary? A host bridge that implements a non 1:1
> translation for port I/O ranges may be part of a system that has
> native port I/O, and so the translation should be based on that.
>
> > 3. RootBridgeIoConfiguration needs to fill AddrTranslationOffset in
> > the discriptor.
> >
>
> Indeed. Note that this has been a source of much confusion lately,
> should we should discuss this carefully before spending time on an
> implementation.
>
> > If it makes sense, then I'll continue to prepare the formal patch.
> >
> > Any comments?
> >
> > Thanks,
> >
> > Gary (Heyi Guo)
> >
> > Cc: Star Zeng <star.zeng@intel.com>
> > Cc: Eric Dong <eric.dong@intel.com>
> > Cc: Ruiyu Ni <ruiyu.ni@intel.com>
> > Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> > Cc: Jason Zhang <jason.zhang@linaro.org>
> >
> > ---
> > MdeModulePkg/Include/Library/PciHostBridgeLib.h | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/MdeModulePkg/Include/Library/PciHostBridgeLib.h b/MdeModulePkg/Include/Library/PciHostBridgeLib.h
> > index d42e9ec..b9e8c0f 100644
> > --- a/MdeModulePkg/Include/Library/PciHostBridgeLib.h
> > +++ b/MdeModulePkg/Include/Library/PciHostBridgeLib.h
> > @@ -22,6 +22,7 @@
> > typedef struct {
> > UINT64 Base;
> > UINT64 Limit;
> > + UINT64 Translation;
> > } PCI_ROOT_BRIDGE_APERTURE;
> >
> > typedef struct {
> > --
> > 2.7.4
> >
next prev parent reply other threads:[~2017-12-20 15:12 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-20 8:21 [RFC] MdeModulePkg/PciHostBridge: Add address translation support Heyi Guo
2017-12-20 9:13 ` Ard Biesheuvel
2017-12-20 15:17 ` gary guo [this message]
2017-12-20 15:26 ` Ard Biesheuvel
2017-12-21 8:27 ` Guo Heyi
2017-12-21 8:32 ` Ard Biesheuvel
2017-12-21 9:14 ` Guo Heyi
2017-12-21 9:48 ` Ni, Ruiyu
2017-12-21 9:52 ` Ard Biesheuvel
2017-12-21 9:59 ` Ni, Ruiyu
2017-12-21 10:07 ` Ard Biesheuvel
2017-12-26 6:50 ` Guo Heyi
2018-01-02 7:56 ` Ni, Ruiyu
2018-01-02 15:09 ` gary guo
2017-12-21 9:43 ` Ni, Ruiyu
2017-12-21 11:32 ` Guo Heyi
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=20171220151704.GA2482@iwish \
--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