Re: [Qemu-block] [Qemu-devel] [PATCH 5/5] curl: convert to CoQueue

On 02/03/2018 07:39 AM, Paolo Bonzini wrote: > Now that CoQueues can use a QemuMutex for thread-safety, there is no > need for curl to roll its own coroutine queue. Coroutines can be > placed directly on the queue instead of using a list of CURLAIOCBs. > > Reviewed-by: Stefan Hajnoczi

Re: [Qemu-block] [Qemu-devel] [PATCH 4/5] coroutine-lock: make qemu_co_enter_next thread-safe

On 02/03/2018 07:39 AM, Paolo Bonzini wrote: > qemu_co_queue_next does not need to release and re-acquire the mutex, > because the queued coroutine does not run immediately. However, this > does not hold for qemu_co_enter_next. Now that qemu_co_queue_wait > can synchronize (via QemuLockable)

Re: [Qemu-block] [Qemu-devel] [PATCH 3/5] coroutine-lock: convert CoQueue to use QemuLockable

On 02/03/2018 07:39 AM, Paolo Bonzini wrote: > There are cases in which a queued coroutine must be restarted from > non-coroutine context (with qemu_co_enter_next). In this cases, > qemu_co_enter_next also needs to be thread-safe, but it cannot use > a CoMutex and so cannot qemu_co_queue_wait.

Re: [Qemu-block] [Qemu-devel] [PATCH 1/5] test-coroutine: add simple CoMutex test

On 02/03/2018 07:39 AM, Paolo Bonzini wrote: > In preparation for adding a similar test using QemuLockable, add a very > simple testcase that has two interleaved calls to lock and unlock. > > Reviewed-by: Stefan Hajnoczi > Signed-off-by: Paolo Bonzini >

Re: [Qemu-block] [Qemu-devel] [PATCH 2/5] lockable: add QemuLockable

On 02/03/2018 07:39 AM, Paolo Bonzini wrote: > +/* This function gives an error if an invalid, non-NULL pointer type is > passed > + * to QEMU_MAKE_LOCKABLE. For optimized builds, we can rely on dead-code > elimination > + * from the compiler, and give the errors already at link time. > + */ >

Re: [Qemu-block] [Qemu-devel] [PATCH v2 3/6] qapi: add block-dirty-bitmap-enable/disable

Vladimir Sementsov-Ogievskiy writes: > Signed-off-by: Vladimir Sementsov-Ogievskiy > --- > qapi/block-core.json | 42 ++ > blockdev.c | 42 ++ > 2 files

Re: [Qemu-block] [Qemu-devel] [PATCH v2 5/6] qapi: add block-dirty-bitmap-merge

Vladimir Sementsov-Ogievskiy writes: > Signed-off-by: Vladimir Sementsov-Ogievskiy > --- > qapi/block-core.json | 38 ++ > include/block/dirty-bitmap.h | 2 ++ > block/dirty-bitmap.c | 18

Re: [Qemu-block] [Qemu-devel] [PATCH v2 8/8] qapi: query-blockstat: add driver specific file-posix stats

Eric Blake writes: > On 01/19/2018 06:50 AM, Anton Nefedov wrote: >> A block driver can provide a callback to report driver-specific >> statistics. >> >> file-posix driver now reports discard statistics >> >> Signed-off-by: Anton Nefedov >>

[Qemu-block] [PATCH 2/5] lockable: add QemuLockable

QemuLockable is a polymorphic lock type that takes an object and knows which function to use for locking and unlocking. The implementation could use C11 _Generic, but since the support is not very widespread I am instead using __builtin_choose_expr and __builtin_types_compatible_p, which are

[Qemu-block] [PATCH 3/5] coroutine-lock: convert CoQueue to use QemuLockable

There are cases in which a queued coroutine must be restarted from non-coroutine context (with qemu_co_enter_next). In this cases, qemu_co_enter_next also needs to be thread-safe, but it cannot use a CoMutex and so cannot qemu_co_queue_wait. Use QemuLockable so that the CoQueue can

[Qemu-block] [PATCH 1/5] test-coroutine: add simple CoMutex test

In preparation for adding a similar test using QemuLockable, add a very simple testcase that has two interleaved calls to lock and unlock. Reviewed-by: Stefan Hajnoczi Signed-off-by: Paolo Bonzini --- tests/test-coroutine.c | 50

[Qemu-block] [PATCH 4/5] coroutine-lock: make qemu_co_enter_next thread-safe

qemu_co_queue_next does not need to release and re-acquire the mutex, because the queued coroutine does not run immediately. However, this does not hold for qemu_co_enter_next. Now that qemu_co_queue_wait can synchronize (via QemuLockable) with code that is not running in coroutine context, it's

[Qemu-block] [PATCH 5/5] curl: convert to CoQueue

Now that CoQueues can use a QemuMutex for thread-safety, there is no need for curl to roll its own coroutine queue. Coroutines can be placed directly on the queue instead of using a list of CURLAIOCBs. Reviewed-by: Stefan Hajnoczi Signed-off-by: Paolo Bonzini

[Qemu-block] [PATCH v5 0/5] coroutine-lock: polymorphic CoQueue

There are cases in which a queued coroutine must be restarted from non-coroutine context (with qemu_co_enter_next). In this cases, qemu_co_enter_next also needs to be thread-safe, but it cannot use a CoMutex and so cannot qemu_co_queue_wait. This happens in curl (which right now is rolling its