qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Status of my hacks on the MTTCG WIP branch


From: Alex Bennée
Subject: Re: [Qemu-devel] Status of my hacks on the MTTCG WIP branch
Date: Fri, 15 Jan 2016 15:25:35 +0000
User-agent: mu4e 0.9.15; emacs 25.0.50.1

alvise rigo <address@hidden> writes:

> On Fri, Jan 15, 2016 at 3:51 PM, Alex Bennée <address@hidden> wrote:
>>
>> alvise rigo <address@hidden> writes:
>>
>>> This problem could be related to a missing multi-threaded aware
>>> translation of the atomic instructions.
>>> I'm working on this missing piece, probably the next week I will
>>> publish something.
>>
>> Maybe. We still have Fred's:
>>
>>   Use atomic cmpxchg to atomically check the exclusive value in a STREX
>>
>> Which I think papers over the cracks for both arm and aarch64 in MTTCG
>> while not being as correct as your work.
>
> Keep in mind that Linux on arm64 uses the LDXP/STXP instructions that
> exist solely in aarch64.
> These instructions are purely emulated now and can potentially write
> 128 bits of data in a non-atomic fashion.

Sure, but I doubt they are the reason for this hang as the kernel
doesn't use them.

>
> Regards,
> alvise
>
>>
>>>
>>> Regards,
>>> alvise
>>>
>>> On Fri, Jan 15, 2016 at 3:24 PM, Pranith Kumar <address@hidden> wrote:
>>>> Hi Alex,
>>>>
>>>> On Fri, Jan 15, 2016 at 8:53 AM, Alex Bennée <address@hidden> wrote:
>>>>> Can you try this branch:
>>>>>
>>>>>
>>>>> https://github.com/stsquad/qemu/tree/mttcg/multi_tcg_v8_wip_ajb_fix_locks-r1
>>>>>
>>>>> I think I've caught all the things likely to screw up addressing.
>>>>>
>>>>
>>>> I tried this branch and the boot hangs like follows:
>>>>
>>>> [    2.001083] random: systemd-udevd urandom read with 1 bits of entropy
>>>> available
>>>> main-loop: WARNING: I/O thread spun for 1000 iterations
>>>> [   23.778970] INFO: rcu_sched detected stalls on CPUs/tasks: {} (detected
>>>> by 0, t=2102 jiffies, g=-165, c=-166, q=83)
>>
>> This is just saying the kernel has been waiting for a while and nothing
>> has happened.
>>
>>>> I will try to debug and see where it is hanging.
>>
>> If we knew what the kernel was waiting for that would be useful to know.
>>
>>>>
>>>> Thanks!
>>>> --
>>>> Pranith
>>
>>
>> --
>> Alex Bennée


--
Alex Bennée



reply via email to

[Prev in Thread] Current Thread [Next in Thread]