Re: [Qemu-devel] [RFC] New thread for the VM migration

[Anthony Liguori]

On 07/14/2011 03:36 AM, Avi Kivity wrote:
> On 07/14/2011 10:14 AM, Umesh Deshpande wrote:
> > Following patch is implemented to deal with the VCPU and iothread
> > starvation during the migration of a guest. Currently iothread is
> > responsible for performing the migration. It holds the qemu_mutex
> > during the migration and doesn't allow VCPU to enter the qemu mode and
> > delays its return to the guest. The guest migration, executed as an
> > iohandler also delays the execution of other iohandlers. In the
> > following patch, the migration has been moved to a separate thread to
> > reduce the qemu_mutex contention and iohandler starvation.
> >
> >
> > @@ -260,10 +260,15 @@ int ram_save_live(Monitor *mon, QEMUFile *f, int
> > stage, void *opaque)
> > return 0;
> > }
> >
> > + if (stage != 3)
> > + qemu_mutex_lock_iothread();
>
> Please read CODING_STYLE, especially the bit about braces.
>
> Does this mean that the following code is sometimes executed without
> qemu_mutex? I don't think any of it is thread safe.

That was my reaction too.

I think the most rational thing to do is have a separate thread and a 
pair of producer/consumer queues.

The I/O thread can push virtual addresses and sizes to the queue for the 
migration thread to compress/write() to the fd.  The migration thread 
can then push sent regions onto a separate queue for the I/O thread to 
mark as dirty.

Regards,

Anthony Liguori

> Even just reading memory is not thread safe. You either have to copy it
> into a buffer under lock, or convert the memory API to RCU.