Re: [PATCH v3 21/30] target/ppc: Introduce PowerPCCPUClass::has_work()

[Richard Henderson <richard.henderson@xxxxxxxxxx>]

On 9/11/21 3:31 PM, Philippe Mathieu-Daudé wrote:
> On 9/3/21 11:11 PM, Philippe Mathieu-Daudé wrote:
> > On 9/3/21 10:42 PM, Richard Henderson wrote:
> > > On 9/3/21 2:50 AM, David Gibson wrote:
> > > > On Thu, Sep 02, 2021 at 06:15:34PM +0200, Philippe Mathieu-Daudé wrote:
> > > > > Each POWER cpu has its own has_work() implementation. Instead of
> > > > > overloading CPUClass on each PowerPCCPUClass init, register the
> > > > > generic ppc_cpu_has_work() handler, and have it call the POWER
> > > > > specific has_work().
> > > > I don't quite see the rationale for introducing a second layer of
> > > > indirection here.  What's wrong with switching the base has_work for
> > > > each cpu variant?
> > > We're moving the hook from CPUState to TCGCPUOps.
> > > Phil was trying to avoid creating N versions of
> > >
> > > static const struct TCGCPUOps ppc_tcg_ops = {
> > >      ...
> > > };
> > Ah yes this is the reason! Too many context switching so
> > I forgot about it.
> >
> > > A plausible alternative is to remove the const from this struct and
> > > modify it, just as we do for CPUState, on the assumption that we cannot
> > > mix and match ppc cpu types in any one machine.
> > I thought about this case and remembered how it works on the ARM arch,
> > i.e. ZynqMP machine uses both Cortex-R5F and Cortex-A53. Even if no
> > similar PPC machine exists, IMHO we should try to generally allow to
> > possibility to experiment machine with different CPUs. Restricting it
> > on PPC goes the other way around. Thoughts?
> I'm running out of ideas to do avoid the indirection and multiple
> copies of TCGCPUOps. I'm not giving up, I suppose I'm simply not
> seeing it... David, any suggestions?
I think multiple copies of TCGCPUOps is the solution.  Macro-ized, perhaps, so that the 
amount of typing is minimal across the versions.

r~