All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Emilio G. Cota" <cota@braap.org>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Alex Bennée" <alex.bennee@linaro.org>,
	"MTTCG Devel" <mttcg@greensocs.com>,
	"QEMU Developers" <qemu-devel@nongnu.org>,
	a.rigo@virtualopensystems.com,
	"Sergey Fedorov" <serge.fdrv@gmail.com>,
	"Richard Henderson" <rth@twiddle.net>,
	"Frederic Konrad" <fred.konrad@greensocs.com>
Subject: Re: [Qemu-devel] Making cputlb.c operations safe for MTTCG
Date: Tue, 27 Sep 2016 18:29:35 -0400	[thread overview]
Message-ID: <20160927222935.GA21144@flamenco> (raw)
In-Reply-To: <5d48957b-780b-aa9c-7061-cba6808909b4@redhat.com>

On Tue, Sep 27, 2016 at 18:16:45 +0200, Paolo Bonzini wrote:
> Anyhow, the next step is to merge either cmpxchg-based atomics
> or iothread-free single-threaded TCG.  Either will do. :)
> 
> I think that even iothread-free single-threaded TCG requires this
> TLB stuff, because the iothread's address_space_write (and hence
> invalidate_and_set_dirty) can race against the TCG thread's
> code generation.

What's a quick-and-dirty way to disable the fast-path TLB lookups?
Alex: you told me the monitor has an option for this, but I can't
find it. I'm looking for something that'd go in tcg/i386 to simply
bypass the fast path.

Forcing the slow TLB lookup would be an easy way to then implement
a per-TLB seqlock. I think TLB corruption might explain the crashes I
see when booting Ubuntu in a many-core guest (running on a many-core
host).

Thanks,

		Emilio

  parent reply	other threads:[~2016-09-27 22:29 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-26 12:09 [Qemu-devel] Making cputlb.c operations safe for MTTCG Alex Bennée
2016-07-26 14:03 ` [Qemu-devel] [PATCH] cputlb: make tlb_reset_dirty " Alex Bennée
2016-08-01 14:54 ` [Qemu-devel] Making cputlb.c operations " Paolo Bonzini
2016-08-02  6:37   ` Alex Bennée
2016-08-02 10:26     ` Paolo Bonzini
2016-08-03 17:25     ` Richard Henderson
2016-08-03 20:56       ` Paolo Bonzini
2016-09-27 16:16     ` Paolo Bonzini
2016-09-27 22:15       ` Alex Bennée
2016-09-27 22:29       ` Emilio G. Cota [this message]
2016-09-27 23:04         ` Alex Bennée
2016-09-27 23:05         ` Richard Henderson
2016-09-27 23:32           ` Alex Bennée
2016-09-28  0:34             ` Richard Henderson

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=20160927222935.GA21144@flamenco \
    --to=cota@braap.org \
    --cc=a.rigo@virtualopensystems.com \
    --cc=alex.bennee@linaro.org \
    --cc=fred.konrad@greensocs.com \
    --cc=mttcg@greensocs.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rth@twiddle.net \
    --cc=serge.fdrv@gmail.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 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.