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
