On Tue, Nov 21, 2017 at 12:13:46AM +0100, Paolo Bonzini wrote:
> On 21/11/2017 00:08, Jeff Cody wrote:
> > @@ -34,6 +36,7 @@ void coroutine_fn co_aio_sleep_ns(AioContext *ctx,
> > QEMUClockType type,
> > CoSleepCB sleep_cb = {
> > .co = qemu_coroutine_self(),
> > };
> > +if
On 21/11/2017 00:08, Jeff Cody wrote:
> @@ -34,6 +36,7 @@ void coroutine_fn co_aio_sleep_ns(AioContext *ctx,
> QEMUClockType type,
> CoSleepCB sleep_cb = {
> .co = qemu_coroutine_self(),
> };
> +if (sleep_cb.co->sleeping == 1 || sleep_cb.co->scheduled == 1) {
> + fprin
On Mon, Nov 20, 2017 at 11:47:09PM +0100, Paolo Bonzini wrote:
> On 20/11/2017 23:35, Jeff Cody wrote:
> >> Is this a different "state" (in Stefan's parlance) than scheduled? In
> >> practice both means that someone may call qemu_(aio_)coroutine_enter
> >> concurrently, so you'd better not do it y
On 20/11/2017 23:35, Jeff Cody wrote:
>> Is this a different "state" (in Stefan's parlance) than scheduled? In
>> practice both means that someone may call qemu_(aio_)coroutine_enter
>> concurrently, so you'd better not do it yourself.
>>
> It is slightly different; it is from sleeping with a time
On Mon, Nov 20, 2017 at 11:30:39PM +0100, Paolo Bonzini wrote:
> On 20/11/2017 03:46, Jeff Cody wrote:
> > Once a coroutine is "sleeping", the timer callback will either enter the
> > coroutine, or schedule it for the next AioContext if using iothreads.
> >
> > It is illegal to enter that coroutin
On 20/11/2017 03:46, Jeff Cody wrote:
> Once a coroutine is "sleeping", the timer callback will either enter the
> coroutine, or schedule it for the next AioContext if using iothreads.
>
> It is illegal to enter that coroutine while waiting for this timer
> event and subsequent callback. This pat
Once a coroutine is "sleeping", the timer callback will either enter the
coroutine, or schedule it for the next AioContext if using iothreads.
It is illegal to enter that coroutine while waiting for this timer
event and subsequent callback. This patch will catch such an attempt,
and abort QEMU wi
