From: Guo Heyi <heyi.guo@linaro.org>
To: Laszlo Ersek <lersek@redhat.com>
Cc: Heyi Guo <heyi.guo@linaro.org>,
edk2-devel@lists.01.org, Ruiyu Ni <ruiyu.ni@intel.com>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
Star Zeng <star.zeng@intel.com>, Eric Dong <eric.dong@intel.com>,
Michael D Kinney <michael.d.kinney@intel.com>
Subject: Re: [RFC v2 2/2] MdeModulePkg/PciBus: return CPU address for GetBarAttributes
Date: Fri, 23 Feb 2018 09:10:07 +0800 [thread overview]
Message-ID: <20180223011007.GD95440@SZX1000114654> (raw)
In-Reply-To: <d9124654-f768-f815-3a06-e44bdf254793@redhat.com>
On Thu, Feb 22, 2018 at 11:41:50AM +0100, Laszlo Ersek wrote:
> On 02/22/18 07:54, Heyi Guo wrote:
> > PciIo::GetBarAttributes should return CPU view address according to
> > UEFI spec 2.7, so we change the implementation to follow the spec.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Heyi Guo <heyi.guo@linaro.org>
> > Cc: Ruiyu Ni <ruiyu.ni@intel.com>
> > Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> > Cc: Star Zeng <star.zeng@intel.com>
> > Cc: Eric Dong <eric.dong@intel.com>
> > Cc: Laszlo Ersek <lersek@redhat.com>
> > Cc: Michael D Kinney <michael.d.kinney@intel.com>
> >
> > ---
> > MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c | 9 +++++++--
> > 1 file changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c b/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c
> > index 190f4b0..0aafcba 100644
> > --- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c
> > +++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c
> > @@ -1814,8 +1814,8 @@ GetMmioAddressTranslationOffset (
> >
> > while (Configuration->Desc == ACPI_ADDRESS_SPACE_DESCRIPTOR) {
> > if ((Configuration->ResType == ACPI_ADDRESS_SPACE_TYPE_MEM) &&
> > - (Configuration->AddrRangeMin <= AddrRangeMin) &&
> > - (Configuration->AddrRangeMin + Configuration->AddrLen >= AddrRangeMin + AddrLen)
> > + (Configuration->AddrRangeMin + Configuration->AddrTranslationOffset <= AddrRangeMin) &&
> > + (Configuration->AddrRangeMin + Configuration->AddrLen + Configuration->AddrTranslationOffset >= AddrRangeMin + AddrLen)
> > ) {
> > return Configuration->AddrTranslationOffset;
> > }
> > @@ -1968,6 +1968,11 @@ PciIoGetBarAttributes (
> > return EFI_UNSUPPORTED;
> > }
> > }
> > +
> > + // According to UEFI spec 2.7, we need return CPU view address for PciIo::GetBarAttributes,
> > + // and PCI view = CPU view + translation
> > + Descriptor->AddrRangeMin -= Descriptor->AddrTranslationOffset;
> > + Descriptor->AddrRangeMax -= Descriptor->AddrTranslationOffset;
> > }
> >
> > return EFI_SUCCESS;
> >
>
> According to your blurb -- which should be instead part of the commit
> message of patch #1, as discussed before --, we have the following
> interpretations:
>
> * internal: host = device + ATO
> * external: device = host + ATO
>
> The GetMmioAddressTranslationOffset() change looks correct, because
> (according to your blurb) RootBridgeIo->Configuration() returns a host
> (CPU) view. Adding the ATO we get the device view, and then we can do
> the comparison against the BAR values read from the device. OK.
>
> In PciIoGetBarAttributes(), Descriptor->AddrRangeMin is first set from
> PciIoDevice, so it's a device view. I think the subtraction is correct;
> the caller will re-add the ATO if it wants to return to the device view.
>
> In PciIoGetBarAttributes(), I think the AddrRangeMax manipulation is
> incorrect (possibly due to a preexistent bug in PciBusDxe). Namely,
> Descriptor->AddrRangeMax is first set to the Alignment of the BAR, from
> PciIoDevice, not the end address of the BAR. In order to output the
> value required by the UEFI spec, we have to calculate the end address
> using AddrLen. Is that right?
Will double check what it really is.
>
> ... To repeat myself, I find it extremely hard to reason about this
> feature while using different internal and external ATO interpretations.
> Can we pick one formula and stick with it everywhere? (I don't insist,
> but without it, I don't think I can sensibly review future iterations of
> this set.)
I made the patch according to the conclusion here:
https://lists.01.org/pipermail/edk2-devel/2018-February/020960.html
if I understood that correctly :)
However, if it turns out so confusing in the code, especially to someone who
didn't participate in the discussions, I agree it may worth keeping all the
definitions consistent in EDK2 code, while being different from what in ACPI ASL
code.
Thanks,
Gary (Heyi Guo)
>
> Thanks
> Laszlo
next prev parent reply other threads:[~2018-02-23 1:04 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-22 6:54 [RFC v2 0/2] Add translation support to generic PCIHostBridge Heyi Guo
2018-02-22 6:54 ` [RFC v2 1/2] MdeModulePkg/PciHostBridgeDxe: Add support for address translation Heyi Guo
2018-02-22 8:55 ` Ni, Ruiyu
2018-02-22 8:56 ` Ni, Ruiyu
2018-02-22 9:43 ` Laszlo Ersek
2018-02-22 6:54 ` [RFC v2 2/2] MdeModulePkg/PciBus: return CPU address for GetBarAttributes Heyi Guo
2018-02-22 10:41 ` Laszlo Ersek
2018-02-23 1:10 ` Guo Heyi [this message]
2018-02-22 10:06 ` [RFC v2 0/2] Add translation support to generic PCIHostBridge Laszlo Ersek
2018-02-22 10: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=20180223011007.GD95440@SZX1000114654 \
--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