All of lore.kernel.org
 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 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.