Re: [Qemu-devel] [RFC PATCH 17/26] replay: push replay_mutex_lock up the call tree

[Paolo Bonzini]

On 06/11/2017 14:05, Alex Bennée wrote:
> 
> Paolo Bonzini <address@hidden> writes:
> 
>> On 03/11/2017 10:47, Alex Bennée wrote:
>>>   As deadlocks are easy to introduce a new rule is introduced that the
>>>   replay_mutex_lock is taken before any BQL locks. Conversely you cannot
>>>   release the replay_lock while the BQL is still held.
>>
>> I agree with the former, but the latter is unnecessary.
> 
> I'm trying to think of occasions where this might cause us problems. The
> BQL is a event level lock, generally held for HW event serialisation and
> the replay_lock is synchronising batches of those events to the
> advancement of "time".

I would say that the BQL is "just" protecting data that has no other
finer-grain lock.

The replay_lock is (besides protecting record/replay status)
synchronizing events so that threads advance in lockstep, but the BQL is
also protecting things unrelated to recorded events.  For those it makes
sense to take the BQL without the replay lock.  Replacing
unlock_iothread/unlock_replay/lock_iothread with just unlock_replay is
only an optimization.

Paolo

> How about:
> 
>   As deadlocks are easy to introduce a new rule is introduced that the
>   replay_mutex_lock is taken before any BQL locks. While you would
>   usually unlock in the reverse order this isn't strictly enforced. The
>   important thing is any work to record the state of a given hardware
>   transaction has been completed as once the BQL is released the
>   execution state may move on.
>