On Wed, 23 May 2012, Andreas Färber wrote:
> Hello,
>
> This series, based on qom-next and the two pending ARM cleanup patches, starts
> moving fields from CPUArchState (CPU_COMMON) to QOM CPUState. It stops short
> of moving all easily possible fields (i.e., those not depending on target_ulong
> or target_phys_addr_t) since the series got too long already and is expected to
> spark some controversies due to collisions with several other series.
>
> The series is structured as preparatory refactorings interwoven with the actual
> touch-all movement of one field ("cpu: Move ... to CPUState"), optionally
> followed by type signature cleanups, culminating in the movement of two fields
> that are tied together by VMState.
> Thus, unlike part 3, this series cannot randomly be cherry-picked to
> <arch>-next trees, only select parts thereof (e.g., use of cpu_s390x_init()).
>
> Please review and test.
>
> The use of cpu_index vs. cpuid_apic_id for x86 cpu[n] still needs some thought.
>
> The question was brought up whether adding the CPUs a child<X86CPU> properties
> should be generalized outside the machine scope - I don't think so, since CPU
> hotplug seems highly architecture-specific and not applicable everywhere (SoCs).
>
> Blue will likely have a superb idea how to avoid the cpu_tlb_flush() indirection
> that I needed for VMState, but apart from having been a lot of dumb typing, it
> works fine as interim solution. "Blah." wasn't terribly helpful as a comment.
>
> I have checked this to compile on ...
> * openSUSE 12.1 x86_64 w/KVM,
> * openSUSE Factory ppc w/KVM,
> * SLES 11 SP2 s390x w/KVM,
> * mingw32/64 cross-builds,
> * OpenBSD 5.1 amd64 (not for final version though, master doesn't build).
> Untested: Xen.
I tested it on Xen: it works correctly.
Tested-by: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
