[Qemu-devel] [PATCH v2 0/5] Add aarch64_be-linux-user target

[Qemu-devel] [PATCH v2 0/5] Add aarch64_be-linux-user target

[Michael Weiser]

Hello,

below patches add support for big-endian aarch64 to linux-user. Almost
everything is already in place. The patches just set up the CPU flags as
required for big-endianess, add a distinction in uname and make sure the
instructions for the signal trampoline end up in memory little-endian.
Finally, configure is extended to allow building of a
aarch64_be-linux-user target and scripts/qemu-binfmt-conf.sh to include
the binfmt magic for aarch64_be ELF files.

With this I am able to run individual aarch64_be binaries as well as
chroot into a full-blown aarch64_be userland using binfmt_misc, running
and compiling things (Gentoo crossdev/native).

v2:
- add binfmt magic to qemu-binfmt-conf.sh
- fix style problems (tab indenting)

Thanks,
Michael

Michael Weiser (5):
  linux-user: Add support for big-endian aarch64
  linux-user: Add separate aarch64_be uname
  linux-user: Fix endianess of aarch64 signal trampoline
  configure: Add aarch64_be-linux-user target
  linux-user: Add aarch64_be magic numbers to qemu-binfmt-conf.sh

 configure                                 |  9 +++++----
 default-configs/aarch64_be-linux-user.mak |  1 +
 linux-user/aarch64/target_syscall.h       |  4 ++++
 linux-user/main.c                         |  6 ++++++
 linux-user/signal.c                       | 10 +++++++---
 scripts/qemu-binfmt-conf.sh               |  6 +++++-
 6 files changed, 28 insertions(+), 8 deletions(-)
 create mode 100644 default-configs/aarch64_be-linux-user.mak

-- 
2.15.1

[Qemu-devel] [PATCH v2 1/5] linux-user: Add support for big-endian aarch64

[Michael Weiser]

Enable big-endian mode for data accesses on aarch64 for big-endian linux
user mode. Activate it for all execution levels as documented by ARM:
Set the SCTLR EE bit for ELs 1 through 3. Additionally set bit E0E in
EL1 to enable it in EL0 as well.

Signed-off-by: Michael Weiser <michael.weiser@gmx.de>
---
 linux-user/main.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/linux-user/main.c b/linux-user/main.c
index 2fd2a143ed..7ea863260d 100644
--- a/linux-user/main.c
+++ b/linux-user/main.c
@@ -4611,6 +4611,12 @@ int main(int argc, char **argv, char **envp)
         }
         env->pc = regs->pc;
         env->xregs[31] = regs->sp;
+#ifdef TARGET_WORDS_BIGENDIAN
+        env->cp15.sctlr_el[1] |= SCTLR_E0E;
+        for (i = 1; i < 4; ++i) {
+            env->cp15.sctlr_el[i] |= SCTLR_EE;
+        }
+#endif
     }
 #elif defined(TARGET_ARM)
     {
-- 
2.15.1

[Qemu-devel] [PATCH v2 2/5] linux-user: Add separate aarch64_be uname

[Michael Weiser]

Make big-endian aarch64 systems identify as aarch64_be as expected by
big-endian userland and toolchains.

Signed-off-by: Michael Weiser <michael.weiser@gmx.de>
---
 linux-user/aarch64/target_syscall.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/linux-user/aarch64/target_syscall.h b/linux-user/aarch64/target_syscall.h
index 1b62953eeb..604ab99b14 100644
--- a/linux-user/aarch64/target_syscall.h
+++ b/linux-user/aarch64/target_syscall.h
@@ -8,7 +8,11 @@ struct target_pt_regs {
     uint64_t        pstate;
 };
 
+#if defined(TARGET_WORDS_BIGENDIAN)
+#define UNAME_MACHINE "aarch64_be"
+#else
 #define UNAME_MACHINE "aarch64"
+#endif
 #define UNAME_MINIMUM_RELEASE "3.8.0"
 #define TARGET_CLONE_BACKWARDS
 #define TARGET_MINSIGSTKSZ       2048
-- 
2.15.1

[Qemu-devel] [PATCH v2 3/5] linux-user: Fix endianess of aarch64 signal trampoline

[Michael Weiser]

Since for aarch64 the signal trampoline is synthesized directly into the
signal frame we need to make sure the instructions end up little-endian.
Otherwise the wrong endianness will cause a SIGILL upon return from the
signal handler on big-endian targets.

Signed-off-by: Michael Weiser <michael.weiser@gmx.de>
---
 linux-user/signal.c | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/linux-user/signal.c b/linux-user/signal.c
index dae14d4a89..81b7fbeb1e 100644
--- a/linux-user/signal.c
+++ b/linux-user/signal.c
@@ -1599,9 +1599,13 @@ static void target_setup_frame(int usig, struct target_sigaction *ka,
     if (ka->sa_flags & TARGET_SA_RESTORER) {
         return_addr = ka->sa_restorer;
     } else {
-        /* mov x8,#__NR_rt_sigreturn; svc #0 */
-        __put_user(0xd2801168, &frame->tramp[0]);
-        __put_user(0xd4000001, &frame->tramp[1]);
+        /*
+         * mov x8,#__NR_rt_sigreturn; svc #0
+         * Since these are instructions they need to be put as little-endian
+         * regardless of target default or current CPU endianness.
+         */
+        __put_user_e(0xd2801168, &frame->tramp[0], le);
+        __put_user_e(0xd4000001, &frame->tramp[1], le);
         return_addr = frame_addr + offsetof(struct target_rt_sigframe, tramp);
     }
     env->xregs[0] = usig;
-- 
2.15.1

[Qemu-devel] [PATCH v2 4/5] configure: Add aarch64_be-linux-user target

[Michael Weiser]

Add target aarch64_be-linux-user. This allows a qemu-aarch64_be binary
to be built that will run big-endian aarch64 binaries.

Signed-off-by: Michael Weiser <michael.weiser@gmx.de>
---
 configure                                 | 9 +++++----
 default-configs/aarch64_be-linux-user.mak | 1 +
 2 files changed, 6 insertions(+), 4 deletions(-)
 create mode 100644 default-configs/aarch64_be-linux-user.mak

diff --git a/configure b/configure
index 9c8aa5a98b..03d95340d8 100755
--- a/configure
+++ b/configure
@@ -657,7 +657,7 @@ case "$cpu" in
     cpu="arm"
     supported_cpu="yes"
   ;;
-  aarch64)
+  aarch64|aarch64_be)
     cpu="aarch64"
     supported_cpu="yes"
   ;;
@@ -6345,7 +6345,7 @@ if test "$linux" = "yes" ; then
   s390x)
     linux_arch=s390
     ;;
-  aarch64)
+  aarch64|aarch64_be)
     linux_arch=arm64
     ;;
   mips64)
@@ -6369,7 +6369,7 @@ target_name=$(echo $target | cut -d '-' -f 1)
 target_bigendian="no"
 
 case "$target_name" in
-  armeb|hppa|lm32|m68k|microblaze|mips|mipsn32|mips64|moxie|or1k|ppc|ppcemb|ppc64|ppc64abi32|s390x|sh4eb|sparc|sparc64|sparc32plus|xtensaeb)
+  armeb|aarch64_be|hppa|lm32|m68k|microblaze|mips|mipsn32|mips64|moxie|or1k|ppc|ppcemb|ppc64|ppc64abi32|s390x|sh4eb|sparc|sparc64|sparc32plus|xtensaeb)
   target_bigendian=yes
   ;;
 esac
@@ -6424,7 +6424,8 @@ case "$target_name" in
     mttcg="yes"
     gdb_xml_files="arm-core.xml arm-vfp.xml arm-vfp3.xml arm-neon.xml"
   ;;
-  aarch64)
+  aarch64|aarch64_be)
+    TARGET_ARCH=aarch64
     TARGET_BASE_ARCH=arm
     bflt="yes"
     mttcg="yes"
diff --git a/default-configs/aarch64_be-linux-user.mak b/default-configs/aarch64_be-linux-user.mak
new file mode 100644
index 0000000000..a69d9d2e41
--- /dev/null
+++ b/default-configs/aarch64_be-linux-user.mak
@@ -0,0 +1 @@
+# Default configuration for aarch64_be-linux-user
-- 
2.15.1

[Qemu-devel] [PATCH v2 5/5] linux-user: Add aarch64_be magic numbers to qemu-binfmt-conf.sh

[Michael Weiser]

As we now have a linux-user aarch64_be target, we can add it to the list
of supported targets in qemu-binfmt-conf.sh

Signed-off-by: Michael Weiser <michael.weiser@gmx.de>
---
 scripts/qemu-binfmt-conf.sh | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/scripts/qemu-binfmt-conf.sh b/scripts/qemu-binfmt-conf.sh
index 8afc3eb5bb..d69953525c 100755
--- a/scripts/qemu-binfmt-conf.sh
+++ b/scripts/qemu-binfmt-conf.sh
@@ -4,7 +4,7 @@
 
 qemu_target_list="i386 i486 alpha arm sparc32plus ppc ppc64 ppc64le m68k \
 mips mipsel mipsn32 mipsn32el mips64 mips64el \
-sh4 sh4eb s390x aarch64 hppa"
+sh4 sh4eb s390x aarch64 aarch64_be hppa"
 
 i386_magic='\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x03\x00'
 i386_mask='\xff\xff\xff\xff\xff\xfe\xfe\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff'
@@ -92,6 +92,10 @@ aarch64_magic='\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x
 aarch64_mask='\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff'
 aarch64_family=arm
 
+aarch64_be_magic='\x7fELF\x02\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\xb7'
+aarch64_be_mask='\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff'
+aarch64_be_family=arm
+
 hppa_magic='\x7f\x45\x4c\x46\x01\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x0f'
 hppa_mask='\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff'
 hppa_family=hppa
-- 
2.15.1

Re: [Qemu-devel] [PATCH v2 0/5] Add aarch64_be-linux-user target

[no-reply]

Hi,

This series seems to have some coding style problems. See output below for
more information:

Type: series
Message-id: 20171219201613.7399-1-michael.weiser@gmx.de
Subject: [Qemu-devel] [PATCH v2 0/5] Add aarch64_be-linux-user target

=== TEST SCRIPT BEGIN ===
#!/bin/bash

BASE=base
n=1
total=$(git log --oneline $BASE.. | wc -l)
failed=0

git config --local diff.renamelimit 0
git config --local diff.renames True

commits="$(git log --format=%H --reverse $BASE..)"
for c in $commits; do
    echo "Checking PATCH $n/$total: $(git log -n 1 --format=%s $c)..."
    if ! git show $c --format=email | ./scripts/checkpatch.pl --mailback -; then
        failed=1
        echo
    fi
    n=$((n+1))
done

exit $failed
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
Switched to a new branch 'test'
1408be599f linux-user: Add aarch64_be magic numbers to qemu-binfmt-conf.sh
246c0913be configure: Add aarch64_be-linux-user target
e845d35c97 linux-user: Fix endianess of aarch64 signal trampoline
c9dc348343 linux-user: Add separate aarch64_be uname
138f48ac61 linux-user: Add support for big-endian aarch64

=== OUTPUT BEGIN ===
Checking PATCH 1/5: linux-user: Add support for big-endian aarch64...
Checking PATCH 2/5: linux-user: Add separate aarch64_be uname...
Checking PATCH 3/5: linux-user: Fix endianess of aarch64 signal trampoline...
Checking PATCH 4/5: configure: Add aarch64_be-linux-user target...
Checking PATCH 5/5: linux-user: Add aarch64_be magic numbers to qemu-binfmt-conf.sh...
WARNING: line over 80 characters
#30: FILE: scripts/qemu-binfmt-conf.sh:95:
+aarch64_be_magic='\x7fELF\x02\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\xb7'

ERROR: line over 90 characters
#31: FILE: scripts/qemu-binfmt-conf.sh:96:
+aarch64_be_mask='\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff'

total: 1 errors, 1 warnings, 18 lines checked

Your patch has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

=== OUTPUT END ===

Test command exited with code: 1


---
Email generated automatically by Patchew [http://patchew.org/].
Please send your feedback to patchew-devel@freelists.org

Re: [Qemu-devel] [PATCH v2 5/5] linux-user: Add aarch64_be magic numbers to qemu-binfmt-conf.sh

[Laurent Vivier]

Le 19/12/2017 à 21:16, Michael Weiser a écrit :
> As we now have a linux-user aarch64_be target, we can add it to the list
> of supported targets in qemu-binfmt-conf.sh
> 
> Signed-off-by: Michael Weiser <michael.weiser@gmx.de>
> ---
>  scripts/qemu-binfmt-conf.sh | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/scripts/qemu-binfmt-conf.sh b/scripts/qemu-binfmt-conf.sh
> index 8afc3eb5bb..d69953525c 100755
> --- a/scripts/qemu-binfmt-conf.sh
> +++ b/scripts/qemu-binfmt-conf.sh
> @@ -4,7 +4,7 @@
>  
>  qemu_target_list="i386 i486 alpha arm sparc32plus ppc ppc64 ppc64le m68k \
>  mips mipsel mipsn32 mipsn32el mips64 mips64el \
> -sh4 sh4eb s390x aarch64 hppa"
> +sh4 sh4eb s390x aarch64 aarch64_be hppa"
>  
>  i386_magic='\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x03\x00'
>  i386_mask='\xff\xff\xff\xff\xff\xfe\xfe\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff'
> @@ -92,6 +92,10 @@ aarch64_magic='\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x
>  aarch64_mask='\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff'
>  aarch64_family=arm
>  
> +aarch64_be_magic='\x7fELF\x02\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\xb7'
> +aarch64_be_mask='\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff'
> +aarch64_be_family=arm

You need a different family, something like "armbe", to let
qemu_set_binfmts() registers aarch64_be on aarch64 and vice-versa.

The principle is binaries of a given family can be executed natively on
the host of the same family, so we don't want to register a binfmt
handler. Is that the case between aarch64 and arch64_be?

Thanks,
Laurent

Re: [Qemu-devel] [PATCH v2 4/5] configure: Add aarch64_be-linux-user target

[Laurent Vivier]

Le 19/12/2017 à 21:16, Michael Weiser a écrit :
> Add target aarch64_be-linux-user. This allows a qemu-aarch64_be binary
> to be built that will run big-endian aarch64 binaries.
> 
> Signed-off-by: Michael Weiser <michael.weiser@gmx.de>
> ---
>  configure                                 | 9 +++++----
>  default-configs/aarch64_be-linux-user.mak | 1 +
>  2 files changed, 6 insertions(+), 4 deletions(-)
>  create mode 100644 default-configs/aarch64_be-linux-user.mak
> 
> diff --git a/configure b/configure
> index 9c8aa5a98b..03d95340d8 100755
> --- a/configure
> +++ b/configure
> @@ -657,7 +657,7 @@ case "$cpu" in
>      cpu="arm"
>      supported_cpu="yes"
>    ;;
> -  aarch64)
> +  aarch64|aarch64_be)
>      cpu="aarch64"
>      supported_cpu="yes"

This switch is for host CPU. Do you want to add aarch64_be as a
supported host architecture?

>    ;;
> @@ -6345,7 +6345,7 @@ if test "$linux" = "yes" ; then
>    s390x)
>      linux_arch=s390
>      ;;
> -  aarch64)
> +  aarch64|aarch64_be)
>      linux_arch=arm64

This is also for the host.

Thanks,
Laurent

Re: [Qemu-devel] [PATCH v2 2/5] linux-user: Add separate aarch64_be uname

[Laurent Vivier]

Le 19/12/2017 à 21:16, Michael Weiser a écrit :
> Make big-endian aarch64 systems identify as aarch64_be as expected by
> big-endian userland and toolchains.
> 
> Signed-off-by: Michael Weiser <michael.weiser@gmx.de>
> ---
>  linux-user/aarch64/target_syscall.h | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/linux-user/aarch64/target_syscall.h b/linux-user/aarch64/target_syscall.h
> index 1b62953eeb..604ab99b14 100644
> --- a/linux-user/aarch64/target_syscall.h
> +++ b/linux-user/aarch64/target_syscall.h
> @@ -8,7 +8,11 @@ struct target_pt_regs {
>      uint64_t        pstate;
>  };
>  
> +#if defined(TARGET_WORDS_BIGENDIAN)
> +#define UNAME_MACHINE "aarch64_be"
> +#else
>  #define UNAME_MACHINE "aarch64"
> +#endif
>  #define UNAME_MINIMUM_RELEASE "3.8.0"

For aarch64_be, I think the minimum release should be 4.9.0
(see kernel commit cfa88c79462d "arm64: Set UTS_MACHINE in the Makefile")

Thanks,
Laurent

Re: [Qemu-devel] [PATCH v2 2/5] linux-user: Add separate aarch64_be uname

[Peter Maydell]

On 20 December 2017 at 15:20, Laurent Vivier <laurent@vivier.eu> wrote:
> Le 19/12/2017 à 21:16, Michael Weiser a écrit :
>> Make big-endian aarch64 systems identify as aarch64_be as expected by
>> big-endian userland and toolchains.
>>
>> Signed-off-by: Michael Weiser <michael.weiser@gmx.de>
>> ---
>>  linux-user/aarch64/target_syscall.h | 4 ++++
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/linux-user/aarch64/target_syscall.h b/linux-user/aarch64/target_syscall.h
>> index 1b62953eeb..604ab99b14 100644
>> --- a/linux-user/aarch64/target_syscall.h
>> +++ b/linux-user/aarch64/target_syscall.h
>> @@ -8,7 +8,11 @@ struct target_pt_regs {
>>      uint64_t        pstate;
>>  };
>>
>> +#if defined(TARGET_WORDS_BIGENDIAN)
>> +#define UNAME_MACHINE "aarch64_be"
>> +#else
>>  #define UNAME_MACHINE "aarch64"
>> +#endif
>>  #define UNAME_MINIMUM_RELEASE "3.8.0"
>
> For aarch64_be, I think the minimum release should be 4.9.0
> (see kernel commit cfa88c79462d "arm64: Set UTS_MACHINE in the Makefile")

Isn't the thing that defines what we set the minimum-release
to glibc, not the kernel? That is, the reason we lie to the
guest about the kernel version for some architectures is because
the glibc for those archs insists on a minimum kernel version
which the host may not have. Unless aarch64_be glibc insists
on kernel 4.9.0 there's no need to tell the guest that.

thanks
-- PMM

Re: [Qemu-devel] [PATCH v2 5/5] linux-user: Add aarch64_be magic numbers to qemu-binfmt-conf.sh

[Michael Weiser]

Hi Laurent,

On Wed, Dec 20, 2017 at 03:18:34PM +0100, Laurent Vivier wrote:

> > +aarch64_be_magic='\x7fELF\x02\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\xb7'
> > +aarch64_be_mask='\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff'
> > +aarch64_be_family=arm

> You need a different family, something like "armbe", to let
> qemu_set_binfmts() registers aarch64_be on aarch64 and vice-versa.

> The principle is binaries of a given family can be executed natively on
> the host of the same family, so we don't want to register a binfmt
> handler. Is that the case between aarch64 and arch64_be?

Right, while the CPU certainly is capable of switching endianess on the
fly I'm not sure if there is any multilib/multiarch userland setup and
kernel interface that would support mixed little/big-endianess of
arm or aarch64 binaries. Even if, it would likely need further detection
in the script to make sure it's there.

Based on that I suspect that qemu-binfmt-conf.sh's current assignment of
armeb and aarch64 into the arm CPU family is over-optimistic as well.
So I'd suggest treating all of arm, armeb, aarch64 and aarch64_be as
separate families.

Incidentally: I noticed that armeb is missing from qemu_target_list. Is
that intentional?

How about the following changes, maybe split into two patches "add
armeb" and "separate ARM CPU families"?

diff --git a/scripts/qemu-binfmt-conf.sh b/scripts/qemu-binfmt-conf.sh
index d69953525c..69ebfe7a6e 100755
--- a/scripts/qemu-binfmt-conf.sh
+++ b/scripts/qemu-binfmt-conf.sh
@@ -2,7 +2,7 @@
 # enable automatic i386/ARM/M68K/MIPS/SPARC/PPC/s390/HPPA
 # program execution by the kernel
 
-qemu_target_list="i386 i486 alpha arm sparc32plus ppc ppc64 ppc64le m68k \
+qemu_target_list="i386 i486 alpha arm armeb sparc32plus ppc ppc64 ppc64le m68k \
 mips mipsel mipsn32 mipsn32el mips64 mips64el \
 sh4 sh4eb s390x aarch64 aarch64_be hppa"
 
@@ -24,7 +24,7 @@ arm_family=arm
 
 armeb_magic='\x7fELF\x01\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x28'
 armeb_mask='\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff'
-armeb_family=arm
+armeb_family=armeb
 
 sparc_magic='\x7fELF\x01\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x02'
 sparc_mask='\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff'
@@ -90,11 +90,11 @@ s390x_family=s390x
 
 aarch64_magic='\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\xb7\x00'
 aarch64_mask='\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff'
-aarch64_family=arm
+aarch64_family=aarch64
 
 aarch64_be_magic='\x7fELF\x02\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\xb7'
 aarch64_be_mask='\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff'
-aarch64_be_family=arm
+aarch64_be_family=aarch64_be
 
 hppa_magic='\x7f\x45\x4c\x46\x01\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x0f'
 hppa_mask='\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff'

Okay?
-- 
bye, Michael

Re: [Qemu-devel] [PATCH v2 4/5] configure: Add aarch64_be-linux-user target

[Michael Weiser]

Hello Laurent,

On Wed, Dec 20, 2017 at 03:55:03PM +0100, Laurent Vivier wrote:

> > diff --git a/configure b/configure
> > index 9c8aa5a98b..03d95340d8 100755
> > --- a/configure
> > +++ b/configure
> > @@ -657,7 +657,7 @@ case "$cpu" in
> >      cpu="arm"
> >      supported_cpu="yes"
> >    ;;
> > -  aarch64)
> > +  aarch64|aarch64_be)
> >      cpu="aarch64"
> >      supported_cpu="yes"
> This switch is for host CPU. Do you want to add aarch64_be as a
> supported host architecture?

No, that's a project for another day, I guess and certainly doesn't
belong into that patch. Dropped.

> >    ;;
> > @@ -6345,7 +6345,7 @@ if test "$linux" = "yes" ; then
> >    s390x)
> >      linux_arch=s390
> >      ;;
> > -  aarch64)
> > +  aarch64|aarch64_be)
> >      linux_arch=arm64
> This is also for the host.

Same here.
-- 
Thanks,
Michael

Re: [Qemu-devel] [PATCH v2 2/5] linux-user: Add separate aarch64_be uname

[Laurent Vivier]

Le 20/12/2017 à 16:36, Peter Maydell a écrit :
> On 20 December 2017 at 15:20, Laurent Vivier <laurent@vivier.eu> wrote:
>> Le 19/12/2017 à 21:16, Michael Weiser a écrit :
>>> Make big-endian aarch64 systems identify as aarch64_be as expected by
>>> big-endian userland and toolchains.
>>>
>>> Signed-off-by: Michael Weiser <michael.weiser@gmx.de>
>>> ---
>>>  linux-user/aarch64/target_syscall.h | 4 ++++
>>>  1 file changed, 4 insertions(+)
>>>
>>> diff --git a/linux-user/aarch64/target_syscall.h b/linux-user/aarch64/target_syscall.h
>>> index 1b62953eeb..604ab99b14 100644
>>> --- a/linux-user/aarch64/target_syscall.h
>>> +++ b/linux-user/aarch64/target_syscall.h
>>> @@ -8,7 +8,11 @@ struct target_pt_regs {
>>>      uint64_t        pstate;
>>>  };
>>>
>>> +#if defined(TARGET_WORDS_BIGENDIAN)
>>> +#define UNAME_MACHINE "aarch64_be"
>>> +#else
>>>  #define UNAME_MACHINE "aarch64"
>>> +#endif
>>>  #define UNAME_MINIMUM_RELEASE "3.8.0"
>>
>> For aarch64_be, I think the minimum release should be 4.9.0
>> (see kernel commit cfa88c79462d "arm64: Set UTS_MACHINE in the Makefile")
> 
> Isn't the thing that defines what we set the minimum-release
> to glibc, not the kernel? That is, the reason we lie to the
> guest about the kernel version for some architectures is because
> the glibc for those archs insists on a minimum kernel version
> which the host may not have. Unless aarch64_be glibc insists
> on kernel 4.9.0 there's no need to tell the guest that.

As you are the author of the original commit (4a24a75810 "linux-user:
Allow targets to specify a minimum uname release"), I guess you're
right. So ignore my comment...

Thanks,
Laurent

Re: [Qemu-devel] [PATCH v2 5/5] linux-user: Add aarch64_be magic numbers to qemu-binfmt-conf.sh

[Laurent Vivier]

Le 20/12/2017 à 16:37, Michael Weiser a écrit :
> Hi Laurent,
> 
> On Wed, Dec 20, 2017 at 03:18:34PM +0100, Laurent Vivier wrote:
> 
>>> +aarch64_be_magic='\x7fELF\x02\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\xb7'
>>> +aarch64_be_mask='\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff'
>>> +aarch64_be_family=arm
> 
>> You need a different family, something like "armbe", to let
>> qemu_set_binfmts() registers aarch64_be on aarch64 and vice-versa.
> 
>> The principle is binaries of a given family can be executed natively on
>> the host of the same family, so we don't want to register a binfmt
>> handler. Is that the case between aarch64 and arch64_be?
> 
> Right, while the CPU certainly is capable of switching endianess on the
> fly I'm not sure if there is any multilib/multiarch userland setup and
> kernel interface that would support mixed little/big-endianess of
> arm or aarch64 binaries. Even if, it would likely need further detection
> in the script to make sure it's there.
> 
> Based on that I suspect that qemu-binfmt-conf.sh's current assignment of
> armeb and aarch64 into the arm CPU family is over-optimistic as well.
> So I'd suggest treating all of arm, armeb, aarch64 and aarch64_be as
> separate families.

So it's not like on intel/AMD where we can execute a 32bit binary on a
64bit kernel?

> 
> Incidentally: I noticed that armeb is missing from qemu_target_list. Is
> that intentional?

no. please fix it :)

> How about the following changes, maybe split into two patches "add
> armeb" and "separate ARM CPU families"?
> 
> diff --git a/scripts/qemu-binfmt-conf.sh b/scripts/qemu-binfmt-conf.sh
> index d69953525c..69ebfe7a6e 100755
> --- a/scripts/qemu-binfmt-conf.sh
> +++ b/scripts/qemu-binfmt-conf.sh
> @@ -2,7 +2,7 @@
>  # enable automatic i386/ARM/M68K/MIPS/SPARC/PPC/s390/HPPA
>  # program execution by the kernel
>  
> -qemu_target_list="i386 i486 alpha arm sparc32plus ppc ppc64 ppc64le m68k \
> +qemu_target_list="i386 i486 alpha arm armeb sparc32plus ppc ppc64 ppc64le m68k \
>  mips mipsel mipsn32 mipsn32el mips64 mips64el \
>  sh4 sh4eb s390x aarch64 aarch64_be hppa"
>  
> @@ -24,7 +24,7 @@ arm_family=arm
>  
>  armeb_magic='\x7fELF\x01\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x28'
>  armeb_mask='\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff'
> -armeb_family=arm
> +armeb_family=armeb
>  
>  sparc_magic='\x7fELF\x01\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x02'
>  sparc_mask='\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff'
> @@ -90,11 +90,11 @@ s390x_family=s390x
>  
>  aarch64_magic='\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\xb7\x00'
>  aarch64_mask='\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff'
> -aarch64_family=arm
> +aarch64_family=aarch64
>  
>  aarch64_be_magic='\x7fELF\x02\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\xb7'
>  aarch64_be_mask='\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff'
> -aarch64_be_family=arm
> +aarch64_be_family=aarch64_be
>  
>  hppa_magic='\x7f\x45\x4c\x46\x01\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x0f'
>  hppa_mask='\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff'
> 
> Okay?
> 

It looks good to me.

Thanks,
Laurent

Re: [Qemu-devel] [PATCH v2 2/5] linux-user: Add separate aarch64_be uname

[Michael Weiser]

Hi Peter,

On Wed, Dec 20, 2017 at 03:36:29PM +0000, Peter Maydell wrote:

> >>  #define UNAME_MINIMUM_RELEASE "3.8.0"

> > For aarch64_be, I think the minimum release should be 4.9.0
> > (see kernel commit cfa88c79462d "arm64: Set UTS_MACHINE in the Makefile")

> Isn't the thing that defines what we set the minimum-release
> to glibc, not the kernel? That is, the reason we lie to the
> guest about the kernel version for some architectures is because
> the glibc for those archs insists on a minimum kernel version
> which the host may not have. Unless aarch64_be glibc insists
> on kernel 4.9.0 there's no need to tell the guest that.

I can confirm that cross-compiled glibc runs fine with the current
value. Also, a native compile of glibc inside an qemu-aarch64_be binfmt
chroot configured without problem and currently churns along compiling.

My Gentoo setup calls configure with --enable-kernel=3.2.0 and that says
about this:

checking installed Linux kernel header files... 3.2.0 or later
configure: WARNING: minimum kernel version reset to 3.7.0
checking for kernel header at least 3.7.0... ok

So it seems your memory is right.
-- 
Bye,
Michael

Re: [Qemu-devel] [PATCH v2 5/5] linux-user: Add aarch64_be magic numbers to qemu-binfmt-conf.sh

[Michael Weiser]

Hi Laurent,

On Wed, Dec 20, 2017 at 04:56:41PM +0100, Laurent Vivier wrote:

> > Based on that I suspect that qemu-binfmt-conf.sh's current assignment of
> > armeb and aarch64 into the arm CPU family is over-optimistic as well.
> > So I'd suggest treating all of arm, armeb, aarch64 and aarch64_be as
> > separate families.
> So it's not like on intel/AMD where we can execute a 32bit binary on a
> 64bit kernel?

An aarch64 CPU is capable of running arm (i.e. aarch32) code. And I
think this is supported as a multilib setup on Linux. But not in mixed
endianess as far as I know.

Looking at the code again, I'm confused now: Wouldn't the current logic
treat an actual i386 machine as capable of running x86_64 binaries
natively and omit registering the handler for x86_64?

> > Incidentally: I noticed that armeb is missing from qemu_target_list. Is
> > that intentional?
> no. please fix it :)

Will do.

> > Okay?
> It looks good to me.

Based on the above I now lean towards the following assignments:

 arm_family=arm
[...]
-armeb_family=arm
+armeb_family=armeb
[...] 
 aarch64_family=arm
[...]
-aarch64_be_family=arm
+aarch64_be_family=armeb

This would be in line with what you recommended, how i386/x86_64 is
treated and reflects the principal platform capabilities.
-- 
Bye,
Michael

Re: [Qemu-devel] [PATCH v2 5/5] linux-user: Add aarch64_be magic numbers to qemu-binfmt-conf.sh

[Laurent Vivier]

Le 20/12/2017 à 17:15, Michael Weiser a écrit :
> Hi Laurent,
> 
> On Wed, Dec 20, 2017 at 04:56:41PM +0100, Laurent Vivier wrote:
> 
>>> Based on that I suspect that qemu-binfmt-conf.sh's current assignment of
>>> armeb and aarch64 into the arm CPU family is over-optimistic as well.
>>> So I'd suggest treating all of arm, armeb, aarch64 and aarch64_be as
>>> separate families.
>> So it's not like on intel/AMD where we can execute a 32bit binary on a
>> 64bit kernel?
> 
> An aarch64 CPU is capable of running arm (i.e. aarch32) code. And I
> think this is supported as a multilib setup on Linux. But not in mixed
> endianess as far as I know.
> 
> Looking at the code again, I'm confused now: Wouldn't the current logic
> treat an actual i386 machine as capable of running x86_64 binaries
> natively and omit registering the handler for x86_64?

It can be read like that, but actually 32bit machine cannot emulate
64bit architecture, so we don't register it.

So for the same family:

- on 64bit machine, we don't register the interpreter because the 32bit
binary can be executed natively,

- on 32bit machine, we don't register the interpreter because the
interpreter cannot work,

Thanks,
Laurent

Re: [Qemu-devel] [PATCH v2 5/5] linux-user: Add aarch64_be magic numbers to qemu-binfmt-conf.sh

[Michael Weiser]

Hi Laurent,

On Wed, Dec 20, 2017 at 05:43:34PM +0100, Laurent Vivier wrote:

> >> So it's not like on intel/AMD where we can execute a 32bit binary on a
> >> 64bit kernel?
> > 
> > An aarch64 CPU is capable of running arm (i.e. aarch32) code. And I
> > think this is supported as a multilib setup on Linux. But not in mixed
> > endianess as far as I know.
> > 
> > Looking at the code again, I'm confused now: Wouldn't the current logic
> > treat an actual i386 machine as capable of running x86_64 binaries
> > natively and omit registering the handler for x86_64?
> - on 32bit machine, we don't register the interpreter because the
> interpreter cannot work,

Okay, makes sense.

Meanwhile I verified that a little-endian arm kernel indeed refuses to
run a statically linked big-endian arm binary and vice-versa with
ENOEXEC ("Exec format error").

Looking at fs/binfmt_elf.c of the kernel, I understand that the kernel
makes no attempt to adjust for binary images of differing endianness.
Because the e_type ELF header field is byte-swapped in the big-endian
arm ELF binary, the kernel will see an invalid executable type and
return ENOEXEC.

Based on this I'm reasonably sure that a mixed little-/big-endian
userland is not currently possible on Linux. So I've gone with the
arm/armeb family split.

I'll push out a new version of the patch series with all the discussed
changes in a minute.
-- 
Bye,
Michael