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
