configure: Support QEMU cross-compiling for ARM64 host

We should be able to cross compile QEMU for ARM64 host.

This is required for trying out ARM 32-bit guest on ARM64 host using QEMU + KVM ARM64.

Signed-off-by: Anup Patel <anup.patel@linaro.org>
---
 configure |    5 +++++
 1 file changed, 5 insertions(+)

On 8 January 2013 11:05, Anup Patel <anup.patel@linaro.org> wrote:
> diff --git a/configure b/configure
> index fe18ed2..0bfb8bb 100755
> --- a/configure
> +++ b/configure
> @@ -366,6 +366,8 @@ elif check_define __s390__ ; then
>    fi
>  elif check_define __arm__ ; then
>    cpu="arm"
> +elif check_define __aarch64__ ; then
> +  cpu="arm64"

This should be "aarch64"...

>  elif check_define __hppa__ ; then
>    cpu="hppa"
>  else
> @@ -388,6 +390,9 @@ case "$cpu" in
>    armv*b|armv*l|arm)
>      cpu="arm"
>    ;;
> +  arm64|aarch64)
> +    cpu="arm64"
> +  ;;

...and this should just be
      aarch64)
          cpu="aarch64"
     ;;

Here's the rationale for that naming...

So, to start off with, the official ARM terminology goes:
 * ARMv8 is the new version of the architecture, covering both
   32 and 64 bit systems. (v7 is the most recent public arch
   version and is 32 bit only.) There may well be a v9 in future.
 * AArch64 is the 64 bit operating mode of a 64-bit aware v8
   core. (AArch32 is the corresponding 32 bit operating mode.)
   The core can transition between these at exception boundaries.
 * A64 is the instruction set visible in AArch64. A32 and T32
   are the 'classic' ARM and Thumb(2) instruction sets visible in
   AArch32. NB that v8 includes some new stuff even in A32/T32
   (eg crypto extensions, some extensions to Neon, etc).
 * arm64 is what the kernel port is called, since Linus doesn't
   much like any of the above :-) Note that 'uname -m' still
   says "aarch64", and the gcc triplet uses "aarch64". Only
   kernel devs looking at source filenames see 'arm64'.

So, QEMU names:
For the target architecture name (ie what comes out in the
qemu-foo and qemu-system-foo binary names) we generally use
the same name that 'uname -m' produces on those machines. In
this case that would be "aarch64", hence my suggested changes.

The translator sources (as and when we implement a
TCG QEMU target for this) should live under the existing target-arm.
We will probably want to put the A64 decoder in its own file,
ie target-arm/translate-a64.c.

[Big-endian would be aarch64_be, but let's not go there.]


Also, I suspect this isn't the only thing that will be required.
Presumably for an aarch64 build of QEMU we want to use
the 64 bit kernel KVM headers, which means we need to import
them. Since neither ARM 32 or 64 bit KVM has landed upstream
yet those parts are definitely not going to be ready for upstream
qemu just yet. Similarly the configure check for whether we can
set CONFIG_KVM needs to accept "target cpu is arm and
host cpu is aarch64", otherwise we won't enable KVM at all.

-- PMM

On 8 January 2013 17:38, Peter Maydell <peter.maydell@linaro.org> wrote:

> On 8 January 2013 11:05, Anup Patel <anup.patel@linaro.org> wrote:
> > diff --git a/configure b/configure
> > index fe18ed2..0bfb8bb 100755
> > --- a/configure
> > +++ b/configure
> > @@ -366,6 +366,8 @@ elif check_define __s390__ ; then
> >    fi
> >  elif check_define __arm__ ; then
> >    cpu="arm"
> > +elif check_define __aarch64__ ; then
> > +  cpu="arm64"
>
> This should be "aarch64"...
>
> >  elif check_define __hppa__ ; then
> >    cpu="hppa"
> >  else
> > @@ -388,6 +390,9 @@ case "$cpu" in
> >    armv*b|armv*l|arm)
> >      cpu="arm"
> >    ;;
> > +  arm64|aarch64)
> > +    cpu="arm64"
> > +  ;;
>
> ...and this should just be
>       aarch64)
>           cpu="aarch64"
>      ;;
>
> Here's the rationale for that naming...
>
> So, to start off with, the official ARM terminology goes:
>  * ARMv8 is the new version of the architecture, covering both
>    32 and 64 bit systems. (v7 is the most recent public arch
>    version and is 32 bit only.) There may well be a v9 in future.
>  * AArch64 is the 64 bit operating mode of a 64-bit aware v8
>    core. (AArch32 is the corresponding 32 bit operating mode.)
>    The core can transition between these at exception boundaries.
>  * A64 is the instruction set visible in AArch64. A32 and T32
>    are the 'classic' ARM and Thumb(2) instruction sets visible in
>    AArch32. NB that v8 includes some new stuff even in A32/T32
>    (eg crypto extensions, some extensions to Neon, etc).
>  * arm64 is what the kernel port is called, since Linus doesn't
>    much like any of the above :-) Note that 'uname -m' still
>    says "aarch64", and the gcc triplet uses "aarch64". Only
>    kernel devs looking at source filenames see 'arm64'.
>
> So, QEMU names:
> For the target architecture name (ie what comes out in the
> qemu-foo and qemu-system-foo binary names) we generally use
> the same name that 'uname -m' produces on those machines. In
> this case that would be "aarch64", hence my suggested changes.
>

Agree with your suggestion. I will update the patch accordingly.


>
> The translator sources (as and when we implement a
> TCG QEMU target for this) should live under the existing target-arm.
> We will probably want to put the A64 decoder in its own file,
> ie target-arm/translate-a64.c.
>
> [Big-endian would be aarch64_be, but let's not go there.]
>
>
> Also, I suspect this isn't the only thing that will be required.
> Presumably for an aarch64 build of QEMU we want to use
> the 64 bit kernel KVM headers, which means we need to import
> them. Since neither ARM 32 or 64 bit KVM has landed upstream
> yet those parts are definitely not going to be ready for upstream
> qemu just yet. Similarly the configure check for whether we can
> set CONFIG_KVM needs to accept "target cpu is arm and
> host cpu is aarch64", otherwise we won't enable KVM at all.
>

Yes. This patch only tries to make sure that the configure step falls
through and
at-least QEMU cross-compilation starts.
(assuming we have provided the QEMU dependencies such as zlib, glib-2.0,
etc.)


>
> -- PMM
>

--Anup

On 8 January 2013 12:24, Anup Patel <anup.patel@linaro.org> wrote:
> On 8 January 2013 17:38, Peter Maydell <peter.maydell@linaro.org> wrote:
>> Also, I suspect this isn't the only thing that will be required.

> Yes. This patch only tries to make sure that the configure step falls
> through and at-least QEMU cross-compilation starts.

It's generally considered polite to mention if the patch you're posting
is still in the "this doesn't actually work yet" state :-)
Tagging it [RFC] rather than [PATCH] is probably also a good idea.

thanks
-- PMM

On 01/08/2013 04:08 AM, Peter Maydell wrote:
> The translator sources (as and when we implement a
> TCG QEMU target for this) should live under the existing target-arm.

Of this I'm not certain, given that A64 is different enough from A32
to warrant a brand new gcc backend.  I havn't tried to reverse engineer
the encodings from the binutils sources to understand the details; I'm
happy to wait until proper documentation is finally released.


r~

On 8 January 2013 15:57, Richard Henderson <rth@twiddle.net> wrote:
> On 01/08/2013 04:08 AM, Peter Maydell wrote:
>> The translator sources (as and when we implement a
>> TCG QEMU target for this) should live under the existing target-arm.
>
> Of this I'm not certain, given that A64 is different enough from A32
> to warrant a brand new gcc backend.  I havn't tried to reverse engineer
> the encodings from the binutils sources to understand the details; I'm
> happy to wait until proper documentation is finally released.

Since an ARMv8 64 bit CPU can run both 32 bit and 64 bit binaries,
a QEMU TCG system level emulator would need the existing 32 bit
code as well as new 64 bit code, so putting them both in the same
directory seems to make sense to me. GCC backends don't need to
emit code for both modes at once (since you can only change mode
on an exception boundary) so they don't have the same requirements.

(Also, all our other "we have a 32 and a 64 bit version" tcg targets live
in a shared target-foo/ directory.)

-- PMM