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

[Markus Armbruster]

"Dr. David Alan Gilbert" <address@hidden> 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 be made thread local for running multiple
monitors concurrently.

> 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 just the wrong time while the lock is held, and now, you don't have

Is it okay to block while holding the BQL?

> any way to unblock it since you can't do anything on the monitors.
> If I could issue a command then I could have it end up doing a shutdown(2)
> on the network connection and free things up.
>
> Maybe this would also help real-time people?
>
> I was thinking then, we could:
>    a) Have a monitor that wasn't tied to the main loop at all - each instance
> would be it's own thread and have it's own poll() (probably using the new
> IO channels?)
>    b) for most commands it would take the big lock before execute the command
> and release it afterwards - so there would be no risk in those commands.

Saves you the auditing their code, which would probably be impractical.

>    c) Some commands you could mark as 'lock free' - they would be required
> not to take any locks or wait for *anything* and for those the monitor would
> not take the lock.

They also must not access shared state without suitable synchronization.

>    d) Perhaps have some way of restricting a particular monitor session to 
> only
> allowing non-blocking commands.

Why?  To ensure you always have an emergency monitor available?

>    e) Then I'd have to have a way of finding the broken device in a lockfree
> way (RTU list walk?) and issuing the shutdown(2).
>
> Bonus points to anyone who can statically check commands in (c).

Tall order.

> Does this make sense to everyone else, or does anyone have any better
> suggestions?

Sounds like a big, hairy task to me.

Any alternatives?