Re: [PATCH 0 of 7] kvm-userspace: support multiple processors in

Re: [PATCH 0 of 7] kvm-userspace: support multiple processors in

[Christian Ehrhardt]

Hollis Blanchard wrote:
> These patches allow the kvmctl bits (including testcases and libcflat) to be
> built for multiple processor types within the same architecture (e.g. 440 and
> e500). This is important because PowerPC supervisor mode can contain
> significant differences between processors (it's user mode that's more or less
> identical).
>
> For example, the data in a TLB entry and how to manipulate the TLB
> are a major difference between 440 and e500, which is critical here because
> libcflat must create its own mappings and so must know which method to use.
>
> Some of the complexity comes from user/Makefile *not* using the top-level
> config.mak, so we have to add some of the same logic to both configure scripts
> to generate both config.mak files.
>
> Too much makefile logic depends on ARCH containing only the architecture
> name, so it was simpler to create and export a separate PROCESSOR variable.
>
> -Hollis
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>   
Unfortunately there is too often no "really nice" way to do Makefile 
magic :-)
I know you started with the arch-platform-os-compiler after our discussion,
but I like the $PROCESSOR solution for our *powerpc* Makefiles too.
And a good catch with that AR usage in patch 7.

(full series)
Acked-by: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>

-- 

Grüsse / regards, 
Christian Ehrhardt
IBM Linux Technology Center, Open Virtualization

Re: [PATCH 0 of 7] kvm-userspace: support multiple processors in

[Avi Kivity]

Hollis Blanchard wrote:
> These patches allow the kvmctl bits (including testcases and libcflat) to be
> built for multiple processor types within the same architecture (e.g. 440 and
> e500). This is important because PowerPC supervisor mode can contain
> significant differences between processors (it's user mode that's more or less
> identical).
>
> For example, the data in a TLB entry and how to manipulate the TLB
> are a major difference between 440 and e500, which is critical here because
> libcflat must create its own mappings and so must know which method to use.
>
> Some of the complexity comes from user/Makefile *not* using the top-level
> config.mak, so we have to add some of the same logic to both configure scripts
> to generate both config.mak files.
>
> Too much makefile logic depends on ARCH containing only the architecture
> name, so it was simpler to create and export a separate PROCESSOR variable.
>   

All applied, thanks.

-- 
error compiling committee.c: too many arguments to function