qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [Consult] About SPRs information


From: Chen Gang
Subject: Re: [Qemu-devel] [Consult] About SPRs information
Date: Fri, 8 May 2015 05:05:39 +0800
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0

Since no response, I assume that it is not suitable to send patches
before finish printing hello world successfully (when sending patches,
we should be sure of the patches are valuable enough).

And sorry, I delayed too much for developing tilegx qemu, next I shall
try to print hello world successfully and send patches within this
month.

Thanks.

On 5/3/15 22:30, Chen Gang wrote:
> 
> After spend two days, I fix the issue below: I misunderstood v4int_l
> instruction, so cause this issue.
> 
> At present, I met mf (memory fence), I guess, we can just skip it, but I
> am not quite sure, welcome any ideas, suggestions and completions for it.
> 
> And I almost re-constructed the code (it doesn't change quite much), if
> suitable, I shall try to send patches to upstream for reviewing. Welcome
> any ideas, suggestions and completions for it.
> 
> Thanks.
> 
> On 5/2/15 12:09, Chen Gang wrote:
>> Hello all:
>>
>> At present, I met an issue (I guess, it should be my code bug), I am
>> analyzing it which may spend quite a few time resources (checking and
>> reconstructing the code is helpful for analyzing this issue):
>>
>>  - It is about invalid memory access for ld operation. The related
>>    tilegx code is "ld r48, r12", the related x86_64 code is
>>    "mov (%rbx),%rbx".
>>
>>  - The related invalid address is 0x128020 which is near (but a little
>>    upper) tilegx rsp.
>>
>>  - I have ways for analyzing it: we have the related libc source code,
>>    and the working flow is not quite complex. But it really needs to
>>    spend me quite a few time resources on it.
>>
>> At present, for me, I plan to send the reconstructed code to upstream
>> within 2 days, and continue analyzing (so that other members can also
>> have a check), but I am not quite sure whether it is suitable.
>>
>> Welcome any ideas, suggestions and completions.
>>
>> Thanks.
>>
>> On 5/2/15 10:42, Chen Gang wrote:
>>>
>>>
>>> On 4/29/15 21:32, Chen Gang wrote:
>>>> On 4/29/15 05:43, Peter Maydell wrote:
>>>>> On 28 April 2015 at 22:32, Chen Gang <address@hidden> wrote:
>>>>>> The related information for cmpexch instruction:
>>>>>>
>>>>>>   Description
>>>>>>
>>>>>>     Compare the 8-byte contents of the CmpValue SPR with the 8-byte
>>>>>>     value in memory at the address held in the first source register. If
>>>>>>     the values are not equal, then no memory operation is performed. If
>>>>>>     the values are equal, the 8-byte quantity from the second source
>>>>>>     register is written into memory at the address held in the first
>>>>>>     source register. In either case, the result of the instruc- tion is
>>>>>>     the value read from memory. The compare and write to memory are
>>>>>>     atomic and thus can be used for synchronization purposes. This
>>>>>>     instruction only operates for addresses aligned to a 8-byte boundary.
>>>>>>     Unaligned memory access causes an Unaligned Data Reference interrupt.
>>>>>
>>>>> I suggest you look at how existing CPUs handle this kind of
>>>>> atomic operation.
>>>>>
>>>
>>> I finished cmpexch(), referenced to store_exclusive() in arm and alpha.
>>> Hope what I have done is correct (I guess, it should be).
>>>
>>>  - Save information about cmpexch (add additional variable in CPUState).
>>>
>>>  - Generate an exception for it.
>>>
>>>  - Process the related exception in main.c with start/end_exclusive()
>>>    just like what alpha or arm has done.
>>>
>>>
>>> Thanks.
>>>
>>>> OK, thanks.
>>>>
>>>
>>>
>>>>> I also suggest you stop adding implementations of *new* instructions
>>>>> and concentrate on getting a basic set into shape for inclusion.
>>>>> The more stuff you keep adding the bigger your patchset is going
>>>>> to get and the harder it is going to get to review.
>>>>>
>>>
>>> Reconstruction the code is really very useful, cmp*, shl?add*, V?int_?.
>>> That will not only simplify reading, but also speed up coding.
>>>
>>> Thank you for your valuable suggestions again.
>>>
>>>>
>>>> For me, current code is not quite much, and really easy enough. At
>>>> present I am still going smoothly (the issues are mainly about
>>>> understanding new instructions which I shall meet).
>>>>
>>>> I still want to reach "display hello world" successfully (it does not
>>>> seem quite difficult to me), then reconstruct current code, and send
>>>> patch to upstream.
>>>>
>>>> But sorry, it seems I can not finish it within this month (and I shall
>>>> try to finish within next month).
>>>>
>>>>
>>>> Thanks.
>>>>
>>>
>>
> 

-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed



reply via email to

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