On 18/11/20 18:30, Eduardo Habkost wrote:
Adding a layer of indirect calls is not very different from monkey patching
though.
I'm a little bothered by monkey patching, but I'm more
bothered by having to:
(1) register (module_init()) a function (kvm_cpu_accel_register()) that
(2) register (accel_register_call()) a function (kvm_cpu_accel_init()) that
(3) register (x86_cpu_accel_init()) a data structure (X86CPUAccel
kvm_cpu_accel) that
(4) will be saved in multiple QOM classes, so that
(5) we will call the right X86CPUClass.accel method at the right moment
(common_class_init(), instance_init(), realizefn()),
where:
step 4 must be done before any CPU object is created
(otherwise X86CPUAccel.instance_init & X86CPUAccel.realizefn
will be silently ignored), and
step 3 must be done after all QOM types were registered.
You also have to consider that accel currently does not exist in usermode
emulators, so that's an issue too. I would rather get a simple change in
quickly, instead of designing the perfect class hierarchy.
It doesn't have to be perfect. I agree that simple is better.
To me, registering a QOM type and looking it up when necessary is
simpler than the above. Even if it's a weird class having no
object instances. It probably could be an interface type.
Registering a QOM type still has quite some boilerplate. Also
registering a QOM type has a public side effect (shows up in
qom-list-types). In general I don't look at QOM unless I want its
property mechanism, but maybe that's just me.
Perhaps another idea would be to allow adding interfaces to classes
*separately from the registration of the types*. Then we can use it to add
SOFTMMU_ACCEL and I386_ACCEL interfaces to a bare bones accel class, and
add the accel object to usermode emulators.
I'm not sure I follow. What do you mean by bare bones accel
class, and when exactly would you add the new interfaces to the
classes?
A bare bones accel class would not have init_machine and setup_post
methods; those would be in a TYPE_SOFTMMU_ACCEL interface. It would
still have properties (such as tb-size for TCG) and would be able to
register compat properties.
Where would I add it, I don't know. It could be a simple public wrapper
around type_initialize_interface() if we add a new MODULE_INIT_* phase
after QOM.
Or without adding a new phase, it could be a class_type->array of
(interface_type, init_fn) hash table. type_initialize would look up the
class_type by name, add the interfaces would to the class with
type_initialize_interface, and then call the init_fn to fill in the vtable.
Paolo
