From: Paolo Bonzini <pbonzini@redhat.com>
To: alvise rigo <a.rigo@virtualopensystems.com>
Cc: "MTTCG Devel" <mttcg@listserver.greensocs.com>,
"Peter Maydell" <peter.maydell@linaro.org>,
"Mark Burton" <mark.burton@greensocs.com>,
"Claudio Fontana" <claudio.fontana@huawei.com>,
"QEMU Developers" <qemu-devel@nongnu.org>,
"Jani Kokkonen" <jani.kokkonen@huawei.com>,
"tech@virtualopensystems.com" <tech@virtualopensystems.com>,
"Alex Bennée" <alex.bennee@linaro.org>,
"KONRAD Frédéric" <fred.konrad@greensocs.com>
Subject: Re: [Qemu-devel] [mttcg] cputlb: Use async tlb_flush_by_mmuidx
Date: Mon, 7 Mar 2016 22:18:09 +0100 [thread overview]
Message-ID: <56DDF011.4090301@redhat.com> (raw)
In-Reply-To: <CAH47eN3e+Kk+ef7Y0Y5HA=yp87kZoUXwdyfPu9kmMR=b8kmapw@mail.gmail.com>
On 04/03/2016 15:28, alvise rigo wrote:
> A small update on this. I have a working implementation of the "halted
> state" mechanism for waiting all the pending flushes to be completed.
> However, the way I'm going back to the cpus.c loop (the while(1) in
> qemu_tcg_cpu_thread_fn) is a bit convoluted. In the case of the TLB ops
> that always end the TB, a simple cpu_exit() allows me to go back to the
> main loop. I think in this case we can also use the cpu_loop_exit(),
> though making the code a bit more complicated since the PC would require
> some adjustments.
I think in both cases the function to use is cpu_loop_exit_restore. It
will restart execution of the current instruction so it should be fine
as long as you don't call it unconditionally.
If you're not calling it directly from the helper, you need to save
GETPC() in the helper and propagate it down to the call site. Then the
call site can use it as the last argument. For an example see
helper_ljmp_protected's call to switch_tss_ra in target-i386/seg_helper.c.
> I wanted then to apply the same "halted state" to the LoadLink helper,
> since also this one might cause some flush requests.
Interesting, where is this documented in the ARM ARM?
> In this case, we
> can not just call cpu_loop_exit() in that the guest code would miss the
> returned value. Forcing the LDREX instruction to also end the TB through
> an empty 'is_jmp' condition did the trick allowing once again to use
> cpu_exit(). Is there another better solution?
Perhaps cpu_loop_exit_restore()?
Paolo
next prev parent reply other threads:[~2016-03-07 21:18 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-29 13:16 [Qemu-devel] [mttcg] cputlb: Use async tlb_flush_by_mmuidx Alvise Rigo
2016-02-29 13:21 ` Peter Maydell
2016-02-29 13:50 ` Paolo Bonzini
2016-02-29 13:55 ` Peter Maydell
2016-02-29 14:02 ` alvise rigo
2016-02-29 14:06 ` Paolo Bonzini
2016-02-29 14:18 ` alvise rigo
2016-03-04 14:28 ` alvise rigo
2016-03-07 20:18 ` Alex Bennée
2016-03-07 21:18 ` Paolo Bonzini [this message]
2016-03-11 11:08 ` alvise rigo
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=56DDF011.4090301@redhat.com \
--to=pbonzini@redhat.com \
--cc=a.rigo@virtualopensystems.com \
--cc=alex.bennee@linaro.org \
--cc=claudio.fontana@huawei.com \
--cc=fred.konrad@greensocs.com \
--cc=jani.kokkonen@huawei.com \
--cc=mark.burton@greensocs.com \
--cc=mttcg@listserver.greensocs.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=tech@virtualopensystems.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).