qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v5 10/11] dataplane: add virtio-blk data plane c


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH v5 10/11] dataplane: add virtio-blk data plane code
Date: Fri, 07 Dec 2012 11:51:18 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0

Il 07/12/2012 07:06, Stefan Hajnoczi ha scritto:
> BTW I should go into slightly more detail about why I stopped short of
> implementing the notify+join approach.
> 
> notify+join means stopping the event loop and data plane thread so
> that the caller is sure that virtio-blk-data-plane is quiesced.
> 
> Unfortunately this doesn't map nicely to bdrv_drain_all() where the
> caller has the global mutex, quiesces I/O, and then performs a critical
> operation.  I/O resumes after the caller returns or releases the global
> mutex:
> 
> bdrv_drain_all();
> critical_operation();
> return;
> /* now it's okay to process I/O again */
> 
> We cannot use notify+join here because bdrv_drain_all() would stop the
> data plane thread but nothing restarts it!

That's true.  The solution here for AioContext would be to run the event
loop in the context of the thread that is calling bdrv_drain_all().  But
you do not need bdrv_drain_all() right now, and the event loop would be
rewritten anyway to use AioContext, so the lack of "resume" is not a
problem for now IMHO.

> Perhaps we'd need a "resume" call after the critical operation so that
> the data plane thread is restarted - but this sounds invasive and is a
> departure from how existing I/O and emulated devices work.

The problem was more about the possible race in the draining of
requests, but it's okay to tackle it later.

Paolo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]