On Mon, Nov 23, 2020 at 04:02:24PM +0100, Claudio Fontana wrote: > On 11/23/20 2:18 PM, Paolo Bonzini wrote: > > On 23/11/20 10:55, Claudio Fontana wrote: > >> One idea that came to mind is, why not extend accel.h to user mode? > >> > >> It already contains > >> > >> #ifndef CONFIG_USER_ONLY > >> > >> parts, so maybe it was meant to be used by both, and just happened to > >> end up confined to include/softmmu ? > >> > >> Basically I was thinking, we could have an AccelState and an > >> AccelClass for user mode as well (without bringing in the whole > >> machine thing), and from there we could use current_accel() to build > >> up the right name for the chosen accelerator? > > > > Yes, extending the accelerator class to usermode emulation is certainly > > a good idea. > > > > Paolo > > > > Thanks, I'll work on this option. > > Btw considering that CpusAccel for tcg is actually three different interfaces > (for mttcg, for icount, and plain RR), > it will be tough to, in the stated objective, "remove all conditionals", even > after removing the tcg_enabled().
The main issue were the conditionals inside module init function. They are completely OK inside accel-specific methods. > > I wonder how you see this issue (patches for 3 TCG split are in Richard's > queue atm). > > static void tcg_accel_cpu_init(void) > { > if (tcg_enabled()) { > TCGState *s = TCG_STATE(current_accel()); > > if (s->mttcg_enabled) { > cpus_register_accel(&tcg_cpus_mttcg); > } else if (icount_enabled()) { > cpus_register_accel(&tcg_cpus_icount); > } else { > cpus_register_accel(&tcg_cpus_rr); > } > } > } Probably what we are missing here is a non-softmmu-specific AccelClass.init() method? -- Eduardo