[Top][All Lists]
[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
- [Qemu-devel] [RFC 04/20] cpu: replace trivial old_cpu_init functions, (continued)
- [Qemu-devel] [RFC 04/20] cpu: replace trivial old_cpu_init functions, Eduardo Habkost, 2012/12/18
- [Qemu-devel] [RFC 13/20] target-openrisc: replace cpu_openrisc_init() with generic_cpu_init(), Eduardo Habkost, 2012/12/18
- [Qemu-devel] [RFC 16/20] target-m68k: move final steps of cpu_m68k_init() to realize function, Eduardo Habkost, 2012/12/18
- [Qemu-devel] [RFC 18/20] target-unicore32: move final steps of uc32_cpu_init() to realize function, Eduardo Habkost, 2012/12/18
- [Qemu-devel] [RFC 19/20] target-unicore32: replace uc32_cpu_init() with generic_cpu_init(), Eduardo Habkost, 2012/12/18
- [Qemu-devel] [RFC 14/20] target-arm: move final steps of cpu_arm_init() to realize function, Eduardo Habkost, 2012/12/18
- [Qemu-devel] [RFC 20/20] cpu: convert cpu_copy() to QOM, Eduardo Habkost, 2012/12/18
- [Qemu-devel] [RFC 08/20] cpu: move cpu_model_str to CPUState, Eduardo Habkost, 2012/12/18
- [Qemu-devel] [RFC 10/20] cpu: introduce generic_cpu_init() & generic_cpu_create() functions, Eduardo Habkost, 2012/12/18
- [Qemu-devel] [RFC 03/20] cpu: make cpu_init return CPUState QOM object, Eduardo Habkost, 2012/12/18
- Re: [Qemu-devel] [RFC 00/20] generic_cpu_init() and generic_cpu_create() functions,
Andreas Färber <=