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
