All of lore.kernel.org
 help / color / mirror / Atom feed
From: Claudio Fontana <cfontana@suse.de>
To: "Paolo Bonzini" <pbonzini@redhat.com>,
	"Thomas Huth" <thuth@redhat.com>,
	"Richard Henderson" <richard.henderson@linaro.org>,
	"Stefano Stabellini" <sstabellini@kernel.org>,
	"Wenchao Wang" <wenchao.wang@intel.com>,
	"Roman Bolshakov" <r.bolshakov@yadro.com>,
	"Sunil Muthuswamy" <sunilmut@microsoft.com>,
	"Philippe Mathieu-Daudé" <philmd@redhat.com>
Cc: Laurent Vivier <lvivier@redhat.com>,
	Eduardo Habkost <ehabkost@redhat.com>,
	Paul Durrant <paul@xen.org>, Jason Wang <jasowang@redhat.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	qemu-devel@nongnu.org, Peter Xu <peterx@redhat.com>,
	Dario Faggioli <dfaggioli@suse.com>,
	Cameron Esfahani <dirty@apple.com>,
	haxm-team@intel.com, Colin Xu <colin.xu@intel.com>,
	Anthony Perard <anthony.perard@citrix.com>,
	Bruce Rogers <brogers@suse.com>, Olaf Hering <ohering@suse.de>,
	"Emilio G . Cota" <cota@braap.org>
Subject: Re: [RFC v6 10/11] accel: introduce AccelCPUClass extending CPUClass
Date: Fri, 18 Dec 2020 18:51:03 +0100	[thread overview]
Message-ID: <ff157643-5245-85ba-123e-32800f212f4b@suse.de> (raw)
In-Reply-To: <6cbd508c-b24b-3219-3302-196dfefaa8f7@redhat.com>

On 11/27/20 7:21 AM, Paolo Bonzini wrote:
> On 26/11/20 23:32, Claudio Fontana wrote:
>> +    if (acc) {
>> +        object_class_foreach(accel_init_cpu_int_aux, cpu_type, false, acc);
>> +    }
> 
> Any reason to do it for cpu_type only, rather than for all subclasses of 
> CPU_RESOLVING_TYPE?  This would remove the cpu_type argument to 
> accel_init_cpu_interfaces and accel_init_interfaces.
> 
> Otherwise I haven't done a careful review yet but it looks very nice, 
> thanks!
> 
> Paolo
> 

Hi Paolo,

going back to this topic:

while doing some experiments in applying the ACCEL_CPU_TYPE classes for all targets (TCG for now, not KVM or other hw accels),
and merging all tcg cpu ops,

I did encounter some issue.

For the simplest of targets like hppa for example, it works just fine, we can do:

static void hppa_tcg_cpu_class_init(CPUClass *cc)
{
    cc->tcg_ops.initialize = hppa_translate_init;
    cc->tcg_ops.do_interrupt = hppa_cpu_do_interrupt;
    cc->tcg_ops.cpu_exec_interrupt = hppa_cpu_exec_interrupt;
    cc->tcg_ops.synchronize_from_tb = hppa_cpu_synchronize_from_tb;
    cc->tcg_ops.tlb_fill = hppa_cpu_tlb_fill;
#ifndef CONFIG_USER_ONLY
    cc->tcg_ops.do_unaligned_access = hppa_cpu_do_unaligned_access;
#endif
}

*(later on I will try to change the cc->tcg_ops thing to something that ends up in cc->accel_cpu->tcg_ops->initialize, as I try to merge tcg_ops with accel_cpu, but this is spoiler of the future)*

static void hppa_tcg_cpu_accel_class_init(ObjectClass *oc, void *data)
{
    AccelCPUClass *acc = ACCEL_CPU_CLASS(oc);

    acc->cpu_class_init = hppa_tcg_cpu_class_init;
}

static const TypeInfo hppa_tcg_cpu_accel_type = {
    .name = ACCEL_CPU_NAME("tcg"),

    .parent = TYPE_ACCEL_CPU,
    .class_init = hppa_tcg_cpu_accel_class_init,
};

static void hppa_cpu_register_types(void)
{
    type_register_static(&hppa_cpu_type_info);
    type_register_static(&hppa_tcg_cpu_accel_type);
}

type_init(hppa_cpu_register_types)

So this is good.

But with things like cris/ for example, 
the tcg functions to use are actually versioned per each subclass of TYPE_CRIS_CPU.

Different tcg_ops need to be used for different subclasses of the CPU_RESOLVING_TYPE.

So in order to avoid code in the class initialization like this:

if (version1) { then set the tcg ops for version 1; }
if (version2) { then set the tcg ops for version 2; ...} etc,

we could define the right tcg op variants corresponding to the cpu variants, so that everything can be matched automatically.

But I think we'd need to pass explicitly the cpu type in accel_init_cpu_interfaces for this to work..
we could still in the future call accel_init_cpu_interfaces multiple times, once for each cpu model we want to use.

Or, we could do something else: we could delay the accel cpu interface initialization and call it in cpu_create(const char *typename),
where typename needs to be known for sure.

This last option seems kinda attractive, but any ideas?

Thanks, ciao,

Claudio








  parent reply	other threads:[~2020-12-18 17:52 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 [this message]
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
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=ff157643-5245-85ba-123e-32800f212f4b@suse.de \
    --to=cfontana@suse.de \
    --cc=anthony.perard@citrix.com \
    --cc=brogers@suse.com \
    --cc=colin.xu@intel.com \
    --cc=cota@braap.org \
    --cc=dfaggioli@suse.com \
    --cc=dirty@apple.com \
    --cc=ehabkost@redhat.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 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.