From: Fabiano Rosas <farosas@linux.ibm.com>
To: Bruno Piazera Larsen <bruno.larsen@eldorado.org.br>,
David Gibson <david@gibson.dropbear.id.au>
Cc: Thomas Huth <thuth@redhat.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
Andre Fernando da Silva <andre.silva@eldorado.org.br>,
Lucas Mateus Martins Araujo e Castro
<lucas.araujo@eldorado.org.br>,
Fernando Eckhardt Valle <fernando.valle@eldorado.org.br>,
"qemu-ppc@nongnu.org" <qemu-ppc@nongnu.org>,
"lagarcia@br.ibm.com" <lagarcia@br.ibm.com>,
Matheus Kowalczuk Ferst <matheus.ferst@eldorado.org.br>,
Luis Fernando Fujita Pires <luis.pires@eldorado.org.br>
Subject: RE: [PATCH 1/4] target/ppc: Code motion required to build disabling tcg
Date: Tue, 13 Apr 2021 18:38:57 -0300 [thread overview]
Message-ID: <87o8eh50ge.fsf@linux.ibm.com> (raw)
In-Reply-To: <CP2PR80MB449996D26DEA4C27397EEF14C74F9@CP2PR80MB4499.lamprd80.prod.outlook.com>
Bruno Piazera Larsen <bruno.larsen@eldorado.org.br> writes:
>> I'm actually not sure if we'll want translate_init.c for !tcg builds.
>> It's *primarily* for TCG, but we still need at least some of the cpu
>> state structure for KVM, and some of that is initialized in
>> translate_init.
>>
>> I think it will probably make more sense to leave it in for a first
>> cut. Later refinement might end up removing it.
>>
>> The whole #include translate_init.c.inc thing might make for some
>> awkward fiddling in this, of course.
>
> I just checked, there is going to be some shuffling of functions
> around, as there are some static variables defined on translate.c,
> and used in translate_init.c.inc, some functions needed for KVM
> on translate.c and some TCG only functions in the
> translate_init.c.inc.
>
> The trivial path is to:
> * rename translate_init.c.inc to cpu_init.c (since it has to do with
> initial definitions for CPUs, and it's not related to translating
> anymore);
Below I'm assuming we have one place for TCG stuff and other for KVM
stuff, whatever this particular discussion ends up producing.
> * move gen_write_xer and gen_read_xer into cpu_init.c, as they're
> used for some sprs, and whatever needs to be moved with it
I'd leave them where they are currently. Instead what I think we should
do is to find a way to not need the uea/oea/hea|read/write callbacks
with KVM.
Maybe extract a function from _spr_register that sets what is common for
both tcg and kvm (num, name, initial_value, AFAICT). Then alter the
gen_spr* functions to first create all registers and then call both
configs to supplement:
//tcg.c
static void tcg_gen_spr_generic(CPUPPCState *env)
{
// these only set the callbacks
spr_register(env, SPR_FOO,
SPR_NOACCESS, SPR_NOACCESS,
&spr_read_foo, &spr_write_foo);
spr_register(env, SPR_BAR,
SPR_NOACCESS, SPR_NOACCESS,
&spr_read_bar, &spr_write_bar);
}
//kvm.c
static void kvm_gen_spr_generic(CPUPPCState *env)
{
// these only set one_reg_id
spr_register_kvm(env, SPR_FOO, KVM_REG_PPC_FOO);
spr_register_kvm(env, SPR_BAR, KVM_REG_PPC_BAR);
}
//common.c
static void gen_spr_generic(CPUPPCState *env)
{
// these only set name, num, initial value
spr_register(env, SPR_FOO, "FOO", 0xf00);
spr_register(env, SPR_BAR, "BAR", 0xb4d);
...
// have these stubbed if not chosen via config
tcg_gen_spr_generic(env);
kvm_gen_spr_generic(env);
}
init_ppc_proc()
{
...
gen_spr_generic(env);
...
}
Can anyone see a better way? That would be much easier if we could
afford to say that TCG and KVM are mutually exclusive for a given build,
but I don't think they are.
> * move is_indirect_opcode and ind_table to translate.c, since they
> are used to translate ppc instructions, and the things defined for
> these functions
Makes sense. This and the other part below about callback tables would
be mostly about moving code so it's a candidate for coming soon.
> * Figure out what needs to be added to the includes for both
> files to compile
> * move opcodes and invalid_handler into cpu_init.c, because they
> are only used by stuff in this file.
>
> I'm just not sure about this last point. The stuff that use opcodes
> create the callback tables for TCG, AFAICT. The better plan would
> be to move all of that to tanslate.c, but might be a lot.
translate.c seems like a better place indeed.
next prev parent reply other threads:[~2021-04-13 21:41 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-13 17:43 [PATCH 1/4] target/ppc: Code motion required to build disabling tcg Bruno Piazera Larsen
2021-04-13 21:38 ` Fabiano Rosas [this message]
2021-04-14 12:04 ` Bruno Piazera Larsen
2021-04-14 20:05 ` Fabiano Rosas
2021-04-19 5:23 ` David Gibson
2021-04-14 19:37 ` Richard Henderson
2021-04-14 20:07 ` Bruno Piazera Larsen
2021-04-14 20:32 ` Richard Henderson
2021-04-19 5:21 ` David Gibson
-- strict thread matches above, loose matches on Subject: below --
2021-04-22 12:34 Bruno Piazera Larsen
2021-04-22 19:35 ` Fabiano Rosas
2021-04-23 0:08 ` David Gibson
2021-04-23 13:28 ` Fabiano Rosas
2021-04-27 1:29 ` David Gibson
2021-04-20 19:02 Bruno Piazera Larsen
2021-04-21 5:13 ` David Gibson
2021-04-19 14:40 Bruno Piazera Larsen
2021-04-20 1:20 ` David Gibson
2021-04-12 12:05 Bruno Piazera Larsen
2021-04-12 13:56 ` Fabiano Rosas
2021-04-13 6:40 ` David Gibson
2021-04-09 15:19 [RFC PATCH 0/4] target/ppc: add disable-tcg option Bruno Larsen (billionai)
2021-04-09 15:19 ` [PATCH 1/4] target/ppc: Code motion required to build disabling tcg Bruno Larsen (billionai)
2021-04-09 19:48 ` Fabiano Rosas
2021-04-12 4:34 ` David Gibson
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=87o8eh50ge.fsf@linux.ibm.com \
--to=farosas@linux.ibm.com \
--cc=andre.silva@eldorado.org.br \
--cc=bruno.larsen@eldorado.org.br \
--cc=david@gibson.dropbear.id.au \
--cc=fernando.valle@eldorado.org.br \
--cc=lagarcia@br.ibm.com \
--cc=lucas.araujo@eldorado.org.br \
--cc=luis.pires@eldorado.org.br \
--cc=matheus.ferst@eldorado.org.br \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=thuth@redhat.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.