diff options
author | David Gibson <david@gibson.dropbear.id.au> | 2016-10-18 17:02:49 +1100 |
---|---|---|
committer | David Gibson <david@gibson.dropbear.id.au> | 2016-10-28 09:38:27 +1100 |
commit | a795fc08f2636013fe097e51bdac62d089ac505a (patch) | |
tree | 42d6e2e8ed55611a33149a1529968690b024e6a7 /target-i386 | |
parent | 246fc0fb66cbf861b0e76320626b059e2d49ea12 (diff) |
libqos: Handle PCI IO de-multiplexing in common code
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>
Diffstat (limited to 'target-i386')
0 files changed, 0 insertions, 0 deletions