Re: [Qemu-devel] [PATCH v3 00/15] target-sparc improvements

[Artyom Tarasenko]

On Mon, Oct 31, 2016 at 5:32 PM, Richard Henderson <address@hidden> wrote:
> On 10/31/2016 10:21 AM, Artyom Tarasenko wrote:
>>
>> On Mon, Oct 31, 2016 at 5:06 PM, Richard Henderson <address@hidden>
>> wrote:
>>>
>>> On 10/31/2016 09:40 AM, Artyom Tarasenko wrote:
>>>>>
>>>>>
>>>>>   * The "Remove asi helper code handled inline" patch retains the code
>>>>> within
>>>>>     ldda to handle asis that must be handled out of line.  This fixes
>>>>> the
>>>>>     FreeBSD 10.3 boot problem.  While the UA2007 spec (and thus sun4v?)
>>>>> doesn't
>>>>>     allow for such, it would seem that US2 hardware does.
>>>>
>>>>
>>>>
>>>> What ASI was failing? It may still be a part of sun4v CPUs if it's
>>>> described in UST1/UST2 supplements.
>>>
>>>
>>>
>>> 0x00000000c08e5680:  clr  %g4
>>> 0x00000000c08e5684:  mov  1, %g1
>>> 0x00000000c08e5688:  sllx  %g1, 0x24, %o5
>>> 0x00000000c08e568c:  mov  -1, %g1
>>> 0x00000000c08e5690:  sllx  %g1, 0x23, %g1
>>> 0x00000000c08e5694:  xor  %g1, -128, %o4
>>> 0x00000000c08e5698:  ldda  [ %g4 ] #ASI_IC_TAG, %g0     ****
>>> 0x00000000c08e569c:  mov  %g1, %g2
>>> 0x00000000c08e56a0:  and  %g1, %o5, %g1
>>> 0x00000000c08e56a4:  brz,a   %g1, 0xc08e56dc
>>>
>>> So indeed it would appear that FreeBSD does in fact want the half of the
>>> result that would get stored into %g1.  As far as I can see they could
>>> have
>>> achieved the same result with
>>>
>>>         ldxa    [%g4] #ASI_IC_TAG, %g1
>>>         srl     %g1, 0, %g1
>>>
>>> to stay within the nominal spec.
>>
>>
>> While your code is indeed more readable, I think the current code is
>> still within the spec:
>>
>>  UA2005 chap 7.59:
>> "Note: Execution of an LDTWA instruction with rd = 0 modifies only
>> R[1]."
>
>
> What I mean is found in the description of LDTWA (looking at ua2011 here):
>
>   # Nontranslating ASIs (see page 395) should only be accessed
>   # using LDXA (not LDTWA) instructions. If an LDTWA
>   # referencing a nontranslating ASI is executed, per the above
>   # table, it generates a DAE_invalid_asi exception
>   # (impl. dep. #300-U4-Cs10).
>
> ASI_IC_TAG is certainly nontranslating ASI.
>
> All of the translating ASIs supported by LDTXA are already handled by
> GET_ASI_DTWINX; all of the translating ASIs supported by LDTWA are already
> handled by GET_ASI_DIRECT.  By that reading the "default:" case should
> simply raise DAE_invalid_asi.
>

Interesting. The US2 spec says that  ASI_IC_TAG is
"LDDA, STDFA or STXA only. Other types of access cause a
data_access_exception trap."



-- 
Regards,
Artyom Tarasenko

SPARC and PPC PReP under qemu blog: http://tyom.blogspot.com/search/label/qemu