> The spec is quite clear: the address descriptor should *not* contain
> the raw BAR value, but the CPU's translated view. So I think we should
> fix the implementation to comply with that.
To complicate it a little further, here's what ACPI specification says
about QWORD Address Space Descriptor:
On 5 September 2017 at 08:07, Ni, Ruiyu wrote:
> Bartosz,
>
> Based on your findings, the AddrRangeMin has to be a device addressâș
>
> As far as I can remember, this history is:
> In the very beginning, Spec owner assumes the device address equals to CPU
> address.
> The implementation of GetBarA
oid breaking the existing consumers, GetBarAttributes() remains to
> return the BAR address.
>
>
>
> Anyone please correct me if I am wrong.
>
>
>
> Thanks,
>
> Ray
>
>
>
> *From:* Bartosz Szczepanek [mailto:b...@semihalf.com]
> *Sent:* Monday, Septem
please correct me if I am wrong.
Thanks,
Ray
From: Bartosz Szczepanek [mailto:b...@semihalf.com]
Sent: Monday, September 4, 2017 7:43 PM
To: edk2-devel@lists.01.org
Cc: Ni, Ruiyu
Subject: [edk2] CPU/PCI addressing in PciIoGetAttributes
Hi guys,
I have some doubt about PciIoGetAttributes
Hi guys,
I have some doubt about PciIoGetAttributes behaviour on aarch64 platform
with non-uniform CPU:PCI address space mapping. I'll be grateful if you
verify my understanding.
According to UEFI specification, AddrRangeMin in QWORD Address Space
Descriptor returned by PciIoGetAttributes() shoul
5 matches
Mail list logo
