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

[Eduardo Habkost <ehabkost@redhat.com>]

On Tue, Nov 10, 2020 at 05:05:27PM +0100, Paolo Bonzini wrote:
> 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.

If the accel objects are already per target, it seems appropriate
to have a QOM type hierarchy that reflects that.

`qemu-system-x86_64 -accel kvm` would create a kvm-x86_64-accel
object, but `qemu-system-arm -accel kvm` would create a
kvm-arm-accel.

*-x86_64-accel and *-i386-accel would all implement
INTERFACE_X86_ACCEL.

-- 
Eduardo