From: "Emilio G. Cota" <cota@braap.org>
To: Richard Henderson <rth@twiddle.net>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [RFC 6/7] [XXX] tcg: make TCGContext thread-local for softmmu
Date: Fri, 30 Jun 2017 21:54:17 -0400 [thread overview]
Message-ID: <20170701015417.GA1320@flamenco> (raw)
In-Reply-To: <736ed9fa-219f-64e0-70ba-9e5ef1b63b14@twiddle.net>
On Fri, Jun 30, 2017 at 01:18:58 -0700, Richard Henderson wrote:
> On 06/29/2017 01:28 PM, Emilio G. Cota wrote:
> >This will allow us to generate TCG code in parallel.
> >
> >User-mode is kept out of this: contention due to concurrent translation
> >is more commonly found in full-system mode (e.g. booting a many-core guest).
> >
> >XXX: For now, only convert arm/a64, since these are the only guests that
> >have proper MTTCG support.
>
> Not true. TCG_GUEST_DEFAULT_MO suggests we have 4.
Yes, sorry that was outdated. I'm testing arm/a64 because I can boot
many cores on a64.
> >XXX: This is calling prologue_init once per vCPU, i.e. each TCGContext
> > gets a different prologue/epilogue (all of them with the same
> > contents though). Far from ideal, but for an experiment it
> > "should" work, right?
>
> Um... sure. But surely there's a better way. Perhaps copying the main
> thread's tcg_ctx? That'd be after prologue, and target globals are created.
> That would avoid the need to make all the target cpu_* globals be
> thread-local, for instance.
>
> Of course, now that I think of it, this implies that my tcg patches to use
> pointers instead of indicies is not the Way Forward...
Didn't consider this, but after looking at the code (sans your patchset)
I don't see why this wouldn't work -- would be great to avoid touching
target code, as you point out below.
> > /* Share the TCG temporaries common between 32 and 64 bit modes. */
> >-extern TCGv_env cpu_env;
> >-extern TCGv_i32 cpu_NF, cpu_ZF, cpu_CF, cpu_VF;
> >-extern TCGv_i64 cpu_exclusive_addr;
> >-extern TCGv_i64 cpu_exclusive_val;
> >+extern TCG_THREAD TCGv_env cpu_env;
> >+extern TCG_THREAD TCGv_i32 cpu_NF, cpu_ZF, cpu_CF, cpu_VF;
> >+extern TCG_THREAD TCGv_i64 cpu_exclusive_addr;
> >+extern TCG_THREAD TCGv_i64 cpu_exclusive_val;
>
> It would be Really Good if we could avoid this in the end.
> I see that it's the quickest way to test for now though.
>
> >@@ -887,7 +893,7 @@ typedef struct TCGOpDef {
> > #endif
> > } TCGOpDef;
> >-extern TCGOpDef tcg_op_defs[];
> >+extern TCG_THREAD TCGOpDef tcg_op_defs[];
>
> Why? It's constant after startup.
I was just going for a mass conversion first to see whether this
could ever work. Will refine it.
Thanks,
E.
next prev parent reply other threads:[~2017-07-01 1:54 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-29 20:28 [Qemu-devel] [RFC 0/7] tcg: parallel code generation (Work in Progress) Emilio G. Cota
2017-06-29 20:28 ` [Qemu-devel] [RFC 1/7] exec-all: fix typos in TranslationBlock's documentation Emilio G. Cota
2017-06-30 6:17 ` Richard Henderson
2017-06-29 20:28 ` [Qemu-devel] [RFC 2/7] translate-all: add out_size field to TranslationBlock Emilio G. Cota
2017-06-30 6:31 ` Richard Henderson
2017-06-29 20:28 ` [Qemu-devel] [RFC 3/7] translate-all: use a binary search tree to track TBs in TBContext Emilio G. Cota
2017-06-30 7:41 ` Richard Henderson
2017-06-30 7:49 ` Richard Henderson
2017-06-30 14:55 ` Emilio G. Cota
2017-06-29 20:28 ` [Qemu-devel] [RFC 4/7] translate-all: report correct avg host TB size Emilio G. Cota
2017-06-30 7:50 ` Richard Henderson
2017-06-29 20:28 ` [Qemu-devel] [RFC 5/7] tcg: take tb_ctx out of TCGContext Emilio G. Cota
2017-06-30 7:58 ` Richard Henderson
2017-06-29 20:28 ` [Qemu-devel] [RFC 6/7] [XXX] tcg: make TCGContext thread-local for softmmu Emilio G. Cota
2017-06-30 8:18 ` Richard Henderson
2017-07-01 1:54 ` Emilio G. Cota [this message]
2017-07-01 1:47 ` [Qemu-devel] [PATCH] fixup: missed some TLS variables Emilio G. Cota
2017-06-29 20:28 ` [Qemu-devel] [RFC 7/7] [XXX] translate-all: generate TCG code without holding tb_lock Emilio G. Cota
2017-06-30 8:25 ` [Qemu-devel] [RFC 0/7] tcg: parallel code generation (Work in Progress) Richard Henderson
2017-07-01 2:00 ` Emilio G. Cota
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=20170701015417.GA1320@flamenco \
--to=cota@braap.org \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
/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).