qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC v9 10/32] i386: move TCG cpu class initialization out of helper


From: Alex Bennée
Subject: Re: [RFC v9 10/32] i386: move TCG cpu class initialization out of helper.c
Date: Wed, 09 Dec 2020 10:23:58 +0000
User-agent: mu4e 1.5.7; emacs 28.0.50

Claudio Fontana <cfontana@suse.de> writes:

> Signed-off-by: Claudio Fontana <cfontana@suse.de>
> ---
>  target/i386/cpu.c             |  33 ++++------
>  target/i386/cpu.h             |  97 ++---------------------------
>  target/i386/helper-tcg.h      | 112 ++++++++++++++++++++++++++++++++++
>  target/i386/helper.c          |  23 -------
>  target/i386/meson.build       |   1 +
>  target/i386/tcg-cpu.c         |  71 +++++++++++++++++++++
>  target/i386/tcg-cpu.h         |  15 +++++
>  target/i386/tcg/bpt_helper.c  |   1 +
>  target/i386/tcg/cc_helper.c   |   1 +
>  target/i386/tcg/excp_helper.c |   1 +
>  target/i386/tcg/fpu_helper.c  |  33 +++++-----
>  target/i386/tcg/int_helper.c  |   1 +
>  target/i386/tcg/mem_helper.c  |   1 +
>  target/i386/tcg/misc_helper.c |   1 +
>  target/i386/tcg/mpx_helper.c  |   1 +
>  target/i386/tcg/seg_helper.c  |   1 +
>  target/i386/tcg/smm_helper.c  |   2 +
>  target/i386/tcg/svm_helper.c  |   1 +
>  target/i386/tcg/translate.c   |   1 +
>  19 files changed, 244 insertions(+), 153 deletions(-)
>  create mode 100644 target/i386/helper-tcg.h
>  create mode 100644 target/i386/tcg-cpu.c
>  create mode 100644 target/i386/tcg-cpu.h
>
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index b9bd249c8f..3462d0143f 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -24,6 +24,8 @@
>  #include "qemu/qemu-print.h"
>  
>  #include "cpu.h"
> +#include "tcg-cpu.h"
> +#include "helper-tcg.h"
>  #include "exec/exec-all.h"
>  #include "sysemu/kvm.h"
>  #include "sysemu/reset.h"
> @@ -1495,7 +1497,8 @@ static inline uint64_t x86_cpu_xsave_components(X86CPU 
> *cpu)
>             cpu->env.features[FEAT_XSAVE_COMP_LO];
>  }
>  
> -const char *get_register_name_32(unsigned int reg)
> +/* Return name of 32-bit register, from a R_* constant */
> +static const char *get_register_name_32(unsigned int reg)
>  {
>      if (reg >= CPU_NB_REGS32) {
>          return NULL;
> @@ -7012,13 +7015,6 @@ static void x86_cpu_set_pc(CPUState *cs, vaddr value)
>      cpu->env.eip = value;
>  }
>  
> -static void x86_cpu_synchronize_from_tb(CPUState *cs, TranslationBlock *tb)
> -{
> -    X86CPU *cpu = X86_CPU(cs);
> -
> -    cpu->env.eip = tb->pc - tb->cs_base;
> -}
> -
>  int x86_cpu_pending_interrupt(CPUState *cs, int interrupt_request)
>  {
>      X86CPU *cpu = X86_CPU(cs);
> @@ -7252,17 +7248,18 @@ static void x86_cpu_common_class_init(ObjectClass 
> *oc, void *data)
>      cc->class_by_name = x86_cpu_class_by_name;
>      cc->parse_features = x86_cpu_parse_featurestr;
>      cc->has_work = x86_cpu_has_work;
> +
>  #ifdef CONFIG_TCG
> -    cc->do_interrupt = x86_cpu_do_interrupt;
> -    cc->cpu_exec_interrupt = x86_cpu_exec_interrupt;
> -#endif
> +    tcg_cpu_common_class_init(cc);

Are we likely to have clashing names here as other arches get converted?
tcg_x86_cpu_common_class_init or x86_cpu_common_class_init?

<snip>
> diff --git a/target/i386/tcg-cpu.c b/target/i386/tcg-cpu.c
> new file mode 100644
> index 0000000000..628dd29fe7
> --- /dev/null
> +++ b/target/i386/tcg-cpu.c
> @@ -0,0 +1,71 @@
<snip>
> +
> +void tcg_cpu_common_class_init(CPUClass *cc)
> +{
> +    cc->do_interrupt = x86_cpu_do_interrupt;
> +    cc->cpu_exec_interrupt = x86_cpu_exec_interrupt;
> +    cc->synchronize_from_tb = x86_cpu_synchronize_from_tb;
> +    cc->cpu_exec_enter = x86_cpu_exec_enter;
> +    cc->cpu_exec_exit = x86_cpu_exec_exit;
> +    cc->tcg_initialize = tcg_x86_init;
> +    cc->tlb_fill = x86_cpu_tlb_fill;
> +#ifndef CONFIG_USER_ONLY
> +    cc->debug_excp_handler = breakpoint_handler;
> +#endif
> +}

Oh I see this moves down to target/i386/tcg/ eventually. Maybe we should
just create the new file in place so it's easier to follow the changes
as we convert to a proper abstracted class?

-- 
Alex Bennée



reply via email to

[Prev in Thread] Current Thread [Next in Thread]