[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC v5 09/12] module: introduce MODULE_INIT_ACCEL_CPU
From: |
Claudio Fontana |
Subject: |
Re: [RFC v5 09/12] module: introduce MODULE_INIT_ACCEL_CPU |
Date: |
Thu, 26 Nov 2020 13:45:03 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 |
On 11/25/20 10:30 AM, Paolo Bonzini wrote:
> On 25/11/20 10:21, Claudio Fontana wrote:
>> Hi Paolo,
>>
>> in RFC v5 , module init for ACCEL_CPU is not conditional anymore, right?
>> But the fact that its behavior depends on current_accel() still disqualifies
>> it?
>> It is called right after the accelerator is chosen and initialized
>> in RFC v5, this still is "in the middle of the machine creation sequence"?
> Yes, machine creation basically starts after command line parsing, or
> perhaps even _with_ command line parsing. Basically once the user can
> control the flow it is already too late.
>
>> I am trying to find the actual things to fix, since when doing RFC
>> v5 I tried to specifically address two points:
>>
>> 1) no if () inside module init functions
>>
>> 2) no proliferation of module init functions
>>
>> which I accomplished via AccelClass extension to user mode, current_accel(),
>> and class lookup.
>
> Yes, the rest is great, I'm just not sure that MODULE_INIT_ACCEL_CPU is
> useful and if virtual functions on accel and CPU_RESOLVING_TYPE can
> achieve the same.
>
>> If MODULE_INIT_ACCEL_CPU remains an option, where would you like to see the
>> call so that it is not "in the middle"?
>
> No later than the runstate_init() call, roughly.
>
> Paolo
>
Hi Paolo, not super-related to the context above,
during the implementation I am trying to offer
accel/accel-softmmu.c
accel/accel-common.c
accel/accel-user.c
But I don't seem able to use CONFIG_USER_ONLY in accel-common.c .
in accel/meson.build I am saying
common_ss.add(files('accel-common.c'))
softmmu_ss.add(files('accel-softmmu.c'))
user_ss.add(files('accel-user.c'))
But this doesn't work, if I use common_ss. If I use specific_ss, it works.
So the term "common" is a bit overloaded, it means stuff for libcommon and
such, not common between softmmu and user, right?
Ciao,
Claudio
- Re: [RFC v5 08/12] accel: extend AccelState and AccelClass to user-mode, (continued)
- [RFC v5 09/12] module: introduce MODULE_INIT_ACCEL_CPU, Claudio Fontana, 2020/11/24
- Re: [RFC v5 09/12] module: introduce MODULE_INIT_ACCEL_CPU, Eduardo Habkost, 2020/11/24
- Re: [RFC v5 09/12] module: introduce MODULE_INIT_ACCEL_CPU, Claudio Fontana, 2020/11/24
- Re: [RFC v5 09/12] module: introduce MODULE_INIT_ACCEL_CPU, Eduardo Habkost, 2020/11/24
- Re: [RFC v5 09/12] module: introduce MODULE_INIT_ACCEL_CPU, Paolo Bonzini, 2020/11/24
- Re: [RFC v5 09/12] module: introduce MODULE_INIT_ACCEL_CPU, Claudio Fontana, 2020/11/25
- Re: [RFC v5 09/12] module: introduce MODULE_INIT_ACCEL_CPU, Paolo Bonzini, 2020/11/25
- Re: [RFC v5 09/12] module: introduce MODULE_INIT_ACCEL_CPU, Claudio Fontana, 2020/11/25
- Re: [RFC v5 09/12] module: introduce MODULE_INIT_ACCEL_CPU,
Claudio Fontana <=
Re: [RFC v5 09/12] module: introduce MODULE_INIT_ACCEL_CPU, Philippe Mathieu-Daudé, 2020/11/26
[RFC v5 04/12] i386: hvf: remove stale MAINTAINERS entry for old hvf stubs, Claudio Fontana, 2020/11/24
[RFC v5 07/12] i386: move TCG cpu class initialization out of helper.c, Claudio Fontana, 2020/11/24
[RFC v5 10/12] i386: split cpu accelerators from cpu.c, Claudio Fontana, 2020/11/24
[RFC v5 03/12] i386: move hax accel files into hax/, Claudio Fontana, 2020/11/24
[RFC v5 05/12] i386: move TCG accel files into tcg/, Claudio Fontana, 2020/11/24
[RFC v5 01/12] i386: move kvm accel files into kvm/, Claudio Fontana, 2020/11/24
[RFC v5 11/12] i386: centralize initialization of cpu accel interfaces, Claudio Fontana, 2020/11/24