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

[alvise rigo]

On Fri, Jan 15, 2016 at 4:25 PM, Alex Bennée <address@hidden> wrote:
>
> 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.

The kernel does use them for __cmpxchg_double in
arch/arm64/include/asm/atomic_ll_sc.h.
In any case, the normal exclusive instructions are also emulated in
target-arm/translate-a64.c.

alvise

>
>>
>> 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