Re: [PATCH v14 02/26] target/loongarch: Add core definition

[WANG Xuerui]

Hi,

On 2022/1/12 18:17, gaosong wrote:

Hi,

On 2022/1/12 下午5:28, gaosong wrote:

+    data = "" CPUCFG16, L3_IUUNIFY, 1);
+    data = "" CPUCFG16, L3_IUINCL, 1);
+    env->cpucfg[16] = data;
+
+    data = ""
+    data = "" CPUCFG17, L1IU_WAYS, 0x8003);

This seems out-of-place, according to the manual this field is Way-1 for the L1I cache, so you have 0x8004=32772 ways in this cache?

Same for all similar constructions below.

I have time to reply to your comment now.

As in the previous comments, I don't remember which one,these values should be the same as the values of the physical environment. I dumped 'CPUCFG17' value again,
the value is no problem. Maybe you didn't think about dumping these values when you commented. The value of  'L11U_SIZE' is dumped to be 0. and cpucfg[i] has been 
initialized to 0 before. There is no need to set it again.

Not quite right,  cpucfg[17] is '0x60800003', I missed a '0',  I don't know from which version it's wrong
Thank you very much,  if I hadn't dumped the value today, I wouldn't have realized the wrong.  

Still not quite right; maybe you made a typo there as the value is `0x06080003` (the fields are all whole bytes/shorts, so very easy to recognize).

I used the following snippet to get real values from the 3A5000 system:

#include <stdio.h>

int cpucfg(const int sel)
{
        int ret;
        __asm__ __volatile__("cpucfg %0, %1" : "=r"(ret) : "r"(sel));
        return ret;
}

int main(void)
{
        int i;
        int c;
        for (i = 0; i < 64; i++) {
                c = cpucfg(i);
                if (!c) {
                        continue;
                }
                printf("CPUCFG.0x%-2x = 0x%08x\n", i, c);
        }

        return 0;
}

And I got the following output so we can cross-check:

CPUCFG.0x0  = 0x0014c010
CPUCFG.0x1  = 0x03f2f2fe
CPUCFG.0x2  = 0x007ccfc7
CPUCFG.0x3  = 0x0000fcff
CPUCFG.0x4  = 0x05f5e100
CPUCFG.0x5  = 0x00010001
CPUCFG.0x6  = 0x00007f33
CPUCFG.0x10 = 0x00002c3d
CPUCFG.0x11 = 0x06080003
CPUCFG.0x12 = 0x06080003
CPUCFG.0x13 = 0x0608000f
CPUCFG.0x14 = 0x060e000f
CPUCFG.0x30 = 0x0000000e

Obviously the 0x30 leaf is undocumented, but not implementing it shouldn't matter either, as userspace has no way to make use of that when people aren't even aware of its existence. The other fields are of course to be checked to only leave the implemented bits set in the QEMU implementation.

Hope that helps!