On 3/12/21 11:07 AM, Paolo Bonzini wrote: > On 12/03/21 10:58, Claudio Fontana wrote: >> Not really, but I have been using the accel class init function on x86 to >> register the TCG OPS, >> >> and this instead requires a bit more thought for ARM, >> >> because we currently register for the ARM M Profile the TCG Ops at >> arm_v7m_class_init time, >> which is called already at select_machine() time, >> >> so when we select the accelerator, and we call the tcg_cpu_class_init, we >> run the risk of overriding the existing tcg_ops >> >> Ideas? Looks horrible? > > Not horrible, but wrong. The class_init function must be idempotent: > classes have no side effect until they're instantiated (and even then, > usually we delay that to later, e.g. realized for devices or complete > for user-creatable objects). > > Why can't you register ops in the machine init function for the accelerator? > > Paolo >
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? THanks, Claudio
