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~
