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 yangxiaoj...@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-le...@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~
