[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v3 21/30] target/ppc: Introduce PowerPCCPUClass::has_work()
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~
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |