|
From: | Paolo Bonzini |
Subject: | Re: [RFC v6 10/11] accel: introduce AccelCPUClass extending CPUClass |
Date: | Fri, 18 Dec 2020 19:01:15 +0100 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 |
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?
[Prev in Thread] | Current Thread | [Next in Thread] |