The PCI backends in libqos each supply an iomap() and iounmap() function
which is used to set up a specified PCI BAR. But PCI BAR allocation takes
place entirely within PCI space, so doesn't really need per-backend
versions. For example, Linux includes generic BAR allocation code used on
platforms where that isn't done by firmware.
This patch merges the BAR allocation from the two existing backends into a
single simplified copy. The back ends just need to set up some parameters
describing the window of PCI IO and PCI memory addresses which are
available for allocation. Like both the existing versions the new one uses
a simple bump allocator.
Note that (again like the existing versions) this doesn't really handle
64-bit memory BARs properly. It is actually used for such a BAR by the
ivshmem test, and apparently the 32-bit MMIO BAR logic is close enough to
work, as long as the BAR isn't too big. Fixing that to properly handle
64-bit BAR allocation is a problem for another time.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Laurent Vivier <lvivier@redhat.com>
Reviewed-by: Greg Kurz <groug@kaod.org>
The PCI IO space (aka PIO, aka legacy IO) and PCI memory space (aka MMIO)
are distinct address spaces by the PCI spec (although parts of one might be
aliased to parts of the other in some cases).
However, qpci_io_read*() and qpci_io_write*() can perform accesses to
either space depending on parameter. That's convenient for test case
drivers, since there are a fair few devices which can be controlled via
either a PIO or MMIO BAR but with an otherwise identical driver.
This is implemented by having addresses below 64kiB treated as PIO, and
those above treated as MMIO. This works because low addresses in memory
space are generally reserved for DMA rather than MMIO.
At the moment, this demultiplexing must be handled by each PCI backend
(pc and spapr, so far). There's no real reason for this - the current
encoding is likely to work for all platforms, and even if it doesn't we
can still use a more complex common encoding since the value returned from
iomap are semi-opaque.
This patch moves the demultiplexing into the common part of the libqos PCI
code, with the backends having simpler, separate accessors for PIO and
MMIO space. This also means we have a way of explicitly accessing either
space if it's necessary for some special case.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Laurent Vivier <lvivier@redhat.com>
Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Laurent Vivier <lvivier@redhat.com>
[dwg: Fixed build problem on 32-bit hosts]
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Remove glib.h includes, as it is provided by osdep.h.
This commit was created with scripts/clean-includes.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Eric Blake <eblake@redhat.com>
Tested-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Clean up includes so that osdep.h is included first and headers
which it implies are not included manually.
This commit was created with scripts/clean-includes.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Eric Blake <eblake@redhat.com>
Tested-by: Eric Blake <eblake@redhat.com>
This adds a test wherein we engage the PCI AHCI
device and ensure that the memory region for the
HBA functionality is now accessible.
Under Q35 environments, additional PCI configuration
is performed to ensure that the HBA functionality
will become usable.
Signed-off-by: John Snow <jsnow@redhat.com>
Message-id: 1408643079-30675-5-git-send-email-jsnow@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Added MSI-X support for qtest PCI.
Added MSI-X support for virtio-pci.
Added MSI-X test case in virtio-blk-test.
Signed-off-by: Marc Marí <marc.mari.barcelo@gmail.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
This patch allows qpci_iomap to return the size of the
BAR mapping that it created, to allow driver applications
(e.g, ahci-test) to make determinations about the suitability
or the mapping size, or in the specific case of AHCI, how
many ports are supported by the HBA.
Signed-off-by: John Snow <jsnow@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
This includes basic PCI support for the PC platform. Enough
abstraction should be present to support non-PC platforms too.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Message-id: 1366123521-4330-3-git-send-email-aliguori@us.ibm.com
