From: Paolo Bonzini <pbonzini@redhat.com>
To: "Alex Bennée" <alex.bennee@linaro.org>,
"QEMU Devel" <qemu-devel@nongnu.org>,
mttcg@greensocs.com, mark.burton@greensocs.com,
fred.konrad@greensocs.com, "Richard Henderson" <rth@twiddle.net>,
"Peter Crosthwaite" <crosthwaitepeter@gmail.com>,
"Peter Maydell" <peter.maydell@linaro.org>
Subject: Re: [Qemu-devel] Rationalising exit_request, cpu->exit_request and tcg_exit_req?
Date: Wed, 16 Dec 2015 18:21:48 +0100 [thread overview]
Message-ID: <56719DAC.2030000@redhat.com> (raw)
In-Reply-To: <87zixafh89.fsf@linaro.org>
On 16/12/2015 18:14, Alex Bennée wrote:
>
> While looking at Fred's current MTTCG WIP branch I ran into a problem
> where:
>
> - async_safe_work_pending() was true
> - this triggered setting cpu->exit_request
> - however we never left tcg_exec_all()
> - because the global exit_request wasn't set
> - hence qemu_tcg_wait_io_event() never drained the async work queue
exit_request should disappear with MTTCG. It should only have
cpu->tcg_exit_req and cpu->exit_request.
> While trying to understand why we have both a cpu and a global
> exit_request I then discovered there is also cpu->tcg_exit_req which is
> the actual variable the TCG examines. This leads to sequences like:
> This seems to me to be slightly insane as we now have 3 variables that
> struggle to be kept in sync. Could all this not be rationalised into a
> single variable or am I missing a subtly in their different semantics?
They do.
cpu->tcg_exit_req is the one that is set from generated code. It is set
if you do not have to exit cpu_exec.
cpu->exit_request and exit_request are both necessary, in order to
synchronize exits with the setting of tcg_current_cpu. Again, this is
only needed in single-threaded TCG, because MTTCG gets rid of
tcg_current_cpu. It's documented here:
http://article.gmane.org/gmane.comp.emulators.qemu/357210.
> I don't know if there is clean-up that can happen in master or if this
> all needs to be done in the mttcg work but would it make sense just to
> keep cpu->exit_request,
Yes, and it's actually necessary. :)
> I did have a brief look at the KVM side of the code and it only seems to
> reference cpu->exit_request so I think the rest of this is a TCG
> problem.
Yes. With MTTCG you still need cpu->tcg_exit_req because you still have
something like KVM's kernel- and userspace-vmexits. In TCG the
lightweight exits are those that do not leave cpu_exec. Those only set
cpu->tcg_exit_req.
Paolo
prev parent reply other threads:[~2015-12-16 17:22 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-16 17:14 [Qemu-devel] Rationalising exit_request, cpu->exit_request and tcg_exit_req? Alex Bennée
2015-12-16 17:21 ` Paolo Bonzini [this message]
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=56719DAC.2030000@redhat.com \
--to=pbonzini@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=crosthwaitepeter@gmail.com \
--cc=fred.konrad@greensocs.com \
--cc=mark.burton@greensocs.com \
--cc=mttcg@greensocs.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.