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: Sat, 19 Dec 2020 00:00:46 +0100 [thread overview]
Message-ID: <2f50e4f3-dd13-bbd4-1963-daf695bbe428@suse.de> (raw)
In-Reply-To: <343846ce-12ba-23d6-4832-4aa16cb22f9d@suse.de>
On 12/18/20 11:30 PM, Claudio Fontana wrote:
> On 12/18/20 10:55 PM, Claudio Fontana wrote:
>> On 12/18/20 7:04 PM, Claudio Fontana wrote:
>>> On 12/18/20 7:01 PM, Paolo Bonzini wrote:
>>>> On 18/12/20 18:51, Claudio Fontana wrote:
>>>>> 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.
>>>>
>>>> CRIS is not that bad since it's TCG only. You can just make it a field
>>>> in CRISCPUClass and copy it over to tcg_ops.
>>>>
>>>> I think ARM had something similar though, with different do_interrupt
>>>> implementations for M and A processors. Somebody from Linaro was
>>>> cleaning it up as part of some BQL work, but it was never merged. But
>>>> even in that case, do_interrupt is somewhat special for ARM so making it
>>>> an xxxCPUClass field makes sense.
>>>>
>>>> Paolo
>>>
>>> Ok that's a good alternative,
>>>
>>>>
>>>>> 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.
>>>
>>>
>>> I take you don't like this idea to initialize the accel cpu interface in cpu_create()?
>>> It seems to make sense to me, but any drawbacks?
>>>
>>> Ciao thanks!
>>>
>>> Claudio
>>>
>>>
>>>>>
>>>>> This last option seems kinda attractive, but any ideas?
>>>
>>>
>>
>> Oh I see, sadly, only user mode code seem to be guaranteed to go through cpu_create(), so there is probably no single code point,
>> where we are guaranteed to see the creation of a cpu, everything is duplicated with explict calls to object_new in multiple places.
>>
>> Hmm...
>
> Well we can actually do it in the right place, that is in cpu_common_intfn,
> by calling accel_init_cpu_intefaces there, which kinda makes sense anyway... wdyt?
>
But then the mapping becomes difficult.. actually I think we/I need to study carefully all targets to figure out the best way to associate a cpu subclass/model with its accel cpu interface.
it's going to be next year now.
Happy holidays,
Claudio
next prev parent reply other threads:[~2020-12-18 23:03 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 [this message]
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=2f50e4f3-dd13-bbd4-1963-daf695bbe428@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 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).