From: Paolo Bonzini <pbonzini@redhat.com>
To: "Alex Bennée" <alex.bennee@linaro.org>,
qemu-devel@nongnu.org, mttcg@listserver.greensocs.com
Cc: mark.burton@greensocs.com, claudio.fontana@huawei.com,
a.rigo@virtualopensystems.com, "Emilio G. Cota" <cota@braap.org>,
Alexander Spyridakis <a.spyridakis@virtualopensystems.com>,
"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
fred.konrad@greensocs.com
Subject: Re: [Qemu-devel] MTTCG Tasks (kvmforum summary)
Date: Fri, 4 Sep 2015 11:25:33 +0200 [thread overview]
Message-ID: <55E9638D.4010006@redhat.com> (raw)
In-Reply-To: <87fv2uipzf.fsf@linaro.org>
On 04/09/2015 09:49, Alex Bennée wrote:
> * Signal free qemu_cpu_kick (Paolo)
>
> I don't know much about this patch set but I assume this avoids the need
> to catch signals and longjmp about just to wake up?
It was part of Fred's patches, so I've extracted it to its own series.
Removing 150 lines of code can't hurt.
> * Memory barrier support (need RFC for discussion)
>
> I came to KVM forum with a back of the envelope idea we could implement
> one or two barrier ops (acquire/release?). Various suggestions of other
> types of memory behaviour have been suggested.
>
> I'll try to pull together an RFC patch with design outline for
> discussion. It would be nice to be able to demonstrate barrier failures
> in my test cases as well ;-)
Emilio has something about it in his own MTTCG implementation.
> * longjmp in cpu_exec
>
> Paolo is fairly sure that if you take page faults while IRQs happening
> problems will occur with cpu->interrupt_request. Does it need to take
> the BQL?
>
> I'd like to see if we can get a torture test to stress this code
> although it will require IPI support in the unit tests.
It's x86-specific (hardware interrupts push to the stack and can cause a
page fault or other exception), so a unit test can be written for it.
> * tlb_flush and dmb behaviour (am I waiting for TLB flush?)
>
> I think this means we need explicit memory barriers to sync updates to
> the tlb.
Yes.
> * tb_find_fast outside the lock
>
> Currently it is a big performance win as the tb_find_fast has a lot of
> contention with other threads. However there is concern it needs to be
> properly protected.
This, BTW, can be done for user-mode emulation first, so it can go in
early. Same for RCU-ized code_gen_buffer.
> * What to do about icount?
>
> What is the impact of multi-thread on icount? Do we need to disable it
> for MTTCG or can it be correct per-cpu? Can it be updated lock-step?
>
> We need some input from the guys that use icount the most.
That means Edgar. :)
Paolo
next prev parent reply other threads:[~2015-09-04 9:25 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-04 7:49 [Qemu-devel] MTTCG Tasks (kvmforum summary) Alex Bennée
2015-09-04 8:10 ` Frederic Konrad
2015-09-04 9:25 ` Paolo Bonzini [this message]
2015-09-04 9:41 ` Edgar E. Iglesias
2015-09-04 10:18 ` Mark Burton
2015-09-04 13:00 ` Lluís Vilanova
2015-09-04 13:10 ` dovgaluk
2015-09-04 14:59 ` Lluís Vilanova
2015-09-04 9:45 ` dovgaluk
2015-09-04 12:38 ` Lluís Vilanova
2015-09-04 12:46 ` Mark Burton
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=55E9638D.4010006@redhat.com \
--to=pbonzini@redhat.com \
--cc=a.rigo@virtualopensystems.com \
--cc=a.spyridakis@virtualopensystems.com \
--cc=alex.bennee@linaro.org \
--cc=claudio.fontana@huawei.com \
--cc=cota@braap.org \
--cc=edgar.iglesias@gmail.com \
--cc=fred.konrad@greensocs.com \
--cc=mark.burton@greensocs.com \
--cc=mttcg@listserver.greensocs.com \
--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).