summaryrefslogtreecommitdiff
path: root/IntelFspWrapperPkg
diff options
context:
space:
mode:
authorLaszlo Ersek <lersek@redhat.com>2015-02-23 16:03:46 +0000
committerlersek <lersek@Edk2>2015-02-23 16:03:46 +0000
commitef8dba7da3bb9bef067d553a0ac53e216e085daf (patch)
treef1155223851162b4ea945d583ec27219c83ae026 /IntelFspWrapperPkg
parentf9a8be423cdd5ae0a4bf489189aac500cfe79d57 (diff)
downloadedk2-platforms-ef8dba7da3bb9bef067d553a0ac53e216e085daf.tar.xz
ArmVirtualizationPkg/PciHostBridgeDxe: allocate IO BARs top-down
Currently we allocate IO BARs bottom-up in the EfiPciHostBridgeAllocateResources phase of the enumeration. > GCD:AddIoSpace(Base=0000000000000000,Length=0000000000010000) > GcdIoType = I/O > Status = Success > GCDIoType Range > ========== ================================= > I/O 0000000000000000-000000000000FFFF Because the IO aperture is based at zero, the first allocation happens to get the zero address. However, a zero address for a PCI BAR is considered unmapped; see eg.: - <http://www.pcisig.com/reflector/msg00459.html>, - the (new_addr == 0) part in QEMU, pci_bar_address() [hw/pci/pci.c]: new_addr = pci_get_long(d->config + bar) & ~(size - 1); last_addr = new_addr + size - 1; /* Check if 32 bit BAR wraps around explicitly. * TODO: make priorities correct and remove this work around. */ if (last_addr <= new_addr || new_addr == 0 || last_addr >= UINT32_MAX) { return PCI_BAR_UNMAPPED; } We can avoid this problem by allocating top-down in the IO aperture. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Olivier Martin <Olivier.martin@arm.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16905 6f19259b-4bc3-4df7-8a09-765794883524
Diffstat (limited to 'IntelFspWrapperPkg')
0 files changed, 0 insertions, 0 deletions