From: "Alex Bennée" <alex.bennee@linaro.org>
To: Pavel Dovgalyuk <dovgaluk@ispras.ru>
Cc: 'Stefan Hajnoczi' <stefanha@gmail.com>,
'qemu-devel' <qemu-devel@nongnu.org>,
'Paolo Bonzini' <pbonzini@redhat.com>,
'Pavel Dovgalyuk' <pavel.dovgaluk@ispras.ru>,
'Peter Maydell' <peter.maydell@linaro.org>
Subject: Re: [Qemu-devel] qemu-2.8-rc4 is broken
Date: Fri, 20 Jan 2017 17:33:11 +0000 [thread overview]
Message-ID: <87mveleiw8.fsf@linaro.org> (raw)
In-Reply-To: <000e01d26caa$dfdb3150$9f9193f0$@ru>
Pavel Dovgalyuk <dovgaluk@ispras.ru> writes:
>> From: Alex Bennée [mailto:alex.bennee@linaro.org]
>> >> From: Stefan Hajnoczi [mailto:stefanha@gmail.com]
>> >> >
>> >> > Yes, this option helps.
>> >> > Thank you.
>> >>
>> >> Good news. This can be fixed in 2.8.1 once someone finds a solution.
>> >
>> > It seems that something still goes wrong.
>> > I'm using this workaround, but there is a kind of deadlock in translation.
>> > call_rcu_thread hangs at some moment in qemu_event_wait.
>> >
>> > As far as I understand, it is used by QHT in translate-all.c.
>> > I can't get more information yet, because logging makes everything too slow.
>>
>> There are a number of users of RCU bit for QHT I think it only gets
>> activated when it needs to re-size its hash table on insertion of new
>> TranslationBlocks.
>>
>> Can you get a backtrace of all threads when it deadlocks?
>
> Sorry, this is another problem which occurs only in icount replay mode:
> 1. cpu_handle_exception tries to force exception when is cannot occur due to
> running out all the planned instructions:
> } else if (replay_has_exception()
> && cpu->icount_decr.u16.low + cpu->icount_extra == 0) {
> /* try to cause an exception pending in the log */
> cpu_exec_nocache(cpu, 1, tb_find(cpu, NULL, 0), true);
> *ret = -1;
> return true;
>
> 2. tb_find calls tb_gen_code, which cannot allocate new translation block
> and calls tb_flush (which only queues the flushing) and cpu_loop_exit
> 3. cpu_loop_exit returns to infinite loop of cpu_exec and the condition
> if (cpu_handle_exception(cpu, &ret)) {
> break;
> }
> is checked again causing an infinite loop.
>
> TB cache is not flushed because we never execute that break and real work of tb_flush
> is made outside this loop.
I think what we need is a:
if (cpu->exit_request)
break;
before the cpu_handle_exception() call to ensure any queued work gets
processed first. Can you give me you current command line so I can
reproduce this and check the fix works?
--
Alex Bennée
next prev parent reply other threads:[~2017-01-20 17:33 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-19 9:47 [Qemu-devel] qemu-2.8-rc4 is broken Pavel Dovgalyuk
2016-12-20 7:45 ` Pavel Dovgalyuk
2016-12-20 10:21 ` Stefan Hajnoczi
2016-12-20 11:10 ` Pavel Dovgalyuk
2016-12-20 13:20 ` Stefan Hajnoczi
2016-12-20 14:02 ` Stefan Hajnoczi
2016-12-20 16:02 ` Alex Bennée
2016-12-20 16:13 ` Stefan Hajnoczi
2016-12-21 5:57 ` Pavel Dovgalyuk
2016-12-21 11:05 ` Stefan Hajnoczi
2017-01-11 7:10 ` Pavel Dovgalyuk
2017-01-11 11:41 ` Alex Bennée
2017-01-12 8:07 ` Pavel Dovgalyuk
2017-01-20 17:33 ` Alex Bennée [this message]
2017-01-23 7:50 ` Pavel Dovgalyuk
2017-01-23 9:38 ` 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=87mveleiw8.fsf@linaro.org \
--to=alex.bennee@linaro.org \
--cc=dovgaluk@ispras.ru \
--cc=pavel.dovgaluk@ispras.ru \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.com \
/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).