Re: [PATCH v7 02/21] target/loongarch: Add core definition

[Song Gao]

Hi, all

On 10/20/2021 09:56 PM, Richard Henderson wrote:
> On 10/20/21 5:00 AM, WANG Xuerui wrote:
>> On 2021/10/20 16:54, Song Gao wrote:
>>
>>> On 10/19/2021 01:38 AM, Philippe Mathieu-Daudé wrote:
>>>> On 10/18/21 18:06, WANG Xuerui wrote:
>>>>
>>>> On 10/18/21 20:47, Song Gao wrote:
>>>>>> +static void set_loongarch_cpucfg(CPULoongArchState *env)
>>>>>> +{
>>>>>> +    int i;
>>>>>> +
>>>>>> +    for (i = 0; i < 49; i++) {
>>>>>> +        env->cpucfg[i] = 0x0;
>>>>>> +    }
>>>>>> +    env->cpucfg[0] = 0x14c010;
>>>>>> +    env->cpucfg[1] = 0x3f2f2fe;
>>>>>> +    env->cpucfg[2] = 0x60c3cf;
>>>>>> +    env->cpucfg[3] = 0xcff;
>>>>>> +    env->cpucfg[4] = 0x5f5e100;
>>>>>> +    env->cpucfg[5] = 0x10001;
>>>>>> +    env->cpucfg[16] = 0x2c3d;
>>>>>> +    env->cpucfg[17] = 0x6080003;
>>>>>> +    env->cpucfg[18] = 0x6080003;
>>>>>> +    env->cpucfg[19] = 0x60800f;
>>>>>> +    env->cpucfg[20] = 0x60f000f;
>>>>> I know these values are taken from a real 3A5000 chip, since I have such
>>>>> a machine and I've done the experiment, but others likely wouldn't
>>>>> notice so quickly. Maybe put some comment on top of this function to
>>>>> illustrate this?
>>>> Simpler: ...
>>>>
>>> On linux-user emulation. We don't care about the value of cpucfg[i].
>>> I think we only need to set cpucfg[i] to 0. and set value on system 
>>> emulations, is that better?
>>
>> I'm afraid that wouldn't be better; actually it would be *wrong* to just
>> return zeroes for user-space CPUCFG accesses. CPUCFG is designed to
>> provide runtime feature probing like CPUID, and is usable from
>> user-space. So, one can only assume this data is being used, and
>> properly return data.
>>
>> I've heard that kernel could choose to not actually enable all features
>> for which CPUCFG indicate support, while not configuring CPUCFG values
>> to reflect that, thus making CPUCFG values unreliable; that's not a
>> proper reason to return zeroes. Kernel should be fixed to properly
>> configure CPUCFG instead. Because otherwise you wouldn't make such an
>> instruction an unprivileged one in the first place...
> 
> In the meantime, I think you really need to filter these values to those you 
> have implemented.  E.g. cpucfg[2].LASX here indicates support for the 256-bit 
> vector extension.  Similarly the COMPLEX and CRYPTO extensions.
> 
> I think you would do well to add some FIELD definitions so that these can be 
> set symbolically.
>
OK.


BTW,   

Account yangxiaojuan@loongson.cn It seems that she has been blacklisted. 
Xiaojuan sent 31 e-mails, which were not displayed since the 21st one, people 
who don't have a CC can't read all the emails,  and xiaojuan reply can't be in 
qemu-level@nongnu.org. 
  

The follow is the return message:

抱歉，您的邮件被退回来了……/
Sorry, your mail is returned...
原邮件信息/
Original e-mail message :        
时间/Time :       2021-10-20 09:33:59
主题/Subject :    Re: Re: [PATCH 00/31] Add Loongarch softmmu support.
收件人/To :        qemu-devel@nongnu.org
退信原因/
Bounce reason :         
由于对方服务器不稳定，或者双方服务器网络连接质量不佳，或者防火墙过滤，而无法连接上对方服务器。
Can not connect to recipient's server because of unstable network or firewall 
filter.
rcpt handle timeout,last handle info: Can not connect to 
nongnu.org:2001:470:142:3::10:25
建议解决方案/
Proposed Solution :     

    邮差温馨提示：请在稍后时间重新尝试投递，或者联系联系管理员、技术中心协助。/
    Warm tips:Please try again later, or contact administrator or helpcenter 
for help.
    如果您有其他退信问题，欢迎向客服中心联系/
    If you have any other bounce problems, please contact customer service 
center

退信代码/
Bounce Code :   
can not connect to

----------------
This message is generated by Coremail.



Xuerui said: 

"You may address the several review comments then just send v2. This way
the threading is less likely to be damaged (you need to exactly specify
In-Reply-To headers and such for the re-sent patches to correctly link
to this thread, I think it's not worth the effort). "

I think this will have the same problem. 

Richard and Karl,  How can we solve this problem？


Thanks
Song Gao.
 
> 
> r~