@@ -1058,7 +1058,8 @@ static pcibus_t pci_bar_address(PCIDevice *d,
/* XXX: as we cannot support really dynamic
mappings, we handle specific values as invalid
mappings. */
- if (last_addr <= new_addr || new_addr == 0 ||
+ if (last_addr <= new_addr ||
+ (new_addr == 0 && !(d->cap_present & QEMU_PCI_ADDR0_ALLOWED)) ||
last_addr == PCI_BAR_UNMAPPED) {
return PCI_BAR_UNMAPPED;
}
@@ -157,6 +157,9 @@ enum {
QEMU_PCI_CAP_SHPC = (1 << QEMU_PCI_SHPC_BITNR),
#define QEMU_PCI_SLOTID_BITNR 6
QEMU_PCI_CAP_SLOTID = (1 << QEMU_PCI_SLOTID_BITNR),
+ /* PCI device (in breach of the spec) allows MMIO BAR at address 0 */
+#define QEMU_PCI_ADDR0_ALLOWED_BITNR 7
+ QEMU_PCI_ADDR0_ALLOWED = (1 << QEMU_PCI_ADDR0_ALLOWED_BITNR)
};
#define TYPE_PCI_DEVICE "pci-device"
The PCI specification says that 0 isn't a valid address for an MMIO bar. However some devices won't object if you program a BAR at address 0 and will then respond to bus accesses at that address. (In particular the host PCI controller for the Versatile/Realview boards behaves like this, and Linux relies on it for setting up a 1:1 mapping between PCI address space and system address space for bus-mastering DMA.) To allow us to model devices with this out-of-spec quirk, add a new QEMU_PCI_ADDR0_ALLOWED flag to cap_present which bypasses the "address 0 is not valid" test in pci_bar_address(). Signed-off-by: Peter Maydell <peter.maydell@linaro.org> --- hw/pci/pci.c | 3 ++- include/hw/pci/pci.h | 3 +++ 2 files changed, 5 insertions(+), 1 deletion(-)