qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Andreas Färber
Subject: Re: [Qemu-devel] [RFC 00/20] generic_cpu_init() and generic_cpu_create() functions
Date: Tue, 18 Dec 2012 23:57:58 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0

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. :-)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]