Re: [RFC v6 10/11] accel: introduce AccelCPUClass extending CPUClass

[Paolo Bonzini]

On 18/12/20 18:51, Claudio Fontana wrote:
> But with things like cris/ for example,
> the tcg functions to use are actually versioned per each subclass of 
> TYPE_CRIS_CPU.
>
> Different tcg_ops need to be used for different subclasses of the 
> CPU_RESOLVING_TYPE.

CRIS is not that bad since it's TCG only.  You can just make it a field 
in CRISCPUClass and copy it over to tcg_ops.

I think ARM had something similar though, with different do_interrupt 
implementations for M and A processors.  Somebody from Linaro was 
cleaning it up as part of some BQL work, but it was never merged.  But 
even in that case, do_interrupt is somewhat special for ARM so making it 
an xxxCPUClass field makes sense.

Paolo

> So in order to avoid code in the class initialization like this:
>
> if (version1) { then set the tcg ops for version 1; }
> if (version2) { then set the tcg ops for version 2; ...} etc,
>
> we could define the right tcg op variants corresponding to the cpu variants, so 
> that everything can be matched automatically.
>
> But I think we'd need to pass explicitly the cpu type in 
> accel_init_cpu_interfaces for this to work..
> we could still in the future call accel_init_cpu_interfaces multiple times, 
> once for each cpu model we want to use.
>
> Or, we could do something else: we could delay the accel cpu interface 
> initialization and call it in cpu_create(const char *typename),
> where typename needs to be known for sure.
>
> This last option seems kinda attractive, but any ideas?