Re: [Qemu-devel] [big lock] Discussion about the convention of device's DMA each other after breaking down biglock

[Paolo Bonzini]

> Oh!  And from this thread, my understanding of the reason for the rule
> of lock sequence: coarse->fine is that biglock means higher
> possibility of conflict, so we try it first, then try the fine-lock.
> In this way, we have a smaller window for holding fine-lock which
> means the other thread can get this lock more smoothly.  Right?

Yes.

> NOT want to open an argument, just a question, is there any reason
> for the sequence devlock->timelock?

Not any particular reason, just that it makes more sense. :)
Backend subsystems (timers, network, I/O handlers, ...) typically
will not call anything else.  So it makes sense that their locks
are held inside the device locks (and inside the big lock).

Also note that while the timer subsystem could call the devices,
it is perfectly plausible that the devices will do for example a
qemu_mod_timer from a timer callback.  Thus, in some sense the
timer subsystem already has to expect modifications of its state
during the callback.  Releasing the lock during callbacks is "just"
an extension of the current behavior.

Of course some changes are needed to the invariants, such as the one
Avi pointed out elsewhere in the thread, but devlock->timerlock is
overall more natural than the opposite.

Paolo