qemu_coroutine_yield switches thread?

qemu_coroutine_yield switches thread?

[Stefan Reiter]

Hi list,

quick question: Can a resume from a qemu_coroutine_yield happen in a 
different thread?

Well, it can, since I'm seeing it happen, but is that okay or a bug?

I.e. in a backup-job the following can sporadically trip:

   unsigned long tid = pthread_self();
   qemu_get_current_aio_context(); // returns main context
   qemu_coroutine_yield();
   qemu_get_current_aio_context(); // still returns main context, but:
   assert(tid == pthread_self()); // this fails

It seems to be called from a vCPU thread when it happens. VM uses no 
iothreads.

~

Re: qemu_coroutine_yield switches thread?

[Kevin Wolf]

Am 16.04.2020 um 10:06 hat Stefan Reiter geschrieben:
> Hi list,
> 
> quick question: Can a resume from a qemu_coroutine_yield happen in a
> different thread?
> 
> Well, it can, since I'm seeing it happen, but is that okay or a bug?

Yes, it can happen. At least for devices like IDE where a request is
started during a vmexit (MMIO or I/O port write), the coroutine will
usually begin its life in the vcpu thread and then move to the main loop
thread.

This is not a problem because the vcpu thread holds the BQL while
running the request coroutine.

> I.e. in a backup-job the following can sporadically trip:
> 
>   unsigned long tid = pthread_self();
>   qemu_get_current_aio_context(); // returns main context
>   qemu_coroutine_yield();
>   qemu_get_current_aio_context(); // still returns main context, but:
>   assert(tid == pthread_self()); // this fails
> 
> It seems to be called from a vCPU thread when it happens. VM uses no
> iothreads.

This must be a guest request that was intercepted by the backup job. I
think it wouldn't happen for the background copy, these requests already
start in the main loop.

Kevin

Re: qemu_coroutine_yield switches thread?

[Dietmar Maurer]

> > quick question: Can a resume from a qemu_coroutine_yield happen in a
> > different thread?
> > 
> > Well, it can, since I'm seeing it happen, but is that okay or a bug?
> 
> Yes, it can happen. At least for devices like IDE where a request is
> started during a vmexit (MMIO or I/O port write), the coroutine will
> usually begin its life in the vcpu thread and then move to the main loop
> thread.
> 
> This is not a problem because the vcpu thread holds the BQL while
> running the request coroutine.

Isn't that a problem when using QemuRecMutex, for example:

qemu_rec_mutex_lock(lock)
...
qemu_coroutine_yield() // wait for something
// we are now inside a different thread
qemu_rec_mutex_unlock(lock) // Crash - wrong thread!!

?

Re: qemu_coroutine_yield switches thread?

[Kevin Wolf]

Am 16.04.2020 um 12:09 hat Dietmar Maurer geschrieben:
> > > quick question: Can a resume from a qemu_coroutine_yield happen in a
> > > different thread?
> > > 
> > > Well, it can, since I'm seeing it happen, but is that okay or a bug?
> > 
> > Yes, it can happen. At least for devices like IDE where a request is
> > started during a vmexit (MMIO or I/O port write), the coroutine will
> > usually begin its life in the vcpu thread and then move to the main loop
> > thread.
> > 
> > This is not a problem because the vcpu thread holds the BQL while
> > running the request coroutine.
> 
> Isn't that a problem when using QemuRecMutex, for example:
> 
> qemu_rec_mutex_lock(lock)
> ...
> qemu_coroutine_yield() // wait for something
> // we are now inside a different thread
> qemu_rec_mutex_unlock(lock) // Crash - wrong thread!!

Acquiring a lock (other than CoMutex etc.) in a coroutine would be wrong
even if the coroutine stays in the same thread because acquiring the
lock can block, and the coroutine must yield in that case instead of
blocking. Coroutines must use the the coroutine locking primitives from
qemu/coroutine.h.

Kevin