Re: [Xen-devel] [PATCH qom-next 00/59] QOM CPUState, part 4: CPU_COMMON

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

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>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel