On 05/10/2012 02:10 AM, Andreas Färber wrote:
Hello,
Based on my CPUState patches for 1.1 (qom-cpu-1.1) this series kills off the
cpu_state_reset() function, which had been renamed as an interim solution
to free the identifier "cpu_reset" for QOM.
The interested observer may note that the earlier sh4 SH7750 patches (that
have been deferred due to time constraints for 1.1) were a test run and
serve as template for propagating xxxCPU throughout the code base:
(i) In target-specific code, accessing CPUxxxState* is a cheap pointer
dereference from xxxCPU (&cpu->env), so xxxCPU should be preferred for any
static helper functions and QOM/qdev state structs because fields in CPUState
and in xxxCPU will increase over time. In state structs this also paves
the way for QOM child<> or link<> properties.
(ii) In TCG helpers, the target's xxxCPU can be obtained via xxx_env_get_cpu().
Be aware that this incurs one QOM cast.
(iii) In generic code, the base CPU can be obtained via ENV_GET_CPU() macro.
Note that this incurs two QOM casts, so local variables should be preferred
over repeated macro usage within a function.
(iv) In generic functions, only after all usages of env have been eliminated
can the argument be changed from CPUArchState to CPUState.
(v) Opaque xxxCPU* values are assigned directly to xxxCPU*, to save QOM casts;
to CPUState* via CPU() cast, in case the casting mechanism ever gets changed.
Historically, this series has been cherry-picked from a larger CPUState
refactoring (guess why) and reordered to group subsystems and to enforce
get, pass, use order.
I had checked v1 to compile on ...
* openSUSE 12.1 x86_64 w/KVM,
* openSUSE Factory ppc w/KVM (with the AREG0 #error suppressed),
* mingw32/64 cross-builds,
* OpenBSD 5.1 amd64.
Thus I'm confident that I got order, return types and local variables right;
changes to opaque values however (keyword "pass") should be reviewed carefully.
v2 fixes the changed cpu_init macros to return NULL if CPU init failed.
Again, target maintainers are requested to start queuing their patches on their
-next branches, where available, to avoid collisions.
I've been careful to verbosely document which change is for what; the targets
are not interdependent except for the final patch, neither is linux-user.
PReP patches depend on target-ppc, so should go through the ppc tree please.
Only target-mips actually depends on a 1.1 patch (the comment drop).
Some logical next steps that were not strictly necessary for cpu_reset() have
been deferred to part 4, including s390x and some more pxa2xx refactorings.
Available for testing and cherry-picking (not pulling!) from:
git://github.com/afaerber/qemu-cpu.git qom-cpu-reset.v2
https://github.com/afaerber/qemu-cpu/commits/qom-cpu-reset.v2
Regards,
Andreas
Cc: Anthony Liguori<anth...@codemonkey.ws>
Cc: Paolo Bonzini<pbonz...@redhat.com>
Cc: Igor Mammedov<imamm...@redhat.com>
Cc: Peter Maydell<peter.mayd...@linaro.org>
Cc: Alexander Graf<ag...@suse.de>
Cc: qemu-ppc<qemu-...@nongnu.org>
Cc: Blue Swirl<blauwir...@gmail.com>
Cc: Edgar E. Iglesias<edgar.igles...@gmail.com>
Cc: Max Filippov<jcmvb...@gmail.com>
Cc: Michael Walle<mich...@walle.cc>
Cc: Aurelien Jarno<aurel...@aurel32.net>
Cc: Richard Henderson<r...@twiddle.net>
Cc: Riku Voipio<riku.voi...@iki.fi>
Very simple, nice and clean ;)
PowerPC parts are:
Acked-by: Alexander Graf <ag...@suse.de>
Alex
