On 12/03/21 11:25, Claudio Fontana wrote:
We can register them from there if needed I think,, but where ever we
do it, we still have to point to the one set of ops or the other,
depending on the cpu model that is finally chosen.
So when we attach the tcg cpu accelerator object to the cpu, we
currently should check which cpu it is, and behave accordingly.
Maybe this is better? Ie, not set the tcg ops in different places (in
the v7m cpu class init and in the tcg cpu accel init),
but rather set them just in a single place, when we attach the accel
cpu object, checking which cpu profile it is somehow (TBD), and then
behave accordingly?
Take a look at
https://wiki.qemu.org/User:Paolo_Bonzini/Machine_init_sequence#Basic_phases.
The phases are:
- creating backends (PHASE_NO_MACHINE)
- creating machine (after which PHASE_MACHINE_CREATED is entered)
- creating accelerator (after which PHASE_ACCEL_CREATED is entered)
- initializing embedded devices (in machine_run_board_init, after which
PHASE_MACHINE_INITIALIZED is entered), including CPUs
- creating devices (in qmp_x_exit_preconfig, after which
PHASE_MACHINE_READY is entered)
And the last is where the guest actually starts.
I think that you should have a callback in the accelerator that runs
after -cpu is processed and before PHASE_MACHINE_INITIALIZED is entered.
So the right place to add it would be machine_run_board_init.
Maybe some kind of double dispatch, where the accelerator has an
acc->init_cpu(acc, cc) method and the CPU has a cc->init_tcg_ops(cc)
method. Then TCG's init_cpu calls into the latter.
Paolo
