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

[Alex Bennée]

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". 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.

-- 
Alex Bennée