On Fri, Feb 08, 2019 at 11:33:32 +0000, Alex Bennée wrote:
>
> Emilio G. Cota <c...@braap.org> writes:
>
> > It will gain some users soon.
> >
> > Suggested-by: Paolo Bonzini <pbonz...@redhat.com>
> > Reviewed-by: Richard Henderson <richard.hender...@linaro.org>
> > Signed-off-by: Emilio G. Cota <c...@braap.org>
> > ---
> > include/qom/cpu.h | 36 +++++++++++++++++++++++++++++++++---
(snip)
> > static inline bool cpu_has_work(CPUState *cpu)
> > {
> > CPUClass *cc = CPU_GET_CLASS(cpu);
> > + bool has_cpu_lock = cpu_mutex_locked(cpu);
> > + bool (*func)(CPUState *cpu);
> > bool ret;
> >
> > + if (cc->has_work_with_iothread_lock) {
> > + if (qemu_mutex_iothread_locked()) {
> > + func = cc->has_work_with_iothread_lock;
> > + goto call_func;
> > + }
> > +
> > + if (has_cpu_lock) {
> > + /* avoid deadlock by acquiring the locks in order */
>
> This is fine here but can we expand the comment above:
>
> * cpu_has_work:
> * @cpu: The vCPU to check.
> *
> * Checks whether the CPU has work to do. If the vCPU helper needs to
> * check it's work status with the BQL held ensure we hold the BQL
> * before taking the CPU lock.
I added a comment to the body of the function:
+ /* some targets require us to hold the BQL when checking for work */
if (cc->has_work_with_iothread_lock) {
> Where is our canonical description of the locking interaction between
> BQL and CPU locks?
It's in a few places, for instance cpu_mutex_lock's documentation
in include/qom/cpu.h.
I've added a comment about the locking order to @lock's documentation,
also in cpu.h:
- * @lock: Lock to prevent multiple access to per-CPU fields.
+ * @lock: Lock to prevent multiple access to per-CPU fields. Must be acqrd
+ * after the BQL.
> Otherwise:
>
> Reviewed-by: Alex Bennée <alex.ben...@linaro.org>
Thanks!
Emilio
