Re: [Qemu-devel] intermittent make check failure: "tcg_handle_interrupt: assertion failed: (qemu_mutex_iothread_locked())"

[Alex Bennée]

Peter Maydell <address@hidden> writes:

> I got a make check failure on aarch64 host running a sparc64 test:
>
>
> TEST: tests/prom-env-test... (pid=13573)
>   /sparc64/prom-env/sun4u:                                             **
> ERROR:/home/pm215/qemu/translate-common.c:34:tcg_handle_interrupt:
> assertion failed: (qemu_mutex_iothread_locked())

So the assertions where added with MTTCG. The design specifies which
bits should be protected by the BQL and cpu->interrupt_request is one of
them. This is because cpu->interrupt_request is often a cross-vCPU
action (one vCPU triggering an interrupt on another) so there is a
chance of racing if not protected.

It's odd this is showing up on a aarch64 host though when it didn't hit
on my x86_64 host while testing.

As most of this stuff is triggered by hardware emulation the BQL should
be in effect when handling MMIO for device emulation. There where other
entry points in ARM which could trigger stuff which is why we add
locking for things like ARM_CP_IO which are co-processor register
accesses which trigger other things in the system.

What will be useful for all these reports is the backtrace. Then it's
fairly simple to identify the thing triggering the interrupt and
identify the correct place for the locking.

Having said that on some setups we are seeing very high BQL contention
so maybe it will be simpler to move this stuff to atomic updates. I
believe Paolo has some patches on the list.

> Broken pipe
> FAIL
> GTester: last random seed: R02Sa5fa983185fe5e65cfb5b7fcb39ed3d1
> (pid=13579)
> FAIL: tests/prom-env-test
>
> This is with commit 9514f2648ca05b3.
>
> It didn't reproduce on a rerun of 'make check' and it didn't
> look like the merge in question was particularly relevant to
> the failure, so I went ahead and pushed it to master.
>
> I'm (perhaps unfairly) assuming that this is fallout from MTTCG
> landing. (prom-env-test is one of the handful of tests in
> 'make check' that actually runs TCG code.)

Well I was hoping for a fairly incident free merge but I guess that's
why we have a softfreeze. The assertions where added so any areas where
the design is violated can be picked up pretty quickly which they seem
to be doing their job.

--
Alex Bennée