Re: [Qemu-devel] [RFC 00/20] generic_cpu_init() and generic_cpu_create() functions

[Eduardo Habkost]

On Tue, Dec 18, 2012 at 11:57:58PM +0100, Andreas Färber wrote:
> Am 18.12.2012 21:03, schrieb Eduardo Habkost:
> > This is just a proof of concept, of how I think we could gradually move to
> > make the architectures share CPU creation/initialization code.
> > 
> > I have implemented a quick cpu_realize() function, just for testing, while 
> > we
> > don't have qdev realizefn support implemented.
> > 
> > I have converted the following targets to use generic_cpu_init(): openrisc, 
> > arm,
> > m68k, unicore32.
> > 
> > To support other architectures with additional CPU lookup requirements
> > (automatically adding "<arch>-cpu" suffix, or CPU model aliases), we can 
> > simply
> > add fields to CPUClass for the target-specific behavior, that can be used by
> > generic_cpu_create().
> 
> Without having looked at the series yet, what I have been experiencing
> the last three rounds of CPU subclass conversions is that a per-target
> name -> ObjectClass mapping works pretty well to abstract target'isms.
> Therefore I was gonna pursue a CPUClass::find_by_name() hook or so as
> generalization.
> 
> That would result in a name -> class, object_new(name(class)),
> env->cpu_model_str = name, realize scheme. That would leave us with the
> issues of QOM/device realization and of cpu_copy(). realize would in my
> mind allow us to register a realizefn in CPU class_init, automatically
> invoked by object_new, the targetted recursive realization allowing to
> drop any realize call from cpu_init() and with a couple explicit
> realization calls in *-user allowing us to repurpose cpu_init() for
> creation. But maybe I'm overlooking something or we're looking at
> different time frames. :-)

I don't have specific plans after the de-duplication. All I was pursuing
was to make all architectures use the same code to create/realize CPUs,
so we can easily change the existing behavior/interfaces in the future
without touching 15 or 30 different files. For example, it is much
easier to make cpu_init() not call realize() if we have only one
cpu_init() function, not 15.

Right now, I see cpu_init() as a temporary interface to be eventually
replaced by [generic_]cpu_create(), or maybe something that will stay
but only for *-user. I expect all the rest of the qemu-system-* code to
eventually just use [generic_]cpu_create() to create not-realized-yet
CPU objects, once we make device realization happen somewhere else. I
guess that's equivalent to what you suggest above, I'm just calling the
resulting function "cpu_create()" instead of "cpu_init()".

But while we don't have all we need, we can at least have a generic
create()+realize() helper that everybody can use, and a simple
create-only helper, for code that for some reason need a
not-realized-yet CPU (I expect the PC code to need it, to fix the
APIC-ID topology bug).

> 
> Andreas
> 
> > We can also extend generic_cpu_init() later to support
> > parsing of "+feature,-feature" feature strings, to set properties on the CPU
> > objects, like on x86.
> > 
> > Note that this series is completely untested except for checking if the code
> > compiles. I am just using the series as a way to demonstrate what I have in
> > mind.
> 
> -- 
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

-- 
Eduardo