[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC v3 8/9] module: introduce MODULE_INIT_ACCEL_CPU
From: |
Eduardo Habkost |
Subject: |
Re: [RFC v3 8/9] module: introduce MODULE_INIT_ACCEL_CPU |
Date: |
Wed, 18 Nov 2020 11:11:19 -0500 |
On Wed, Nov 18, 2020 at 04:43:19PM +0100, Paolo Bonzini wrote:
> Il mer 18 nov 2020, 16:26 Eduardo Habkost <ehabkost@redhat.com> ha scritto:
>
> >
> > > The alternative is to store the (type, function) tuple directly, with the
> > > type as a string. Then you can just use type_init.
> >
> > Right. Let's build on top of that:
> >
> > Another alternative would be to store a (type, X86CPUAccel) tuple
> > directly, with the type as string. This would save the extra
> > indirection of the x86_cpu_accel_init() call.
> >
> > It turns out we already have a mechanism to register and store
> > (type, StructContainingFunctionPointers) tuples at initialization
> > time: QOM.
> >
> > X86CPUAccel can become X86CPUAccelClass, and be registered as a
> > QOM type. It could be a subtype of TYPE_ACCEL or not, it
> > shouldn't matter.
> >
>
> It would be a weird type that isn't instantiated, and/or that does nothing
> but monkey patching other classes. I don't think it's a good fit.
The whole point of this would be to avoid monkey patching other
classes.
Why wouldn't we instantiate it? There's a huge number of static
variables in target/i386/kvm.c that could be moved to that
object. Sounds like a perfect fit for me.
I won't try to stop you if you really want to invent a brand new
(name => CollectionOfFunctionPointers) registry, but it seems
unnecessary.
>
> Yet another possibility is to use GHashTable. It is limited to one value
> per key, but it's enough if everything is kept local to {hw,target}/i386.
> If needed a new function pointer can be added to MachineClass, implemented
> in X86MachineState (where the GHashTable would also be) and called in
> accel.c.
>
> Paolo
>
> Paolo
>
>
> > I remember this was suggested in a previous thread, but I don't
> > remember if there were any objections.
> >
> > >
> > > > Making sure module_call_init() is called at the correct moment is
> > > > not easier or safer than just making sure accel_init_machine()
> > > > (or another init function you create) is called at the correct
> > > > moment.
> > >
> > > Since there is a way to do it without a new level, that would of course
> > be
> > > fine for me too. Let me explain however why I think Claudio's design had
> > > module_call_init() misplaced and what the fundamental difference is. The
> > > basic phases in qemu_init() are:
> > >
> > > - initialize stuff
> > > - parse command line
> > > - create machine
> > > - create accelerator
> > > - initialize machine
> > > - create devices
> > > - start
> > >
> > > with a mess of other object creation sprinkled between the various phases
> > > (but we don't care about those).
> > >
> > > What I object to, is calling module_call_init() after the "initialize
> > stuff"
> > > phase. Claudio was using it to call the function directly, so it had to
> > be
> > > exactly at "create accelerator". This is different from all other
> > > module_call_init() calls, which are done very early.
> >
> > I agree.
> >
> > >
> > > With the implementation I sketched, accel_register_call must still be
> > done
> > > after type_init, so there's still an ordering constraint, but all it's
> > doing
> > > is registering a callback in the "initialize stuff" phase.
> >
> > Makes sense, if we really want to introduce a new accel_register_call()
> > abstraction. I don't think we need it, though.
> >
> > --
> > Eduardo
> >
> >
--
Eduardo
- [RFC v3 7/9] i386: move TCG cpu class initialization out of helper.c, (continued)
- [RFC v3 7/9] i386: move TCG cpu class initialization out of helper.c, Claudio Fontana, 2020/11/18
- [RFC v3 8/9] module: introduce MODULE_INIT_ACCEL_CPU, Claudio Fontana, 2020/11/18
- Re: [RFC v3 8/9] module: introduce MODULE_INIT_ACCEL_CPU, Claudio Fontana, 2020/11/18
- Re: [RFC v3 8/9] module: introduce MODULE_INIT_ACCEL_CPU, Eduardo Habkost, 2020/11/18
- Re: [RFC v3 8/9] module: introduce MODULE_INIT_ACCEL_CPU, Claudio Fontana, 2020/11/18
- Re: [RFC v3 8/9] module: introduce MODULE_INIT_ACCEL_CPU, Paolo Bonzini, 2020/11/18
- Re: [RFC v3 8/9] module: introduce MODULE_INIT_ACCEL_CPU, Eduardo Habkost, 2020/11/18
- Re: [RFC v3 8/9] module: introduce MODULE_INIT_ACCEL_CPU, Paolo Bonzini, 2020/11/18
- Re: [RFC v3 8/9] module: introduce MODULE_INIT_ACCEL_CPU, Eduardo Habkost, 2020/11/18
- Re: [RFC v3 8/9] module: introduce MODULE_INIT_ACCEL_CPU, Paolo Bonzini, 2020/11/18
- Re: [RFC v3 8/9] module: introduce MODULE_INIT_ACCEL_CPU,
Eduardo Habkost <=
- Re: [RFC v3 8/9] module: introduce MODULE_INIT_ACCEL_CPU, Paolo Bonzini, 2020/11/18
- Re: [RFC v3 8/9] module: introduce MODULE_INIT_ACCEL_CPU, Eduardo Habkost, 2020/11/18
- Re: [RFC v3 8/9] module: introduce MODULE_INIT_ACCEL_CPU, Paolo Bonzini, 2020/11/18
- Re: [RFC v3 8/9] module: introduce MODULE_INIT_ACCEL_CPU, Eduardo Habkost, 2020/11/18
- Re: [RFC v3 8/9] module: introduce MODULE_INIT_ACCEL_CPU, Claudio Fontana, 2020/11/20
- Re: [RFC v3 8/9] module: introduce MODULE_INIT_ACCEL_CPU, Eduardo Habkost, 2020/11/20
- Re: [RFC v3 8/9] module: introduce MODULE_INIT_ACCEL_CPU, Claudio Fontana, 2020/11/20
- Re: [RFC v3 8/9] module: introduce MODULE_INIT_ACCEL_CPU, Eduardo Habkost, 2020/11/20
- Re: [RFC v3 8/9] module: introduce MODULE_INIT_ACCEL_CPU, Claudio Fontana, 2020/11/23
- Re: [RFC v3 8/9] module: introduce MODULE_INIT_ACCEL_CPU, Claudio Fontana, 2020/11/23