qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Alex Bennée" <alex.bennee@linaro.org>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] intermittent make check failure: "tcg_handle_interrupt: assertion failed: (qemu_mutex_iothread_locked())"
Date: Wed, 01 Mar 2017 11:36:42 +0000	[thread overview]
Message-ID: <877f492ppx.fsf@linaro.org> (raw)
In-Reply-To: <CAFEAcA_KVG19uhPuBUNx4ySmebnL1Hit6=HUX9ug0FkBFMwasg@mail.gmail.com>


Peter Maydell <peter.maydell@linaro.org> 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

  parent reply	other threads:[~2017-03-01 11:36 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-28 19:10 [Qemu-devel] intermittent make check failure: "tcg_handle_interrupt: assertion failed: (qemu_mutex_iothread_locked())" Peter Maydell
2017-02-28 19:30 ` Thomas Huth
2017-02-28 21:28   ` Thomas Huth
2017-02-28 21:35     ` Mark Cave-Ayland
2017-02-28 22:07       ` Mark Cave-Ayland
2017-02-28 20:52 ` Kevin Wolf
2017-03-01 10:37   ` Dr. David Alan Gilbert
2017-03-01 11:36 ` Alex Bennée [this message]
2017-03-01 12:15   ` Mark Cave-Ayland
2017-03-01 12:41     ` Alex Bennée
2017-03-01 14:53       ` Mark Cave-Ayland
2017-03-01 15:19         ` Alex Bennée
2017-03-01 16:19           ` Mark Cave-Ayland
2017-03-01 18:33             ` Alex Bennée
2017-03-01 16:36           ` Peter Maydell
2017-03-01 18:17           ` Thomas Huth
2017-03-01 12:52   ` Peter Maydell
2017-03-01 18:27   ` [Qemu-devel] s390x " Thomas Huth
2017-03-01 18:35     ` Alex Bennée
2017-03-01 18:41   ` [Qemu-devel] xtensa " Thomas Huth
2017-03-01 20:32     ` Alex Bennée
2017-03-01 20:48       ` Peter Maydell
2017-03-02 11:39     ` [Qemu-devel] mips " Yongbok Kim
2017-03-02 12:57       ` Alex Bennée

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=877f492ppx.fsf@linaro.org \
    --to=alex.bennee@linaro.org \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).