qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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

  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).