[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC v1 09/10] i386: split cpu.c and defer x86 models registration
From: |
Claudio Fontana |
Subject: |
Re: [RFC v1 09/10] i386: split cpu.c and defer x86 models registration |
Date: |
Tue, 10 Nov 2020 18:38:49 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 |
On 11/10/20 4:23 PM, Eduardo Habkost wrote:
> On Tue, Nov 10, 2020 at 11:41:46AM +0100, Paolo Bonzini wrote:
>> On 10/11/20 11:04, Daniel P. Berrangé wrote:
>>>
>>> ie, we should have one class hierarchy for CPU model definitions, and
>>> one class hierarchy for accelerator CPU implementations.
>>>
>>> So at runtime we then get two object instances - a CPU implementation
>>> and a CPU definition. The CPU implementation object should have a
>>> property which is a link to the desired CPU definition.
>>
>> It doesn't even have to be two object instances. The implementation can be
>> nothing more than a set of function pointers.
>
> A set of function pointers is exactly what a QOM interface is.
> Could the methods be provided by a TYPE_X86_ACCEL interface type,
> implemented by the accel object?
>
Looking at the 2 axes mentioned by Daniel before, on the "accelerator cpu
axis", we have TYPE_TCG_CPU, TYPE_KVM_CPU, TYPE_HVF_CPU,
which look like simple subclasses of TYPE_X86_CPU to me, with basically all the
divergent functionality being added by composition.
TYPE_HVF_CPU seems to do everything that TYPE_X86_CPU does on construction (and
device realization), and then some.
On the "cpu models" axis we have all the current subclasses of TYPE_X86_CPU,
which include "links" to X86CPUModel objects in the form
of class_data:
static void x86_register_cpu_model_type(const char *name, X86CPUModel *model,
const char *parent_type)
{
g_autofree char *typename = x86_cpu_type_name(name);
TypeInfo ti = {
.name = typename,
.parent = parent_type,
.class_init = x86_cpu_cpudef_class_init,
.class_data = model,
};
type_register(&ti);
}
so this would be close to the "link" property that Daniel you were speaking
about before?
Should X86CPUmodel be the prime citizen of the "cpu models" axis, without
constructing a separate TYPE_X86_CPU subclass for each cpu model?
A separate topic we did not address in comments before, where I'd like
opinions, is how should we treat cpu types "base" and "max" and "host"?
Just to avoid forgetting about them, currently TYPE_X86_CPU is the parent type
of "base" and of "max",
and "max" is the parent type of "host".
"host" is only allowed when using accelerator kvm or hvf. Attempts to create
such a cpu without a kvm or hvf accelerator enabled will error out.
"max" behaves differently when using hvf or kvm.
Thanks,
Claudio
- Re: [RFC v1 09/10] i386: split cpu.c and defer x86 models registration, (continued)
- Re: [RFC v1 09/10] i386: split cpu.c and defer x86 models registration, Daniel P . Berrangé, 2020/11/09
- Re: [RFC v1 09/10] i386: split cpu.c and defer x86 models registration, Claudio Fontana, 2020/11/10
- Re: [RFC v1 09/10] i386: split cpu.c and defer x86 models registration, Daniel P . Berrangé, 2020/11/10
- Re: [RFC v1 09/10] i386: split cpu.c and defer x86 models registration, Claudio Fontana, 2020/11/10
- Re: [RFC v1 09/10] i386: split cpu.c and defer x86 models registration, Paolo Bonzini, 2020/11/10
- Re: [RFC v1 09/10] i386: split cpu.c and defer x86 models registration, Eduardo Habkost, 2020/11/10
- Re: [RFC v1 09/10] i386: split cpu.c and defer x86 models registration, Paolo Bonzini, 2020/11/10
- Re: [RFC v1 09/10] i386: split cpu.c and defer x86 models registration, Eduardo Habkost, 2020/11/10
- Re: [RFC v1 09/10] i386: split cpu.c and defer x86 models registration, Paolo Bonzini, 2020/11/10
- Re: [RFC v1 09/10] i386: split cpu.c and defer x86 models registration, Eduardo Habkost, 2020/11/10
- Re: [RFC v1 09/10] i386: split cpu.c and defer x86 models registration,
Claudio Fontana <=
- Re: [RFC v1 09/10] i386: split cpu.c and defer x86 models registration, Eduardo Habkost, 2020/11/10
- Re: [RFC v1 09/10] i386: split cpu.c and defer x86 models registration, Claudio Fontana, 2020/11/11
- Re: [RFC v1 09/10] i386: split cpu.c and defer x86 models registration, Claudio Fontana, 2020/11/16
Re: [RFC v1 09/10] i386: split cpu.c and defer x86 models registration, Eduardo Habkost, 2020/11/09
[RFC v1 10/10] module: add priority to module_init, Claudio Fontana, 2020/11/09
Re: [RFC v1 00/10] i386 cleanup, no-reply, 2020/11/09