[Top][All Lists]

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

Re: [Qemu-ppc] [Qemu-devel] [PATCH next v2 00/74] QOM CPUState, part 3:

From: Alexander Graf
Subject: Re: [Qemu-ppc] [Qemu-devel] [PATCH next v2 00/74] QOM CPUState, part 3: CPU reset
Date: Mon, 21 May 2012 15:52:09 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.3) Gecko/20120306 Thunderbird/10.0.3

On 05/10/2012 02:10 AM, Andreas Färber wrote:

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


Cc: Anthony Liguori<address@hidden>
Cc: Paolo Bonzini<address@hidden>
Cc: Igor Mammedov<address@hidden>

Cc: Peter Maydell<address@hidden>
Cc: Alexander Graf<address@hidden>
Cc: qemu-ppc<address@hidden>
Cc: Blue Swirl<address@hidden>
Cc: Edgar E. Iglesias<address@hidden>
Cc: Max Filippov<address@hidden>
Cc: Michael Walle<address@hidden>
Cc: Aurelien Jarno<address@hidden>
Cc: Richard Henderson<address@hidden>
Cc: Riku Voipio<address@hidden>

Very simple, nice and clean ;)

PowerPC parts are:

  Acked-by: Alexander Graf <address@hidden>


reply via email to

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