Drop one more client of global_qtest by teaching all fw_cfg test
functionality (invoked through alloc-pc) to pass in an explicit
QTestState, adjusting all callers. In particular, fw_cfg-test
had to reorder things to create the test state prior to creating
the fw_cfg (and drop a pointless strdup in the meantime), but that
test now no longer depends on global_qtest.
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: John Snow <jsnow@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
[thuth: Fixed conflict wrt pc_alloc_init() in vhost-user-test.c]
Signed-off-by: Thomas Huth <thuth@redhat.com>
When initializing a QPCIBus, track which QTestState the bus is
associated with (so that a later patch can then explicitly use
that test state for all communication on the bus, rather than
blindly relying on global_qtest). Update the initialization
functions to take another parameter, and update all callers to
pass in state (for now, most callers get away with passing the
current global_qtest as the current state, although this required
fixing the order of initialization to ensure qtest_start() is
called before qpci_init*() in rtl8139-test, and provided an
opportunity to pass in the allocator in e1000e-test).
Touch up some allocations to use g_new0() rather than g_malloc()
while in the area, and simplify some code (all implementations
of QOSOps provide a .init_allocator() that never fails).
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: John Snow <jsnow@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
[thuth: Removed hunk from vhost-user-test.c that is not required anymore,
fixed conflict in qtest_vboot() and adjusted qpci_init_pc() in sdhci-test]
Signed-off-by: Thomas Huth <thuth@redhat.com>
Spotted by ASAN.
This hunk adds an assertion. It checks that we're finding no more than
one e1000e device: each hit allocates, but there is only one g_free().
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
The usual use model for the libqos PCI functions is to map a specific PCI
BAR using qpci_iomap() then pass the returned token into IO accessor
functions. This, and the fact that iomap() returns a (void *) which
actually contains a PCI space address, kind of suggests that the return
value from iomap is supposed to be an opaque token.
..except that the callers expect to be able to add offsets to it. Which
also assumes the compiler will support pointer arithmetic on a (void *),
and treat it as working with byte offsets.
To clarify this situation change iomap() and the IO accessors to take
a definitely opaque BAR handle (enforced with a wrapper struct) along with
an offset within the BAR. This changes both the functions and all the
callers.
There were a number of places that checked if iomap() returned non-NULL,
and or initialized it to NULL before hand. Since iomap() already assert()s
if it fails to map the BAR, these tests were mostly pointless and are
removed.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Dmitry Fleytman <dmitry.fleytman@ravellosystems.com>
Signed-off-by: Leonid Bloch <leonid.bloch@ravellosystems.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
Eric Blake