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(+)
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" 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" + ;; hppa|parisc|parisc64) cpu="hppa" ;;
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
-
Anup Patel -
Marcin Juszkiewicz -
Peter Maydell -
Richard Henderson