Re: [RFC v1 09/10] i386: split cpu.c and defer x86 models registration

[Paolo Bonzini]

On 10/11/20 16:23, 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?

I think we should not try yo implement interfaces conditionally (i.e. 
have TYPE_X86_ACCEL implemented only on qemu-system-{i386,x86_64} and 
not qemu-system-arm), even if technically the accel/ objects are 
per-target (specific_ss) rather than common.

Paolo