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

[Ard Biesheuvel <ard.biesheuvel@linaro.org>]

On 24 February 2018 at 03:11, Ni, Ruiyu <ruiyu.ni@intel.com> 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-0xffff 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.