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