Re: Can't clone static arm64 binary from https://github.com/susematz/qemu/tree/aarch64-1.6

[Julien Grall <julien.grall@linaro.org>]

On 06/25/2014 12:45 PM, Ian Campbell wrote:
> On Wed, 2014-06-25 at 12:40 +0100, Julien Grall wrote:
>> On 06/25/2014 09:28 AM, Ian Campbell wrote:
>>> On Tue, 2014-06-24 at 13:57 -0400, John McDermott wrote:
>>>> Xen Developers,
>>>>
>>>> Trying to build arm64 on x86_64 following the guidance on the wiki;
>>>> everything ok 'till I have to run qemu static for arm64. It fails
>>>> because there is no arm64 specific binary installed in Ubuntu 13.10,
>>>> even though the wiki procedure says it should work.
>>>
>>> Which wiki page?
>>>
>>>>  Not to worry; get the source and build it, I think.
>>>>
>>>> However, I cannot clone the git repo for the source, no matter which system I clone from. I even tried it from a Mac and get the same "fatal repo not found" error.
>>>>
>>>> The repo is 'https://github.com/susematz/qemu/tree/aarch64-1.6/' and I can see it in my browser just fine.
>>>>
>>>> Is there an alternative source for this code?
>>>
>>> IIRC it's all in mainline qemu these days.
>>
>> Last time I tried mainline QEMU (it was about a month ago), I was not
>> able to build the different package with an opensuse rootfs.
>>
>> It was because of the threading issue. I don't think it has been fixed yet.
> 
> The threading issue affects the Xen tools build? Or were you building
> something else?

Actually it was affecting the package manager zypper:

sh-4.2# zypper install gcc
Retrieving repository 'openSUSE-13.1-repo-update' metadata -----------------------------------------------------------------------------------------------------------------------------------------------------[|]
*** Error in `/usr/bin/zypper': malloc(): memory corruption: 0x0000004004000fc0 ***
Segmentation fault (core dumped)
sh-4.2# zypper install gcc
Retrieving repository 'openSUSE-13.1-repo-update' metadata -----------------------------------------------------------------------------------------------------------------------------------------------------[\]
/home/xentest/works/qemu/tcg/tcg.c:1693: tcg fatal error

I had a chat with Alexander Graf and Alex Bennée. IIRC they were looking
to a nice way to handle it in qemu upstream.

In meantime, if you want to use QEMU mainline with the opensuse rootfs,
you can add this patch (copied from the suse tree):

commit ca45f1d446ca88675e85bf80f133d3d8d955dbf0
Author: Alexander Graf <agraf@suse.de>
Date:   Tue Jul 10 20:40:55 2012 +0200

    linux-user: Run multi-threaded code on a single core

    Running multi-threaded code can easily expose some of the fundamental
    breakages in QEMU's design. It's just not a well supported scenario.

    So if we pin the whole process to a single host CPU, we guarantee that
    we will never have concurrent memory access actually happen. We can still
    get scheduled away at any time, so it's no complete guarantee, but apparently
    it reduces the odds well enough to get my test cases to pass.

    This gets Java 1.7 working for me again on my test box.

    Signed-off-by: Alexander Graf <agraf@suse.de>

diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 4823aa0..ff5ed06 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -4334,6 +4334,15 @@ static int do_fork(CPUArchState *env, unsigned int flags, abi_ulong newsp,
         if (nptl_flags & CLONE_SETTLS)
             cpu_set_tls (new_env, newtls);

+        /* agraf: Pin ourselves to a single CPU when running multi-threaded.
+           This turned out to improve stability for me. */
+        {
+            cpu_set_t mask;
+            CPU_ZERO(&mask);
+            CPU_SET(0, &mask);
+            sched_setaffinity(0, sizeof(mask), &mask);
+        }
+
         /* Grab a mutex so that thread setup appears atomic.  */
         pthread_mutex_lock(&clone_lock);

---

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel