| Age | Commit message (Collapse) | Author |
|---|
|
All files under GPLv2 will get GPLv2+ changes starting tomorrow.
event_notifier.c and exec-obsolete.h were only ever touched by Red Hat
employees and can be relicensed now.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
|
|
qemu_malloc/qemu_free no longer exist after this commit.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
|
|
Not all block format drivers expose an io_flush method (reasonable for
read-only protocols), so calling io_flush there will immediately segfault.
Fix by checking for the method's existence before calling it.
Signed-off-by: Avi Kivity <avi@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
|
|
We'll leave some AIO completions unhandled when we can't call the callback.
qemu_aio_process_queue() is used later to run any callbacks that are left and
can be run then.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
|
|
Problem: Our file sys-queue.h is a copy of the BSD file, but there are
some additions and it's not entirely compatible. Because of that, there have
been conflicts with system headers on BSD systems. Some hacks have been
introduced in the commits 15cc9235840a22c289edbe064a9b3c19c5f49896,
f40d753718c72693c5f520f0d9899f6e50395e94,
96555a96d724016e13190b28cffa3bc929ac60dc and
3990d09adf4463eca200ad964cc55643c33feb50 but the fixes were fragile.
Solution: Avoid the conflict entirely by renaming the functions and the
file. Revert the previous hacks.
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
|
|
Without this, the call to qemu_aio_flush during migration doesn't
actually flush all in-flight SCSI IOs.
Signed-off-by: Nolan Leake <nolan <at> sigbus.net>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
|
|
qemu_aio_wait by invoking the bh or one of the aio completion
callbacks, could end up submitting new pending aio, breaking the
invariant that qemu_aio_flush returns only when no pending aio is
outstanding (possibly a problem for migration as such).
Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Kevin Wolf <kwolf@redhat.com>
|
|
When deleting an fd event there is a chance the object doesn't get
deleted, but only ->deleted set positive and deleted somewhere later.
Now, if we create a handler for the fd again before the actual
deletion occurs, we end up writing data into an object that has
->deleted set, which is obviously wrong.
I see two ways to fix this:
1. Don't return ->deleted objects in the search
2. Unset ->deleted in the search
This patch implements 1. which feels safer to do. It fixes AIO issues
I've seen with curl, as libcurl unsets fd event listeners pretty
frequently.
Signed-off-by: Alexander Graf <alex@csgraf.de>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
|
|
Signed-off-by: Avi Kivity <avi@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6531 c046a42c-6fe2-441c-8c8c-71466251a162
|
|
This was spotted by valgrind.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@5470 c046a42c-6fe2-441c-8c8c-71466251a162
|
|
This patch refactors the AIO layer to allow multiple AIO implementations. It's
only possible because of the recent signalfd() patch.
Right now, the AIO infrastructure is pretty specific to the block raw backend.
For other block devices to implement AIO, the qemu_aio_wait function must
support registration. This patch introduces a new function,
qemu_aio_set_fd_handler, which can be used to register a file descriptor to be
called back. qemu_aio_wait() now polls a set of file descriptors registered
with this function until one becomes readable or writable.
This patch should allow the implementation of alternative AIO backends (via a
thread pool or linux-aio) and AIO backends in non-traditional block devices
(like NBD).
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@5297 c046a42c-6fe2-441c-8c8c-71466251a162
|
