Re: [Qemu-devel] lock-free monitor?

2016-02-15 Thread Markus Armbruster
Stefan Hajnoczi writes: > On Sun, Feb 14, 2016 at 02:22:10PM +0800, Fam Zheng wrote: >> On Tue, 02/09 13:47, Stefan Hajnoczi wrote: >> > On Mon, Feb 08, 2016 at 03:17:23PM +, Dr. David Alan Gilbert wrote: >> > > Does this make sense to everyone else, or does anyone have

Re: [Qemu-devel] lock-free monitor?

2016-02-15 Thread Stefan Hajnoczi
On Sun, Feb 14, 2016 at 02:22:10PM +0800, Fam Zheng wrote: > On Tue, 02/09 13:47, Stefan Hajnoczi wrote: > > On Mon, Feb 08, 2016 at 03:17:23PM +, Dr. David Alan Gilbert wrote: > > > Does this make sense to everyone else, or does anyone have any better > > > suggestions? > > > > As a concrete

Re: [Qemu-devel] lock-free monitor?

2016-02-15 Thread Kevin Wolf
Am 09.02.2016 um 14:47 hat Stefan Hajnoczi geschrieben: > On Mon, Feb 08, 2016 at 03:17:23PM +, Dr. David Alan Gilbert wrote: > > Does this make sense to everyone else, or does anyone have any better > > suggestions? > > As a concrete example, any monitor command that calls bdrv_drain_all() >

Re: [Qemu-devel] lock-free monitor?

2016-02-13 Thread Fam Zheng
On Tue, 02/09 13:47, Stefan Hajnoczi wrote: > On Mon, Feb 08, 2016 at 03:17:23PM +, Dr. David Alan Gilbert wrote: > > Does this make sense to everyone else, or does anyone have any better > > suggestions? > > As a concrete example, any monitor command that calls bdrv_drain_all() > can hang

Re: [Qemu-devel] lock-free monitor?

2016-02-11 Thread Markus Armbruster
"Dr. David Alan Gilbert" writes: > * Markus Armbruster (arm...@redhat.com) wrote: >> "Dr. David Alan Gilbert" writes: >> >> > * Markus Armbruster (arm...@redhat.com) wrote: >> >> "Dr. David Alan Gilbert" writes: >> >> >> >> > Hi,

Re: [Qemu-devel] lock-free monitor?

2016-02-10 Thread Markus Armbruster
"Dr. David Alan Gilbert" writes: > * Markus Armbruster (arm...@redhat.com) wrote: >> "Dr. David Alan Gilbert" writes: >> >> > Hi, >> > I wondered what it would take to be able to do a lock-free monitor; >> > i.e. one that could respond to (some)

Re: [Qemu-devel] lock-free monitor?

2016-02-10 Thread Dr. David Alan Gilbert
* Markus Armbruster (arm...@redhat.com) wrote: > "Dr. David Alan Gilbert" writes: > > > * Markus Armbruster (arm...@redhat.com) wrote: > >> "Dr. David Alan Gilbert" writes: > >> > >> > Hi, > >> > I wondered what it would take to be able to do a

Re: [Qemu-devel] lock-free monitor?

2016-02-10 Thread Dr. David Alan Gilbert
* Markus Armbruster (arm...@redhat.com) wrote: > "Dr. David Alan Gilbert" writes: > > > Hi, > > I wondered what it would take to be able to do a lock-free monitor; > > i.e. one that could respond to (some) commands while the qemu big lock is > > held. > > Requires a

Re: [Qemu-devel] lock-free monitor?

2016-02-09 Thread Dr. David Alan Gilbert
* Stefan Hajnoczi (stefa...@redhat.com) wrote: > On Mon, Feb 08, 2016 at 03:17:23PM +, Dr. David Alan Gilbert wrote: > > Does this make sense to everyone else, or does anyone have any better > > suggestions? > > As a concrete example, any monitor command that calls bdrv_drain_all() > can hang

Re: [Qemu-devel] lock-free monitor?

2016-02-09 Thread Stefan Hajnoczi
On Mon, Feb 08, 2016 at 03:17:23PM +, Dr. David Alan Gilbert wrote: > Does this make sense to everyone else, or does anyone have any better > suggestions? As a concrete example, any monitor command that calls bdrv_drain_all() can hang forever with the QEMU global mutex held if I/O requests

Re: [Qemu-devel] lock-free monitor?

2016-02-09 Thread Markus Armbruster
"Dr. David Alan Gilbert" writes: > Hi, > I wondered what it would take to be able to do a lock-free monitor; > i.e. one that could respond to (some) commands while the qemu big lock is > held. Requires a careful audit of the monitor code. For instance, cur_mon needs to

[Qemu-devel] lock-free monitor?

2016-02-08 Thread Dr. David Alan Gilbert
Hi, I wondered what it would take to be able to do a lock-free monitor; i.e. one that could respond to (some) commands while the qemu big lock is held. My reason for asking is that there are cases in migration and colo where a network block device has failed and is blocking, but it fails at