qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Eduardo Habkost <ehabkost@redhat.com>
To: Claudio Fontana <cfontana@suse.de>
Cc: "Paul Durrant" <paul@xen.org>, "Jason Wang" <jasowang@redhat.com>,
	qemu-devel@nongnu.org, "Peter Xu" <peterx@redhat.com>,
	haxm-team@intel.com, "Colin Xu" <colin.xu@intel.com>,
	"Olaf Hering" <ohering@suse.de>,
	"Stefano Stabellini" <sstabellini@kernel.org>,
	"Bruce Rogers" <brogers@suse.com>,
	"Emilio G . Cota" <cota@braap.org>,
	"Anthony Perard" <anthony.perard@citrix.com>,
	"Philippe Mathieu-Daudé" <philmd@redhat.com>,
	"Laurent Vivier" <lvivier@redhat.com>,
	"Thomas Huth" <thuth@redhat.com>,
	"Richard Henderson" <richard.henderson@linaro.org>,
	"Cameron Esfahani" <dirty@apple.com>,
	"Dario Faggioli" <dfaggioli@suse.com>,
	"Roman Bolshakov" <r.bolshakov@yadro.com>,
	"Sunil Muthuswamy" <sunilmut@microsoft.com>,
	"Marcelo Tosatti" <mtosatti@redhat.com>,
	"Wenchao Wang" <wenchao.wang@intel.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>
Subject: Re: [RFC v6 10/11] accel: introduce AccelCPUClass extending CPUClass
Date: Fri, 27 Nov 2020 12:06:34 -0500	[thread overview]
Message-ID: <20201127170634.GA2271382@habkost.net> (raw)
In-Reply-To: <20201126223218.31480-11-cfontana@suse.de>

On Thu, Nov 26, 2020 at 11:32:17PM +0100, Claudio Fontana wrote:
> add a new optional interface to CPUClass,
> which allows accelerators to extend the CPUClass
> with additional accelerator-specific initializations.
> 
> Signed-off-by: Claudio Fontana <cfontana@suse.de>
> ---
[...]
> +static void accel_init_cpu_int_aux(ObjectClass *klass, void *opaque)
> +{
> +    CPUClass *cc = CPU_CLASS(klass);
> +    AccelCPUClass *accel_cpu_interface = opaque;
> +
> +    cc->accel_cpu_interface = accel_cpu_interface;
> +    if (accel_cpu_interface->cpu_class_init) {
> +        accel_cpu_interface->cpu_class_init(cc);
> +    }
> +}

So, now that the approach we're following to trigger the
accel_init_cpu*() call is less controversial (thanks for your
patience!), we can try to address the monkey patching issue:

Monkey patching classes like this is acceptable as an initial
solution, but I'd like us to have a plan to eventually get rid of
it.  Monkey patching CPU classes makes querying of CPU model
information less predictable and subtly dependent on QEMU
initialization state.

Removing CPUClass.accel_cpu_interface may be easy, because it
should be possible to just call current_accel() when realizing
CPUs.  Getting rid of CPUClass.cpu_class_init might be more
difficult, depending on what the ->cpu_class_init() function is
doing.

> +
> +/* initialize the arch-specific accel CpuClass interfaces */
> +static void accel_init_cpu_interfaces(AccelClass *ac, const char *cpu_type)
> +{
> +    const char *ac_name; /* AccelClass name */
> +    char *acc_name;      /* AccelCPUClass name */
> +    ObjectClass *acc;    /* AccelCPUClass */
> +
> +    ac_name = object_class_get_name(OBJECT_CLASS(ac));
> +    g_assert(ac_name != NULL);
> +
> +    acc_name = g_strdup_printf("%s-%s", ac_name, CPU_RESOLVING_TYPE);
> +    acc = object_class_by_name(acc_name);
> +    g_free(acc_name);
> +
> +    if (acc) {
> +        object_class_foreach(accel_init_cpu_int_aux, cpu_type, false, acc);
> +    }
> +}
> +
>  void accel_init_interfaces(AccelClass *ac, const char *cpu_type)
>  {
>  #ifndef CONFIG_USER_ONLY
>      accel_init_ops_interfaces(ac);
>  #endif /* !CONFIG_USER_ONLY */
> +
> +    accel_init_cpu_interfaces(ac, cpu_type);
>  }
[...]

-- 
Eduardo



  parent reply	other threads:[~2020-11-27 17:08 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-26 22:32 [RFC v6 00/11] i386 cleanup Claudio Fontana
2020-11-26 22:32 ` [RFC v6 01/11] i386: move kvm accel files into kvm/ Claudio Fontana
2020-11-26 22:32 ` [RFC v6 02/11] i386: move whpx accel files into whpx/ Claudio Fontana
2020-11-26 22:32 ` [RFC v6 03/11] i386: move hax accel files into hax/ Claudio Fontana
2020-11-26 22:32 ` [RFC v6 04/11] i386: hvf: remove stale MAINTAINERS entry for old hvf stubs Claudio Fontana
2020-11-26 22:32 ` [RFC v6 05/11] i386: move TCG accel files into tcg/ Claudio Fontana
2020-11-26 22:32 ` [RFC v6 06/11] i386: move cpu dump out of helper.c into cpu-dump.c Claudio Fontana
2020-11-26 22:32 ` [RFC v6 07/11] i386: move TCG cpu class initialization out of helper.c Claudio Fontana
2020-11-27 19:04   ` Eduardo Habkost
2020-11-27 19:47     ` Claudio Fontana
2020-11-27 20:43       ` Eduardo Habkost
2020-11-29 11:53         ` Claudio Fontana
2020-11-26 22:32 ` [RFC v6 08/11] accel: extend AccelState and AccelClass to user-mode Claudio Fontana
2021-01-11 18:43   ` Claudio Fontana
2021-01-12  9:23     ` Claudio Fontana
2020-11-26 22:32 ` [RFC v6 09/11] accel: replace struct CpusAccel with AccelOpsClass Claudio Fontana
2020-11-26 22:32 ` [RFC v6 10/11] accel: introduce AccelCPUClass extending CPUClass Claudio Fontana
2020-11-27  6:21   ` Paolo Bonzini
2020-11-27  8:59     ` Claudio Fontana
2020-11-27 11:22       ` Claudio Fontana
2020-11-27 11:41         ` Claudio Fontana
2020-11-27 13:31           ` Paolo Bonzini
2020-11-27 13:32             ` Claudio Fontana
2020-12-18 17:51     ` Claudio Fontana
2020-12-18 18:01       ` Paolo Bonzini
2020-12-18 18:04         ` Claudio Fontana
2020-12-18 21:55           ` Claudio Fontana
2020-12-18 22:30             ` Claudio Fontana
2020-12-18 23:00               ` Claudio Fontana
2021-01-11 16:13                 ` Claudio Fontana
2021-01-11 18:08                   ` Claudio Fontana
2021-01-11 22:35                   ` Eduardo Habkost
2021-01-11 23:35                     ` Claudio Fontana
2020-11-27 17:06   ` Eduardo Habkost [this message]
2020-11-27 17:58     ` Claudio Fontana
2020-11-27 18:13       ` Eduardo Habkost
2020-11-27 18:20         ` Claudio Fontana
2020-11-26 22:32 ` [RFC v6 11/11] i386: split cpu accelerators from cpu.c, using AccelCPUClass Claudio Fontana
2020-11-27 17:41   ` Eduardo Habkost
2020-11-27 17:53     ` Claudio Fontana
2020-11-27 18:09       ` Eduardo Habkost
2020-11-27 18:16         ` Claudio Fontana
2020-11-27 18:33           ` Eduardo Habkost

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=20201127170634.GA2271382@habkost.net \
    --to=ehabkost@redhat.com \
    --cc=anthony.perard@citrix.com \
    --cc=brogers@suse.com \
    --cc=cfontana@suse.de \
    --cc=colin.xu@intel.com \
    --cc=cota@braap.org \
    --cc=dfaggioli@suse.com \
    --cc=dirty@apple.com \
    --cc=haxm-team@intel.com \
    --cc=jasowang@redhat.com \
    --cc=lvivier@redhat.com \
    --cc=mtosatti@redhat.com \
    --cc=ohering@suse.de \
    --cc=paul@xen.org \
    --cc=pbonzini@redhat.com \
    --cc=peterx@redhat.com \
    --cc=philmd@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=r.bolshakov@yadro.com \
    --cc=richard.henderson@linaro.org \
    --cc=sstabellini@kernel.org \
    --cc=sunilmut@microsoft.com \
    --cc=thuth@redhat.com \
    --cc=wenchao.wang@intel.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 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).