Re: [edk2] [RFC v3 1/3] MdeModulePkg/PciHostBridgeDxe: Add support for address translation

2018-02-26 Thread Guo Heyi 
Hi Laszlo,

Just a note that comment [6] has not been fully applied in my RFC v4, that I
didn't touch the outer ALIGN_VALUE() yet. As you said, it is an independent
issue and I think it can be fixed before or after my proposed change. I can do
something after Ray comments on it.

Regards,

Heyi

On Fri, Feb 23, 2018 at 04:05:17PM +0100, Laszlo Ersek wrote:
> Thanks for writing up the details!
> 
> Comments:
> 
> On 02/23/18 09:53, Heyi Guo wrote:
> > PCI address translation is necessary for some non-x86 platforms. On
> > such platforms, address value (denoted as "device address" or "address
> > in PCI view") set to PCI BAR registers in configuration space might be
> > different from the address which is used by CPU to access the
> > registers in memory BAR or IO BAR spaces (denoted as "host address" or
> > "address in CPU view"). The difference between the two addresses is
> > called "Address Translation Offset" or simply "translation", and can
> > be represented by "Address Translation Offset" in ACPI QWORD Address
> > Space Descriptor (Offset 0x1E). However UEFI and ACPI differs on the
> > definitions of QWORD Address Space Descriptor, and we will follow UEFI
> > definition on UEFI protocols, such as PCI root bridge IO protocol and
> > PCI IO protocol. In UEFI 2.7, "Address Translation Offset" is "Offset
> > to apply to the Starting address to convert it to a PCI address". This
> > means:
> >
> > 1. Translation = device address - host address.
> 
> OK, this looks like a sensible choice to me. It means that the "apply"
> term used in the UEFI spec means "add", which (I think) is the "natural"
> interpretation.
> 
> > 2. PciRootBridgeIo->Configuration should return CPU view address, as
> > well as PciIo->GetBarAttributes.
> 
> OK.
> 
> >
> > Summary of addresses used:
> >
> > 1. Base and Limit in PCI_ROOT_BRIDGE_APERTURE are device address, for
> > it is easy to check whether the address is below 4G or above 4G.
> 
> I agree that PciHostBridgeLib instances that do not set a nonzero
> Translation need not care about the difference.
> 
> (1) Still, can you confirm this is a "natural" choice? Were the
> DmaAbove4G, MemAbove4G and PMemAbove4G fields originally introduced with
> the device (PCI) view in mind?
> 
> ... I also meant to raise a concern about the InitializePciHostBridge()
> function where we call AddIoSpace() and AddMemoryMappedIoSpace() --
> which end up manipulating GCD -- with data from
> PCI_ROOT_BRIDGE_APERTURE. I can see you modify those call sites in the
> patch, so that's good. (I do have more comments on the actual
> implementation.)
> 
> >
> > 2. Address returned by
> > EFI_PCI_HOST_BRIDGE_RESOURCE_ALLOCATION_PROTOCOL::GetProposedResources
> > is device address, or else PCI bus driver cannot set correct address
> > into PCI BAR registers.
> >
> > 3. Address returned by PciRootBridgeIo->Configuration is host address
> > per UEFI 2.7 definition.
> >
> > 4. Addresses used in GCD manipulation are host address.
> >
> > 5. Addresses in ResAllocNode of PCI_ROOT_BRIDGE_INSTANCE are host
> > address, for they are allocated from GCD.
> >
> > 6. Address passed to PciHostBridgeResourceConflict is host address,
> > for it comes from ResAllocNode.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Heyi Guo 
> > Cc: Ruiyu Ni 
> > Cc: Ard Biesheuvel 
> > Cc: Star Zeng 
> > Cc: Eric Dong 
> > Cc: Laszlo Ersek 
> > Cc: Michael D Kinney 
> > ---
> >  .../Bus/Pci/PciHostBridgeDxe/PciHostBridge.c   |  74 +++---
> >  .../Bus/Pci/PciHostBridgeDxe/PciHostResource.h |   2 +
> >  .../Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c | 112 
> > ++---
> >  MdeModulePkg/Include/Library/PciHostBridgeLib.h|   8 ++
> >  4 files changed, 167 insertions(+), 29 deletions(-)
> >
> > diff --git a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c 
> > b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
> > index 1494848..e8979eb 100644
> > --- a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
> > +++ b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
> > @@ -32,6 +32,29 @@ EDKII_IOMMU_PROTOCOL*mIoMmuProtocol;
> >  EFI_EVENT   mIoMmuEvent;
> >  VOID*mIoMmuRegistration;
> >
> > +STATIC
> > +UINT64
> > +GetTranslationByResourceType (
> > +  IN  PCI_ROOT_BRIDGE_INSTANCE *RootBridge,
> > +  IN  PCI_RESOURCE_TYPEResourceType
> > +  )
> > +{
> > +  switch (ResourceType) {
> > +case TypeIo:
> > +  return RootBridge->Io.Translation;
> > +case TypeMem32:
> > +  return RootBridge->Mem.Translation;
> > +case TypePMem32:
> > +  return RootBridge->PMem.Translation;
> > +case TypeMem64:
> > +  return RootBridge->MemAbove4G.Translation;
> > +case TypePMem64:
> > +  return

Re: [edk2] [RFC v3 1/3] MdeModulePkg/PciHostBridgeDxe: Add support for address translation

2018-02-24 Thread Guo Heyi 
On Sat, Feb 24, 2018 at 04:30:42PM +0800, Ni, Ruiyu wrote:
> On 2/24/2018 11:59 AM, Guo Heyi wrote:
> >On Sat, Feb 24, 2018 at 11:11:35AM +0800, Ni, Ruiyu wrote:
> >>On 2/24/2018 9:51 AM, Guo Heyi wrote:
> >>>On Fri, Feb 23, 2018 at 04:05:17PM +0100, Laszlo Ersek wrote:
> Thanks for writing up the details!
> 
> Comments:
> 
> On 02/23/18 09:53, Heyi Guo wrote:
> >PCI address translation is necessary for some non-x86 platforms. On
> >such platforms, address value (denoted as "device address" or "address
> >in PCI view") set to PCI BAR registers in configuration space might be
> >different from the address which is used by CPU to access the
> >registers in memory BAR or IO BAR spaces (denoted as "host address" or
> >"address in CPU view"). The difference between the two addresses is
> >called "Address Translation Offset" or simply "translation", and can
> >be represented by "Address Translation Offset" in ACPI QWORD Address
> >Space Descriptor (Offset 0x1E). However UEFI and ACPI differs on the
> >definitions of QWORD Address Space Descriptor, and we will follow UEFI
> >definition on UEFI protocols, such as PCI root bridge IO protocol and
> >PCI IO protocol. In UEFI 2.7, "Address Translation Offset" is "Offset
> >to apply to the Starting address to convert it to a PCI address". This
> >means:
> >
> >1. Translation = device address - host address.
> 
> OK, this looks like a sensible choice to me. It means that the "apply"
> term used in the UEFI spec means "add", which (I think) is the "natural"
> interpretation.
> 
> >2. PciRootBridgeIo->Configuration should return CPU view address, as
> >well as PciIo->GetBarAttributes.
> 
> OK.
> 
> >
> >Summary of addresses used:
> >
> >1. Base and Limit in PCI_ROOT_BRIDGE_APERTURE are device address, for
> >it is easy to check whether the address is below 4G or above 4G.
> 
> I agree that PciHostBridgeLib instances that do not set a nonzero
> Translation need not care about the difference.
> 
> (1) Still, can you confirm this is a "natural" choice? Were the
> DmaAbove4G, MemAbove4G and PMemAbove4G fields originally introduced with
> the device (PCI) view in mind?
> 
> ... I also meant to raise a concern about the InitializePciHostBridge()
> function where we call AddIoSpace() and AddMemoryMappedIoSpace() --
> which end up manipulating GCD -- with data from
> PCI_ROOT_BRIDGE_APERTURE. I can see you modify those call sites in the
> patch, so that's good. (I do have more comments on the actual
> implementation.)
> >>DmaAbove4G in PCI_ROOT_BRIDGE_APERTURE indicates the capability of
> >>the root bridge HW, whether it's capable to do DMA on device address
> >>above 4GB.
> >>
> 
> >
> >2. Address returned by
> >EFI_PCI_HOST_BRIDGE_RESOURCE_ALLOCATION_PROTOCOL::GetProposedResources
> >is device address, or else PCI bus driver cannot set correct address
> >into PCI BAR registers.
> >
> >3. Address returned by PciRootBridgeIo->Configuration is host address
> >per UEFI 2.7 definition.
> >
> >4. Addresses used in GCD manipulation are host address.
> >
> >5. Addresses in ResAllocNode of PCI_ROOT_BRIDGE_INSTANCE are host
> >address, for they are allocated from GCD.
> >
> >6. Address passed to PciHostBridgeResourceConflict is host address,
> >for it comes from ResAllocNode.
> >
> >Contributed-under: TianoCore Contribution Agreement 1.1
> >Signed-off-by: Heyi Guo 
> >Cc: Ruiyu Ni 
> >Cc: Ard Biesheuvel 
> >Cc: Star Zeng 
> >Cc: Eric Dong 
> >Cc: Laszlo Ersek 
> >Cc: Michael D Kinney 
> >---
> >  .../Bus/Pci/PciHostBridgeDxe/PciHostBridge.c   |  74 +++---
> >  .../Bus/Pci/PciHostBridgeDxe/PciHostResource.h |   2 +
> >  .../Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c | 112 
> > ++---
> >  MdeModulePkg/Include/Library/PciHostBridgeLib.h|   8 ++
> >  4 files changed, 167 insertions(+), 29 deletions(-)
> >
> >diff --git a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c 
> >b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
> >index 1494848..e8979eb 100644
> >--- a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
> >+++ b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
> >@@ -32,6 +32,29 @@ EDKII_IOMMU_PROTOCOL*mIoMmuProtocol;
> >  EFI_EVENT   mIoMmuEvent;
> >  VOID*mIoMmuRegistration;
> >
> >+STATIC
> >+UINT64
> >+GetTranslationByResourceType (
> >+  IN  PCI_ROOT_BRIDGE_INSTANCE *RootBridge,
> >+  IN  PCI_RESOURCE_TYPE

Re: [edk2] [RFC v3 1/3] MdeModulePkg/PciHostBridgeDxe: Add support for address translation

2018-02-24 Thread Ni, Ruiyu 

On 2/24/2018 11:59 AM, Guo Heyi wrote:

On Sat, Feb 24, 2018 at 11:11:35AM +0800, Ni, Ruiyu wrote:

On 2/24/2018 9:51 AM, Guo Heyi wrote:

On Fri, Feb 23, 2018 at 04:05:17PM +0100, Laszlo Ersek wrote:

Thanks for writing up the details!

Comments:

On 02/23/18 09:53, Heyi Guo wrote:

PCI address translation is necessary for some non-x86 platforms. On
such platforms, address value (denoted as "device address" or "address
in PCI view") set to PCI BAR registers in configuration space might be
different from the address which is used by CPU to access the
registers in memory BAR or IO BAR spaces (denoted as "host address" or
"address in CPU view"). The difference between the two addresses is
called "Address Translation Offset" or simply "translation", and can
be represented by "Address Translation Offset" in ACPI QWORD Address
Space Descriptor (Offset 0x1E). However UEFI and ACPI differs on the
definitions of QWORD Address Space Descriptor, and we will follow UEFI
definition on UEFI protocols, such as PCI root bridge IO protocol and
PCI IO protocol. In UEFI 2.7, "Address Translation Offset" is "Offset
to apply to the Starting address to convert it to a PCI address". This
means:

1. Translation = device address - host address.


OK, this looks like a sensible choice to me. It means that the "apply"
term used in the UEFI spec means "add", which (I think) is the "natural"
interpretation.


2. PciRootBridgeIo->Configuration should return CPU view address, as
well as PciIo->GetBarAttributes.


OK.



Summary of addresses used:

1. Base and Limit in PCI_ROOT_BRIDGE_APERTURE are device address, for
it is easy to check whether the address is below 4G or above 4G.


I agree that PciHostBridgeLib instances that do not set a nonzero
Translation need not care about the difference.

(1) Still, can you confirm this is a "natural" choice? Were the
DmaAbove4G, MemAbove4G and PMemAbove4G fields originally introduced with
the device (PCI) view in mind?

... I also meant to raise a concern about the InitializePciHostBridge()
function where we call AddIoSpace() and AddMemoryMappedIoSpace() --
which end up manipulating GCD -- with data from
PCI_ROOT_BRIDGE_APERTURE. I can see you modify those call sites in the
patch, so that's good. (I do have more comments on the actual
implementation.)

DmaAbove4G in PCI_ROOT_BRIDGE_APERTURE indicates the capability of
the root bridge HW, whether it's capable to do DMA on device address
above 4GB.





2. Address returned by
EFI_PCI_HOST_BRIDGE_RESOURCE_ALLOCATION_PROTOCOL::GetProposedResources
is device address, or else PCI bus driver cannot set correct address
into PCI BAR registers.

3. Address returned by PciRootBridgeIo->Configuration is host address
per UEFI 2.7 definition.

4. Addresses used in GCD manipulation are host address.

5. Addresses in ResAllocNode of PCI_ROOT_BRIDGE_INSTANCE are host
address, for they are allocated from GCD.

6. Address passed to PciHostBridgeResourceConflict is host address,
for it comes from ResAllocNode.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Heyi Guo 
Cc: Ruiyu Ni 
Cc: Ard Biesheuvel 
Cc: Star Zeng 
Cc: Eric Dong 
Cc: Laszlo Ersek 
Cc: Michael D Kinney 
---
  .../Bus/Pci/PciHostBridgeDxe/PciHostBridge.c   |  74 +++---
  .../Bus/Pci/PciHostBridgeDxe/PciHostResource.h |   2 +
  .../Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c | 112 ++---
  MdeModulePkg/Include/Library/PciHostBridgeLib.h|   8 ++
  4 files changed, 167 insertions(+), 29 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c 
b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
index 1494848..e8979eb 100644
--- a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
+++ b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
@@ -32,6 +32,29 @@ EDKII_IOMMU_PROTOCOL*mIoMmuProtocol;
  EFI_EVENT   mIoMmuEvent;
  VOID*mIoMmuRegistration;

+STATIC
+UINT64
+GetTranslationByResourceType (
+  IN  PCI_ROOT_BRIDGE_INSTANCE *RootBridge,
+  IN  PCI_RESOURCE_TYPEResourceType
+  )
+{
+  switch (ResourceType) {
+case TypeIo:
+  return RootBridge->Io.Translation;
+case TypeMem32:
+  return RootBridge->Mem.Translation;
+case TypePMem32:
+  return RootBridge->PMem.Translation;
+case TypeMem64:
+  return RootBridge->MemAbove4G.Translation;
+case TypePMem64:
+  return RootBridge->PMemAbove4G.Translation;
+default:


(2) How about we return zero for TypeBus, explicitly, and then
ASSERT(FALSE) and return zero for "default"?


+  return 0;
+  }
+}
+
  /**
Ensure the compatibility of an IO space descriptor with the IO aperture.

@@ -411,8 +434,12 @@ InitializePciHostBridge (
  }

  if (RootBridges[Index].Io.Base <= RootBridges[Index].Io.Limit) {

Re: [edk2] [RFC v3 1/3] MdeModulePkg/PciHostBridgeDxe: Add support for address translation

2018-02-24 Thread Ard Biesheuvel 
On 24 February 2018 at 03:11, Ni, Ruiyu  wrote:
...
>>> (6) For all of these, I believe that we have to think about the corner
>>> case when the Translation value is not a multiple of (Alignment + 1).
>>>
>>> "Alignment" comes from the PCI BAR in question, whereas Base comes from
>>> the platform PciHostBridgeLib. I think these are fairly independent (you
>>> can plug a 3rd party, discrete PCI card into a board). I find it
>>> plausible that the card has such a huge MMIO BAR (and alignment) that
>>> the platform's Translation offset is not a multiple thereof.
>>>
>>> So, which "view" has to be aligned here? The PCI (device) view, or the
>>> host (CPU) view?
>>
>>
>> I believe the alignment requirement is from PCI view, not the CPU view.
>> This
>> also implies alignment in allocating GCD resources becomes meaningless.
>
> I agree. It's an issue we need to think about.
>
> All address spaces in GCD are added by gDS->AddXXX().
> So it means for a given range of address [HostBase, HostLimit) in GCD,
> the corresponding device address is
> [HostBase + Offset, HostLimit + Offset).
> E.g.: GCD entry = [0xFFD, 0x3FFD), Offset = 0x3
> The corresponding device address range is [0x1000, 0x4000)
> If we want to allocate 3 page-aligned pages of MMIO from GCD,
> current AllocateResource() implementation will fail to allocate.
>
> What will the Offset be in real world?
> If it's quite small (smaller than device required alignment),
> thing becomes complicated. I even cannot think of any solution.
> If it's quite large (larger than device required alignment),
> thing becomes easy. Today's implementation can handle it well.
>

I see two typical use cases for this address translation feature:
- adding an address offset to TypeTranslation I/O range, i.e., two RCs
both using 0x0-0x on the PCI side, but requiring non-overlapping
memory ranges on the CPU side (this is a limitation in the ACPI spec,
where an I/O range cannot be subject to address translation and type
translation at the same time)
- mapping a MMIO32 range high in the CPU address space

In both cases, I think it is reasonable as an implementation
requirement that the translation is sufficiently aligned, maybe even
to the size of the entire window.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [RFC v3 1/3] MdeModulePkg/PciHostBridgeDxe: Add support for address translation

2018-02-23 Thread Guo Heyi 
On Sat, Feb 24, 2018 at 11:11:35AM +0800, Ni, Ruiyu wrote:
> On 2/24/2018 9:51 AM, Guo Heyi wrote:
> >On Fri, Feb 23, 2018 at 04:05:17PM +0100, Laszlo Ersek wrote:
> >>Thanks for writing up the details!
> >>
> >>Comments:
> >>
> >>On 02/23/18 09:53, Heyi Guo wrote:
> >>>PCI address translation is necessary for some non-x86 platforms. On
> >>>such platforms, address value (denoted as "device address" or "address
> >>>in PCI view") set to PCI BAR registers in configuration space might be
> >>>different from the address which is used by CPU to access the
> >>>registers in memory BAR or IO BAR spaces (denoted as "host address" or
> >>>"address in CPU view"). The difference between the two addresses is
> >>>called "Address Translation Offset" or simply "translation", and can
> >>>be represented by "Address Translation Offset" in ACPI QWORD Address
> >>>Space Descriptor (Offset 0x1E). However UEFI and ACPI differs on the
> >>>definitions of QWORD Address Space Descriptor, and we will follow UEFI
> >>>definition on UEFI protocols, such as PCI root bridge IO protocol and
> >>>PCI IO protocol. In UEFI 2.7, "Address Translation Offset" is "Offset
> >>>to apply to the Starting address to convert it to a PCI address". This
> >>>means:
> >>>
> >>>1. Translation = device address - host address.
> >>
> >>OK, this looks like a sensible choice to me. It means that the "apply"
> >>term used in the UEFI spec means "add", which (I think) is the "natural"
> >>interpretation.
> >>
> >>>2. PciRootBridgeIo->Configuration should return CPU view address, as
> >>>well as PciIo->GetBarAttributes.
> >>
> >>OK.
> >>
> >>>
> >>>Summary of addresses used:
> >>>
> >>>1. Base and Limit in PCI_ROOT_BRIDGE_APERTURE are device address, for
> >>>it is easy to check whether the address is below 4G or above 4G.
> >>
> >>I agree that PciHostBridgeLib instances that do not set a nonzero
> >>Translation need not care about the difference.
> >>
> >>(1) Still, can you confirm this is a "natural" choice? Were the
> >>DmaAbove4G, MemAbove4G and PMemAbove4G fields originally introduced with
> >>the device (PCI) view in mind?
> >>
> >>... I also meant to raise a concern about the InitializePciHostBridge()
> >>function where we call AddIoSpace() and AddMemoryMappedIoSpace() --
> >>which end up manipulating GCD -- with data from
> >>PCI_ROOT_BRIDGE_APERTURE. I can see you modify those call sites in the
> >>patch, so that's good. (I do have more comments on the actual
> >>implementation.)
> DmaAbove4G in PCI_ROOT_BRIDGE_APERTURE indicates the capability of
> the root bridge HW, whether it's capable to do DMA on device address
> above 4GB.
> 
> >>
> >>>
> >>>2. Address returned by
> >>>EFI_PCI_HOST_BRIDGE_RESOURCE_ALLOCATION_PROTOCOL::GetProposedResources
> >>>is device address, or else PCI bus driver cannot set correct address
> >>>into PCI BAR registers.
> >>>
> >>>3. Address returned by PciRootBridgeIo->Configuration is host address
> >>>per UEFI 2.7 definition.
> >>>
> >>>4. Addresses used in GCD manipulation are host address.
> >>>
> >>>5. Addresses in ResAllocNode of PCI_ROOT_BRIDGE_INSTANCE are host
> >>>address, for they are allocated from GCD.
> >>>
> >>>6. Address passed to PciHostBridgeResourceConflict is host address,
> >>>for it comes from ResAllocNode.
> >>>
> >>>Contributed-under: TianoCore Contribution Agreement 1.1
> >>>Signed-off-by: Heyi Guo 
> >>>Cc: Ruiyu Ni 
> >>>Cc: Ard Biesheuvel 
> >>>Cc: Star Zeng 
> >>>Cc: Eric Dong 
> >>>Cc: Laszlo Ersek 
> >>>Cc: Michael D Kinney 
> >>>---
> >>>  .../Bus/Pci/PciHostBridgeDxe/PciHostBridge.c   |  74 +++---
> >>>  .../Bus/Pci/PciHostBridgeDxe/PciHostResource.h |   2 +
> >>>  .../Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c | 112 
> >>> ++---
> >>>  MdeModulePkg/Include/Library/PciHostBridgeLib.h|   8 ++
> >>>  4 files changed, 167 insertions(+), 29 deletions(-)
> >>>
> >>>diff --git a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c 
> >>>b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
> >>>index 1494848..e8979eb 100644
> >>>--- a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
> >>>+++ b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
> >>>@@ -32,6 +32,29 @@ EDKII_IOMMU_PROTOCOL*mIoMmuProtocol;
> >>>  EFI_EVENT   mIoMmuEvent;
> >>>  VOID*mIoMmuRegistration;
> >>>
> >>>+STATIC
> >>>+UINT64
> >>>+GetTranslationByResourceType (
> >>>+  IN  PCI_ROOT_BRIDGE_INSTANCE *RootBridge,
> >>>+  IN  PCI_RESOURCE_TYPEResourceType
> >>>+  )
> >>>+{
> >>>+  switch (ResourceType) {
> >>>+case TypeIo:
> >>>+  return RootBridge->Io.Translation;
> >>>+case TypeMem32:
> >>>+  return RootBridge->Mem.Translation;
> >>>+case TypePMem32:
> >>>+  return RootBridge->PMem.Translation;
> >>>+case TypeMem64:
> >>>+

Re: [edk2] [RFC v3 1/3] MdeModulePkg/PciHostBridgeDxe: Add support for address translation

2018-02-23 Thread Ni, Ruiyu 

On 2/24/2018 9:51 AM, Guo Heyi wrote:

On Fri, Feb 23, 2018 at 04:05:17PM +0100, Laszlo Ersek wrote:

Thanks for writing up the details!

Comments:

On 02/23/18 09:53, Heyi Guo wrote:

PCI address translation is necessary for some non-x86 platforms. On
such platforms, address value (denoted as "device address" or "address
in PCI view") set to PCI BAR registers in configuration space might be
different from the address which is used by CPU to access the
registers in memory BAR or IO BAR spaces (denoted as "host address" or
"address in CPU view"). The difference between the two addresses is
called "Address Translation Offset" or simply "translation", and can
be represented by "Address Translation Offset" in ACPI QWORD Address
Space Descriptor (Offset 0x1E). However UEFI and ACPI differs on the
definitions of QWORD Address Space Descriptor, and we will follow UEFI
definition on UEFI protocols, such as PCI root bridge IO protocol and
PCI IO protocol. In UEFI 2.7, "Address Translation Offset" is "Offset
to apply to the Starting address to convert it to a PCI address". This
means:

1. Translation = device address - host address.


OK, this looks like a sensible choice to me. It means that the "apply"
term used in the UEFI spec means "add", which (I think) is the "natural"
interpretation.


2. PciRootBridgeIo->Configuration should return CPU view address, as
well as PciIo->GetBarAttributes.


OK.



Summary of addresses used:

1. Base and Limit in PCI_ROOT_BRIDGE_APERTURE are device address, for
it is easy to check whether the address is below 4G or above 4G.


I agree that PciHostBridgeLib instances that do not set a nonzero
Translation need not care about the difference.

(1) Still, can you confirm this is a "natural" choice? Were the
DmaAbove4G, MemAbove4G and PMemAbove4G fields originally introduced with
the device (PCI) view in mind?

... I also meant to raise a concern about the InitializePciHostBridge()
function where we call AddIoSpace() and AddMemoryMappedIoSpace() --
which end up manipulating GCD -- with data from
PCI_ROOT_BRIDGE_APERTURE. I can see you modify those call sites in the
patch, so that's good. (I do have more comments on the actual
implementation.)

DmaAbove4G in PCI_ROOT_BRIDGE_APERTURE indicates the capability of
the root bridge HW, whether it's capable to do DMA on device address
above 4GB.





2. Address returned by
EFI_PCI_HOST_BRIDGE_RESOURCE_ALLOCATION_PROTOCOL::GetProposedResources
is device address, or else PCI bus driver cannot set correct address
into PCI BAR registers.

3. Address returned by PciRootBridgeIo->Configuration is host address
per UEFI 2.7 definition.

4. Addresses used in GCD manipulation are host address.

5. Addresses in ResAllocNode of PCI_ROOT_BRIDGE_INSTANCE are host
address, for they are allocated from GCD.

6. Address passed to PciHostBridgeResourceConflict is host address,
for it comes from ResAllocNode.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Heyi Guo 
Cc: Ruiyu Ni 
Cc: Ard Biesheuvel 
Cc: Star Zeng 
Cc: Eric Dong 
Cc: Laszlo Ersek 
Cc: Michael D Kinney 
---
  .../Bus/Pci/PciHostBridgeDxe/PciHostBridge.c   |  74 +++---
  .../Bus/Pci/PciHostBridgeDxe/PciHostResource.h |   2 +
  .../Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c | 112 ++---
  MdeModulePkg/Include/Library/PciHostBridgeLib.h|   8 ++
  4 files changed, 167 insertions(+), 29 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c 
b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
index 1494848..e8979eb 100644
--- a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
+++ b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
@@ -32,6 +32,29 @@ EDKII_IOMMU_PROTOCOL*mIoMmuProtocol;
  EFI_EVENT   mIoMmuEvent;
  VOID*mIoMmuRegistration;

+STATIC
+UINT64
+GetTranslationByResourceType (
+  IN  PCI_ROOT_BRIDGE_INSTANCE *RootBridge,
+  IN  PCI_RESOURCE_TYPEResourceType
+  )
+{
+  switch (ResourceType) {
+case TypeIo:
+  return RootBridge->Io.Translation;
+case TypeMem32:
+  return RootBridge->Mem.Translation;
+case TypePMem32:
+  return RootBridge->PMem.Translation;
+case TypeMem64:
+  return RootBridge->MemAbove4G.Translation;
+case TypePMem64:
+  return RootBridge->PMemAbove4G.Translation;
+default:


(2) How about we return zero for TypeBus, explicitly, and then
ASSERT(FALSE) and return zero for "default"?


+  return 0;
+  }
+}
+
  /**
Ensure the compatibility of an IO space descriptor with the IO aperture.

@@ -411,8 +434,12 @@ InitializePciHostBridge (
  }

  if (RootBridges[Index].Io.Base <= RootBridges[Index].Io.Limit) {
+  // Base and Limit in PCI_ROOT_BRIDGE_APERTURE are device address.
+  // According to

Re: [edk2] [RFC v3 1/3] MdeModulePkg/PciHostBridgeDxe: Add support for address translation

2018-02-23 Thread Guo Heyi 
On Fri, Feb 23, 2018 at 04:05:17PM +0100, Laszlo Ersek wrote:
> Thanks for writing up the details!
> 
> Comments:
> 
> On 02/23/18 09:53, Heyi Guo wrote:
> > PCI address translation is necessary for some non-x86 platforms. On
> > such platforms, address value (denoted as "device address" or "address
> > in PCI view") set to PCI BAR registers in configuration space might be
> > different from the address which is used by CPU to access the
> > registers in memory BAR or IO BAR spaces (denoted as "host address" or
> > "address in CPU view"). The difference between the two addresses is
> > called "Address Translation Offset" or simply "translation", and can
> > be represented by "Address Translation Offset" in ACPI QWORD Address
> > Space Descriptor (Offset 0x1E). However UEFI and ACPI differs on the
> > definitions of QWORD Address Space Descriptor, and we will follow UEFI
> > definition on UEFI protocols, such as PCI root bridge IO protocol and
> > PCI IO protocol. In UEFI 2.7, "Address Translation Offset" is "Offset
> > to apply to the Starting address to convert it to a PCI address". This
> > means:
> >
> > 1. Translation = device address - host address.
> 
> OK, this looks like a sensible choice to me. It means that the "apply"
> term used in the UEFI spec means "add", which (I think) is the "natural"
> interpretation.
> 
> > 2. PciRootBridgeIo->Configuration should return CPU view address, as
> > well as PciIo->GetBarAttributes.
> 
> OK.
> 
> >
> > Summary of addresses used:
> >
> > 1. Base and Limit in PCI_ROOT_BRIDGE_APERTURE are device address, for
> > it is easy to check whether the address is below 4G or above 4G.
> 
> I agree that PciHostBridgeLib instances that do not set a nonzero
> Translation need not care about the difference.
> 
> (1) Still, can you confirm this is a "natural" choice? Were the
> DmaAbove4G, MemAbove4G and PMemAbove4G fields originally introduced with
> the device (PCI) view in mind?
> 
> ... I also meant to raise a concern about the InitializePciHostBridge()
> function where we call AddIoSpace() and AddMemoryMappedIoSpace() --
> which end up manipulating GCD -- with data from
> PCI_ROOT_BRIDGE_APERTURE. I can see you modify those call sites in the
> patch, so that's good. (I do have more comments on the actual
> implementation.)
> 
> >
> > 2. Address returned by
> > EFI_PCI_HOST_BRIDGE_RESOURCE_ALLOCATION_PROTOCOL::GetProposedResources
> > is device address, or else PCI bus driver cannot set correct address
> > into PCI BAR registers.
> >
> > 3. Address returned by PciRootBridgeIo->Configuration is host address
> > per UEFI 2.7 definition.
> >
> > 4. Addresses used in GCD manipulation are host address.
> >
> > 5. Addresses in ResAllocNode of PCI_ROOT_BRIDGE_INSTANCE are host
> > address, for they are allocated from GCD.
> >
> > 6. Address passed to PciHostBridgeResourceConflict is host address,
> > for it comes from ResAllocNode.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Heyi Guo 
> > Cc: Ruiyu Ni 
> > Cc: Ard Biesheuvel 
> > Cc: Star Zeng 
> > Cc: Eric Dong 
> > Cc: Laszlo Ersek 
> > Cc: Michael D Kinney 
> > ---
> >  .../Bus/Pci/PciHostBridgeDxe/PciHostBridge.c   |  74 +++---
> >  .../Bus/Pci/PciHostBridgeDxe/PciHostResource.h |   2 +
> >  .../Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c | 112 
> > ++---
> >  MdeModulePkg/Include/Library/PciHostBridgeLib.h|   8 ++
> >  4 files changed, 167 insertions(+), 29 deletions(-)
> >
> > diff --git a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c 
> > b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
> > index 1494848..e8979eb 100644
> > --- a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
> > +++ b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
> > @@ -32,6 +32,29 @@ EDKII_IOMMU_PROTOCOL*mIoMmuProtocol;
> >  EFI_EVENT   mIoMmuEvent;
> >  VOID*mIoMmuRegistration;
> >
> > +STATIC
> > +UINT64
> > +GetTranslationByResourceType (
> > +  IN  PCI_ROOT_BRIDGE_INSTANCE *RootBridge,
> > +  IN  PCI_RESOURCE_TYPEResourceType
> > +  )
> > +{
> > +  switch (ResourceType) {
> > +case TypeIo:
> > +  return RootBridge->Io.Translation;
> > +case TypeMem32:
> > +  return RootBridge->Mem.Translation;
> > +case TypePMem32:
> > +  return RootBridge->PMem.Translation;
> > +case TypeMem64:
> > +  return RootBridge->MemAbove4G.Translation;
> > +case TypePMem64:
> > +  return RootBridge->PMemAbove4G.Translation;
> > +default:
> 
> (2) How about we return zero for TypeBus, explicitly, and then
> ASSERT(FALSE) and return zero for "default"?
> 
> > +  return 0;
> > +  }
> > +}
> > +
> >  /**
> >Ensure the compatibility of an IO space descriptor with the IO aperture.
> >
> > @@ -411,8

Re: [edk2] [RFC v3 1/3] MdeModulePkg/PciHostBridgeDxe: Add support for address translation

2018-02-23 Thread Guo Heyi 
On Fri, Feb 23, 2018 at 04:05:17PM +0100, Laszlo Ersek wrote:
> Thanks for writing up the details!
> 
> Comments:
> 
> On 02/23/18 09:53, Heyi Guo wrote:
> > PCI address translation is necessary for some non-x86 platforms. On
> > such platforms, address value (denoted as "device address" or "address
> > in PCI view") set to PCI BAR registers in configuration space might be
> > different from the address which is used by CPU to access the
> > registers in memory BAR or IO BAR spaces (denoted as "host address" or
> > "address in CPU view"). The difference between the two addresses is
> > called "Address Translation Offset" or simply "translation", and can
> > be represented by "Address Translation Offset" in ACPI QWORD Address
> > Space Descriptor (Offset 0x1E). However UEFI and ACPI differs on the
> > definitions of QWORD Address Space Descriptor, and we will follow UEFI
> > definition on UEFI protocols, such as PCI root bridge IO protocol and
> > PCI IO protocol. In UEFI 2.7, "Address Translation Offset" is "Offset
> > to apply to the Starting address to convert it to a PCI address". This
> > means:
> >
> > 1. Translation = device address - host address.
> 
> OK, this looks like a sensible choice to me. It means that the "apply"
> term used in the UEFI spec means "add", which (I think) is the "natural"
> interpretation.
> 
> > 2. PciRootBridgeIo->Configuration should return CPU view address, as
> > well as PciIo->GetBarAttributes.
> 
> OK.
> 
> >
> > Summary of addresses used:
> >
> > 1. Base and Limit in PCI_ROOT_BRIDGE_APERTURE are device address, for
> > it is easy to check whether the address is below 4G or above 4G.
> 
> I agree that PciHostBridgeLib instances that do not set a nonzero
> Translation need not care about the difference.
> 
> (1) Still, can you confirm this is a "natural" choice? Were the
> DmaAbove4G, MemAbove4G and PMemAbove4G fields originally introduced with
> the device (PCI) view in mind?
> 
> ... I also meant to raise a concern about the InitializePciHostBridge()
> function where we call AddIoSpace() and AddMemoryMappedIoSpace() --
> which end up manipulating GCD -- with data from
> PCI_ROOT_BRIDGE_APERTURE. I can see you modify those call sites in the
> patch, so that's good. (I do have more comments on the actual
> implementation.)
> 
> >
> > 2. Address returned by
> > EFI_PCI_HOST_BRIDGE_RESOURCE_ALLOCATION_PROTOCOL::GetProposedResources
> > is device address, or else PCI bus driver cannot set correct address
> > into PCI BAR registers.
> >
> > 3. Address returned by PciRootBridgeIo->Configuration is host address
> > per UEFI 2.7 definition.
> >
> > 4. Addresses used in GCD manipulation are host address.
> >
> > 5. Addresses in ResAllocNode of PCI_ROOT_BRIDGE_INSTANCE are host
> > address, for they are allocated from GCD.
> >
> > 6. Address passed to PciHostBridgeResourceConflict is host address,
> > for it comes from ResAllocNode.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Heyi Guo 
> > Cc: Ruiyu Ni 
> > Cc: Ard Biesheuvel 
> > Cc: Star Zeng 
> > Cc: Eric Dong 
> > Cc: Laszlo Ersek 
> > Cc: Michael D Kinney 
> > ---
> >  .../Bus/Pci/PciHostBridgeDxe/PciHostBridge.c   |  74 +++---
> >  .../Bus/Pci/PciHostBridgeDxe/PciHostResource.h |   2 +
> >  .../Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c | 112 
> > ++---
> >  MdeModulePkg/Include/Library/PciHostBridgeLib.h|   8 ++
> >  4 files changed, 167 insertions(+), 29 deletions(-)
> >
> > diff --git a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c 
> > b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
> > index 1494848..e8979eb 100644
> > --- a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
> > +++ b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
> > @@ -32,6 +32,29 @@ EDKII_IOMMU_PROTOCOL*mIoMmuProtocol;
> >  EFI_EVENT   mIoMmuEvent;
> >  VOID*mIoMmuRegistration;
> >
> > +STATIC
> > +UINT64
> > +GetTranslationByResourceType (
> > +  IN  PCI_ROOT_BRIDGE_INSTANCE *RootBridge,
> > +  IN  PCI_RESOURCE_TYPEResourceType
> > +  )
> > +{
> > +  switch (ResourceType) {
> > +case TypeIo:
> > +  return RootBridge->Io.Translation;
> > +case TypeMem32:
> > +  return RootBridge->Mem.Translation;
> > +case TypePMem32:
> > +  return RootBridge->PMem.Translation;
> > +case TypeMem64:
> > +  return RootBridge->MemAbove4G.Translation;
> > +case TypePMem64:
> > +  return RootBridge->PMemAbove4G.Translation;
> > +default:
> 
> (2) How about we return zero for TypeBus, explicitly, and then
> ASSERT(FALSE) and return zero for "default"?
> 
> > +  return 0;
> > +  }
> > +}
> > +
> >  /**
> >Ensure the compatibility of an IO space descriptor with the IO aperture.
> >
> > @@ -411,8

Re: [edk2] [RFC v3 1/3] MdeModulePkg/PciHostBridgeDxe: Add support for address translation

2018-02-23 Thread Laszlo Ersek 
On 02/23/18 16:17, Ard Biesheuvel wrote:
> On 23 February 2018 at 15:05, Laszlo Ersek  wrote:

>> (3) In general, the comment style requires comments like this:
>>
>>   //
>>   // Add empty comment lines both before and after.
>>   //
>>
> 
> Quite the opposite, in fact. Search for 'horror vacui' in the coding
> style document.

Right, I remember that. But, I don't recall a single comment block
(using "//"), recent or old, that does not violate that rule. Arguably,
the rule is wrong (it certainly doesn't match on-going practice).

Technically I was wrong however; thanks for the correction.

> That does not mean I agree with that document, and I am perfectly fine
> with both styles.

OK.

So, please ignore my comments on the comments.

Thanks
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [RFC v3 1/3] MdeModulePkg/PciHostBridgeDxe: Add support for address translation

2018-02-23 Thread Ard Biesheuvel 
On 23 February 2018 at 15:05, Laszlo Ersek  wrote:
> Thanks for writing up the details!
>
> Comments:
>
> On 02/23/18 09:53, Heyi Guo wrote:
>> PCI address translation is necessary for some non-x86 platforms. On
>> such platforms, address value (denoted as "device address" or "address
>> in PCI view") set to PCI BAR registers in configuration space might be
>> different from the address which is used by CPU to access the
>> registers in memory BAR or IO BAR spaces (denoted as "host address" or
>> "address in CPU view"). The difference between the two addresses is
>> called "Address Translation Offset" or simply "translation", and can
>> be represented by "Address Translation Offset" in ACPI QWORD Address
>> Space Descriptor (Offset 0x1E). However UEFI and ACPI differs on the
>> definitions of QWORD Address Space Descriptor, and we will follow UEFI
>> definition on UEFI protocols, such as PCI root bridge IO protocol and
>> PCI IO protocol. In UEFI 2.7, "Address Translation Offset" is "Offset
>> to apply to the Starting address to convert it to a PCI address". This
>> means:
>>
>> 1. Translation = device address - host address.
>
> OK, this looks like a sensible choice to me. It means that the "apply"
> term used in the UEFI spec means "add", which (I think) is the "natural"
> interpretation.
>
>> 2. PciRootBridgeIo->Configuration should return CPU view address, as
>> well as PciIo->GetBarAttributes.
>
> OK.
>
>>
>> Summary of addresses used:
>>
>> 1. Base and Limit in PCI_ROOT_BRIDGE_APERTURE are device address, for
>> it is easy to check whether the address is below 4G or above 4G.
>
> I agree that PciHostBridgeLib instances that do not set a nonzero
> Translation need not care about the difference.
>
> (1) Still, can you confirm this is a "natural" choice? Were the
> DmaAbove4G, MemAbove4G and PMemAbove4G fields originally introduced with
> the device (PCI) view in mind?
>

Yes. Although DMA and MMIO space are different in this regard (and
this series does not cover the former), the purpose of having 32-bit
addressable BAR space and/or 32-bit addressable memory for DMA is to
ensure that the addresses can be generated/decoded by the PCI device.

So it is appropriate for the distinction between 'below' and 'above' 4
GB to be made based on the PCI address.

> ... I also meant to raise a concern about the InitializePciHostBridge()
> function where we call AddIoSpace() and AddMemoryMappedIoSpace() --
> which end up manipulating GCD -- with data from
> PCI_ROOT_BRIDGE_APERTURE. I can see you modify those call sites in the
> patch, so that's good. (I do have more comments on the actual
> implementation.)
>
>>
>> 2. Address returned by
>> EFI_PCI_HOST_BRIDGE_RESOURCE_ALLOCATION_PROTOCOL::GetProposedResources
>> is device address, or else PCI bus driver cannot set correct address
>> into PCI BAR registers.
>>
>> 3. Address returned by PciRootBridgeIo->Configuration is host address
>> per UEFI 2.7 definition.
>>
>> 4. Addresses used in GCD manipulation are host address.
>>
>> 5. Addresses in ResAllocNode of PCI_ROOT_BRIDGE_INSTANCE are host
>> address, for they are allocated from GCD.
>>
>> 6. Address passed to PciHostBridgeResourceConflict is host address,
>> for it comes from ResAllocNode.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Heyi Guo 
>> Cc: Ruiyu Ni 
>> Cc: Ard Biesheuvel 
>> Cc: Star Zeng 
>> Cc: Eric Dong 
>> Cc: Laszlo Ersek 
>> Cc: Michael D Kinney 
>> ---
>>  .../Bus/Pci/PciHostBridgeDxe/PciHostBridge.c   |  74 +++---
>>  .../Bus/Pci/PciHostBridgeDxe/PciHostResource.h |   2 +
>>  .../Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c | 112 
>> ++---
>>  MdeModulePkg/Include/Library/PciHostBridgeLib.h|   8 ++
>>  4 files changed, 167 insertions(+), 29 deletions(-)
>>
>> diff --git a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c 
>> b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
>> index 1494848..e8979eb 100644
>> --- a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
>> +++ b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
>> @@ -32,6 +32,29 @@ EDKII_IOMMU_PROTOCOL*mIoMmuProtocol;
>>  EFI_EVENT   mIoMmuEvent;
>>  VOID*mIoMmuRegistration;
>>
>> +STATIC
>> +UINT64
>> +GetTranslationByResourceType (
>> +  IN  PCI_ROOT_BRIDGE_INSTANCE *RootBridge,
>> +  IN  PCI_RESOURCE_TYPEResourceType
>> +  )
>> +{
>> +  switch (ResourceType) {
>> +case TypeIo:
>> +  return RootBridge->Io.Translation;
>> +case TypeMem32:
>> +  return RootBridge->Mem.Translation;
>> +case TypePMem32:
>> +  return RootBridge->PMem.Translation;
>> +case TypeMem64:
>> +  return RootBridge->MemAbove4G.Translation;
>> +case TypePMem64:
>> +  return

[edk2] [RFC v3 1/3] MdeModulePkg/PciHostBridgeDxe: Add support for address translation

2018-02-23 Thread Heyi Guo 
PCI address translation is necessary for some non-x86 platforms. On
such platforms, address value (denoted as "device address" or "address
in PCI view") set to PCI BAR registers in configuration space might be
different from the address which is used by CPU to access the
registers in memory BAR or IO BAR spaces (denoted as "host address" or
"address in CPU view"). The difference between the two addresses is
called "Address Translation Offset" or simply "translation", and can
be represented by "Address Translation Offset" in ACPI QWORD Address
Space Descriptor (Offset 0x1E). However UEFI and ACPI differs on the
definitions of QWORD Address Space Descriptor, and we will follow UEFI
definition on UEFI protocols, such as PCI root bridge IO protocol and
PCI IO protocol. In UEFI 2.7, "Address Translation Offset" is "Offset
to apply to the Starting address to convert it to a PCI address". This
means:

1. Translation = device address - host address.

2. PciRootBridgeIo->Configuration should return CPU view address, as
well as PciIo->GetBarAttributes.

Summary of addresses used:

1. Base and Limit in PCI_ROOT_BRIDGE_APERTURE are device address, for
it is easy to check whether the address is below 4G or above 4G.

2. Address returned by
EFI_PCI_HOST_BRIDGE_RESOURCE_ALLOCATION_PROTOCOL::GetProposedResources
is device address, or else PCI bus driver cannot set correct address
into PCI BAR registers.

3. Address returned by PciRootBridgeIo->Configuration is host address
per UEFI 2.7 definition.

4. Addresses used in GCD manipulation are host address.

5. Addresses in ResAllocNode of PCI_ROOT_BRIDGE_INSTANCE are host
address, for they are allocated from GCD.

6. Address passed to PciHostBridgeResourceConflict is host address,
for it comes from ResAllocNode.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Heyi Guo 
Cc: Ruiyu Ni 
Cc: Ard Biesheuvel 
Cc: Star Zeng 
Cc: Eric Dong 
Cc: Laszlo Ersek 
Cc: Michael D Kinney 
---
 .../Bus/Pci/PciHostBridgeDxe/PciHostBridge.c   |  74 +++---
 .../Bus/Pci/PciHostBridgeDxe/PciHostResource.h |   2 +
 .../Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c | 112 ++---
 MdeModulePkg/Include/Library/PciHostBridgeLib.h|   8 ++
 4 files changed, 167 insertions(+), 29 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c 
b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
index 1494848..e8979eb 100644
--- a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
+++ b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridge.c
@@ -32,6 +32,29 @@ EDKII_IOMMU_PROTOCOL*mIoMmuProtocol;
 EFI_EVENT   mIoMmuEvent;
 VOID*mIoMmuRegistration;
 
+STATIC
+UINT64
+GetTranslationByResourceType (
+  IN  PCI_ROOT_BRIDGE_INSTANCE *RootBridge,
+  IN  PCI_RESOURCE_TYPEResourceType
+  )
+{
+  switch (ResourceType) {
+case TypeIo:
+  return RootBridge->Io.Translation;
+case TypeMem32:
+  return RootBridge->Mem.Translation;
+case TypePMem32:
+  return RootBridge->PMem.Translation;
+case TypeMem64:
+  return RootBridge->MemAbove4G.Translation;
+case TypePMem64:
+  return RootBridge->PMemAbove4G.Translation;
+default:
+  return 0;
+  }
+}
+
 /**
   Ensure the compatibility of an IO space descriptor with the IO aperture.
 
@@ -411,8 +434,12 @@ InitializePciHostBridge (
 }
 
 if (RootBridges[Index].Io.Base <= RootBridges[Index].Io.Limit) {
+  // Base and Limit in PCI_ROOT_BRIDGE_APERTURE are device address.
+  // According to UEFI 2.7, device address = host address + Translation.
+  // For GCD resource manipulation, we should use host address, so
+  // Translation is subtracted from device address here.
   Status = AddIoSpace (
- RootBridges[Index].Io.Base,
+ RootBridges[Index].Io.Base - 
RootBridges[Index].Io.Translation,
  RootBridges[Index].Io.Limit - RootBridges[Index].Io.Base + 1
  );
   ASSERT_EFI_ERROR (Status);
@@ -422,7 +449,7 @@ InitializePciHostBridge (
 EfiGcdIoTypeIo,
 0,
 RootBridges[Index].Io.Limit - 
RootBridges[Index].Io.Base + 1,
-[Index].Io.Base,
+[Index].Io.Base - 
RootBridges[Index].Io.Translation,
 gImageHandle,
 NULL
 );
@@ -443,14 +470,18 @@ InitializePciHostBridge (
 
 for (MemApertureIndex = 0; MemApertureIndex < ARRAY_SIZE (MemApertures); 
MemApertureIndex++) {
   if (MemApertures[MemApertureIndex]->Base <= 
MemApertures[MemApertureIndex]->Limit) {
+// Base and Limit in PCI_ROOT_BRIDGE_APERTURE are device address.
+// According to UEFI 2.7,