[PATCH for-7.1 0/4] Last-minute LoongArch CPU model naming tweaks

[PATCH for-7.1 0/4] Last-minute LoongArch CPU model naming tweaks

[WANG Xuerui]

Hi,

Some people are already testing out the 7.1 RCs for the LoongArch
emulation, and have suggested improvements to the CPU model naming
scheme. While assessing the situation I also found the documentation
already out-of-date, in addition to being especially hard to read (for a
Chinese who could *not* understand Chinglish, though).

Sorry for being really late (I've mostly been focusing on my day job and
LLVM bringup work for LoongArch recently), but hopefully these changes
could still be integrated, because target/loongarch is fresh addition
for 7.1 nobody should have depended on its implementation details yet.
Anyway, since the "new world" ecosystem isn't expected to mature and
attract lots of users very soon, it could be acceptable to just punt
this to 7.2, and issue incompatible change notices as usual. I
personally would be fine with either.

WANG Xuerui (4):
  target/loongarch: Only allow short -cpu arguments without type name
    suffix
  target/loongarch: Trim type name suffix in -cpu help output
  target/loongarch: rename the TCG CPU "la464" to "qemu64-v1.00"
  docs, target/loongarch: Rewrite the LoongArch docs

 docs/system/loongarch/loongson3.rst | 41 ------------
 docs/system/loongarch/virt.rst      | 41 ++++++++++++
 hw/loongarch/virt.c                 | 14 +---
 target/loongarch/README             | 99 -----------------------------
 target/loongarch/README.md          | 75 ++++++++++++++++++++++
 target/loongarch/cpu.c              | 21 +++---
 6 files changed, 128 insertions(+), 163 deletions(-)
 delete mode 100644 docs/system/loongarch/loongson3.rst
 create mode 100644 docs/system/loongarch/virt.rst
 delete mode 100644 target/loongarch/README
 create mode 100644 target/loongarch/README.md

-- 
2.35.1

[PATCH for-7.1 1/4] target/loongarch: Only allow short -cpu arguments without type name suffix

[WANG Xuerui]

From: WANG Xuerui <git@xen0n.name>

Previously both "foo" and "foo-loongarch-cpu" are accepted for the -cpu
command-line option, the latter of which being excessively long and
redundant, hence unwanted. Remove support for consistency with other
targets and simpler code.

Signed-off-by: WANG Xuerui <git@xen0n.name>
---
 target/loongarch/cpu.c | 11 ++++-------
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/target/loongarch/cpu.c b/target/loongarch/cpu.c
index 941e2772bc..dc233ee209 100644
--- a/target/loongarch/cpu.c
+++ b/target/loongarch/cpu.c
@@ -573,14 +573,11 @@ static ObjectClass *loongarch_cpu_class_by_name(const char *cpu_model)
 {
     ObjectClass *oc;
 
-    oc = object_class_by_name(cpu_model);
+    g_autofree char *typename = g_strdup_printf(LOONGARCH_CPU_TYPE_NAME("%s"),
+                                                cpu_model);
+    oc = object_class_by_name(typename);
     if (!oc) {
-        g_autofree char *typename 
-            = g_strdup_printf(LOONGARCH_CPU_TYPE_NAME("%s"), cpu_model);
-        oc = object_class_by_name(typename);
-        if (!oc) {
-            return NULL;
-        }
+        return NULL;
     }
 
     if (object_class_dynamic_cast(oc, TYPE_LOONGARCH_CPU)
-- 
2.35.1

Re: [PATCH for-7.1 1/4] target/loongarch: Only allow short -cpu arguments without type name suffix

[Richard Henderson]

On 8/14/22 09:55, WANG Xuerui wrote:
> From: WANG Xuerui <git@xen0n.name>
> 
> Previously both "foo" and "foo-loongarch-cpu" are accepted for the -cpu
> command-line option, the latter of which being excessively long and
> redundant, hence unwanted. Remove support for consistency with other
> targets and simpler code.
> 
> Signed-off-by: WANG Xuerui <git@xen0n.name>

This breaks testing, iirc, which is why both were accepted in the last change to this 
code.  You could allow just the short name so long as you don't try to provide the long 
name in hw/loongarch/virt.c.


r~


> ---
>   target/loongarch/cpu.c | 11 ++++-------
>   1 file changed, 4 insertions(+), 7 deletions(-)
> 
> diff --git a/target/loongarch/cpu.c b/target/loongarch/cpu.c
> index 941e2772bc..dc233ee209 100644
> --- a/target/loongarch/cpu.c
> +++ b/target/loongarch/cpu.c
> @@ -573,14 +573,11 @@ static ObjectClass *loongarch_cpu_class_by_name(const char *cpu_model)
>   {
>       ObjectClass *oc;
>   
> -    oc = object_class_by_name(cpu_model);
> +    g_autofree char *typename = g_strdup_printf(LOONGARCH_CPU_TYPE_NAME("%s"),
> +                                                cpu_model);
> +    oc = object_class_by_name(typename);
>       if (!oc) {
> -        g_autofree char *typename
> -            = g_strdup_printf(LOONGARCH_CPU_TYPE_NAME("%s"), cpu_model);
> -        oc = object_class_by_name(typename);
> -        if (!oc) {
> -            return NULL;
> -        }
> +        return NULL;
>       }
>   
>       if (object_class_dynamic_cast(oc, TYPE_LOONGARCH_CPU)

Re: [PATCH for-7.1 1/4] target/loongarch: Only allow short -cpu arguments without type name suffix

[Igor Mammedov]

On Sun, 14 Aug 2022 22:55:19 +0800
WANG Xuerui <i.qemu@xen0n.name> wrote:

> From: WANG Xuerui <git@xen0n.name>
> 
> Previously both "foo" and "foo-loongarch-cpu" are accepted for the -cpu
> command-line option, the latter of which being excessively long and
> redundant, hence unwanted. Remove support for consistency with other
> targets and simpler code.

to be consistent wit -device and other (qmp/monitor interfaces)
it's better to drop short variants (they are there mainly for compat
reasons) and use only long names (i.e. complete type name).

use avr_cpu_class_by_name() as an example

> 
> Signed-off-by: WANG Xuerui <git@xen0n.name>
> ---
>  target/loongarch/cpu.c | 11 ++++-------
>  1 file changed, 4 insertions(+), 7 deletions(-)
> 
> diff --git a/target/loongarch/cpu.c b/target/loongarch/cpu.c
> index 941e2772bc..dc233ee209 100644
> --- a/target/loongarch/cpu.c
> +++ b/target/loongarch/cpu.c
> @@ -573,14 +573,11 @@ static ObjectClass *loongarch_cpu_class_by_name(const char *cpu_model)
>  {
>      ObjectClass *oc;
>  
> -    oc = object_class_by_name(cpu_model);
> +    g_autofree char *typename = g_strdup_printf(LOONGARCH_CPU_TYPE_NAME("%s"),
> +                                                cpu_model);
> +    oc = object_class_by_name(typename);
>      if (!oc) {
> -        g_autofree char *typename 
> -            = g_strdup_printf(LOONGARCH_CPU_TYPE_NAME("%s"), cpu_model);
> -        oc = object_class_by_name(typename);
> -        if (!oc) {
> -            return NULL;
> -        }
> +        return NULL;
>      }
>  
>      if (object_class_dynamic_cast(oc, TYPE_LOONGARCH_CPU)

[PATCH for-7.1 2/4] target/loongarch: Trim type name suffix in -cpu help output

[WANG Xuerui]

From: WANG Xuerui <git@xen0n.name>

Also add a header and indentation for each entry, while at it.

Signed-off-by: WANG Xuerui <git@xen0n.name>
---
 target/loongarch/cpu.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/target/loongarch/cpu.c b/target/loongarch/cpu.c
index dc233ee209..4663539443 100644
--- a/target/loongarch/cpu.c
+++ b/target/loongarch/cpu.c
@@ -416,13 +416,15 @@ static void loongarch_la464_initfn(Object *obj)
 static void loongarch_cpu_list_entry(gpointer data, gpointer user_data)
 {
     const char *typename = object_class_get_name(OBJECT_CLASS(data));
+    int len = strlen(typename) - strlen(LOONGARCH_CPU_TYPE_SUFFIX);
 
-    qemu_printf("%s\n", typename);
+    qemu_printf("  %.*s\n", len, typename);
 }
 
 void loongarch_cpu_list(void)
 {
     GSList *list;
+    qemu_printf("Available CPUs:\n");
     list = object_class_get_list_sorted(TYPE_LOONGARCH_CPU, false);
     g_slist_foreach(list, loongarch_cpu_list_entry, NULL);
     g_slist_free(list);
-- 
2.35.1

Re: [PATCH for-7.1 2/4] target/loongarch: Trim type name suffix in -cpu help output

[Richard Henderson]

On 8/14/22 09:55, WANG Xuerui wrote:
> From: WANG Xuerui <git@xen0n.name>
> 
> Also add a header and indentation for each entry, while at it.
> 
> Signed-off-by: WANG Xuerui <git@xen0n.name>
> ---
>   target/loongarch/cpu.c | 4 +++-
>   1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/target/loongarch/cpu.c b/target/loongarch/cpu.c
> index dc233ee209..4663539443 100644
> --- a/target/loongarch/cpu.c
> +++ b/target/loongarch/cpu.c
> @@ -416,13 +416,15 @@ static void loongarch_la464_initfn(Object *obj)
>   static void loongarch_cpu_list_entry(gpointer data, gpointer user_data)
>   {
>       const char *typename = object_class_get_name(OBJECT_CLASS(data));
> +    int len = strlen(typename) - strlen(LOONGARCH_CPU_TYPE_SUFFIX);
>   
> -    qemu_printf("%s\n", typename);
> +    qemu_printf("  %.*s\n", len, typename);
>   }
>   
>   void loongarch_cpu_list(void)
>   {
>       GSList *list;
> +    qemu_printf("Available CPUs:\n");
>       list = object_class_get_list_sorted(TYPE_LOONGARCH_CPU, false);
>       g_slist_foreach(list, loongarch_cpu_list_entry, NULL);
>       g_slist_free(list);

This should be merged with the previous patch, so that we don't have an intermediate state 
where help and loongarch_cpu_class_by_name disagree.


r~

[PATCH for-7.1 3/4] target/loongarch: rename the TCG CPU "la464" to "qemu64-v1.00"

[WANG Xuerui]

From: WANG Xuerui <git@xen0n.name>

The only LoongArch CPU implemented is modeled after the Loongson 3A5000,
but it is not the real thing, and at least one feature [1] is missing
that actually made the model incompatible with the real 3A5000. What's
more, the model is currently named "la464", while none of the
micro-architecture-specific things are currently present, further making
things needlessly complex.

In general, high-fidelity models can and should be named after the real
hardware model, while generic emulation-oriented models should be named
after ISA levels. For now, the best reference for LoongArch ISA levels
is the revision number of the LoongArch ISA Manual, of which v1.00 is
still the latest. (v1.01 and v1.02 are minor revisions without
substantive change.)

As defined by various specs, the vendor and model names are also
reflected in respective CSRs, and are 8 bytes long. So, rename "la464"
to "qemu64-v1.00", with "QEMU64" as vendor name and "v1.00" as model
name.

As the QEMU 7.1 hasn't been officially released, no downstream is
expected to depend on the old name, so this change should be safe for
7.1.

[1]: https://lore.kernel.org/loongarch/20220726094049.7200-2-maobibo@loongson.cn/

Signed-off-by: WANG Xuerui <git@xen0n.name>
---
 hw/loongarch/virt.c    | 14 ++------------
 target/loongarch/cpu.c |  6 +++---
 2 files changed, 5 insertions(+), 15 deletions(-)

diff --git a/hw/loongarch/virt.c b/hw/loongarch/virt.c
index 5cc0b05538..35e2174a17 100644
--- a/hw/loongarch/virt.c
+++ b/hw/loongarch/virt.c
@@ -626,7 +626,6 @@ static void loongarch_direct_kernel_boot(LoongArchMachineState *lams)
 static void loongarch_init(MachineState *machine)
 {
     LoongArchCPU *lacpu;
-    const char *cpu_model = machine->cpu_type;
     ram_addr_t offset = 0;
     ram_addr_t ram_size = machine->ram_size;
     uint64_t highram_size = 0;
@@ -634,15 +633,6 @@ static void loongarch_init(MachineState *machine)
     LoongArchMachineState *lams = LOONGARCH_MACHINE(machine);
     int i;
 
-    if (!cpu_model) {
-        cpu_model = LOONGARCH_CPU_TYPE_NAME("la464");
-    }
-
-    if (!strstr(cpu_model, "la464")) {
-        error_report("LoongArch/TCG needs cpu type la464");
-        exit(1);
-    }
-
     if (ram_size < 1 * GiB) {
         error_report("ram_size must be greater than 1G.");
         exit(1);
@@ -749,10 +739,10 @@ static void loongarch_class_init(ObjectClass *oc, void *data)
 {
     MachineClass *mc = MACHINE_CLASS(oc);
 
-    mc->desc = "Loongson-3A5000 LS7A1000 machine";
+    mc->desc = "LoongArch64 v1.00-compatible LS7A1000 machine";
     mc->init = loongarch_init;
     mc->default_ram_size = 1 * GiB;
-    mc->default_cpu_type = LOONGARCH_CPU_TYPE_NAME("la464");
+    mc->default_cpu_type = LOONGARCH_CPU_TYPE_NAME("qemu64-v1.00");
     mc->default_ram_id = "loongarch.ram";
     mc->max_cpus = LOONGARCH_MAX_VCPUS;
     mc->is_default = 1;
diff --git a/target/loongarch/cpu.c b/target/loongarch/cpu.c
index 4663539443..0a41509a0c 100644
--- a/target/loongarch/cpu.c
+++ b/target/loongarch/cpu.c
@@ -527,9 +527,9 @@ static uint64_t loongarch_qemu_read(void *opaque, hwaddr addr, unsigned size)
         return 1ULL << IOCSRF_MSI | 1ULL << IOCSRF_EXTIOI |
                1ULL << IOCSRF_CSRIPI;
     case VENDOR_REG:
-        return 0x6e6f73676e6f6f4cULL; /* "Loongson" */
+        return 0x3436554d4551ULL; /* "QEMU64" */
     case CPUNAME_REG:
-        return 0x303030354133ULL;     /* "3A5000" */
+        return 0x30302e3176ULL;   /* "v1.00" */
     case MISC_FUNC_REG:
         return 1ULL << IOCSRM_EXTIOI_EN;
     }
@@ -715,7 +715,7 @@ static const TypeInfo loongarch_cpu_type_infos[] = {
         .class_size = sizeof(LoongArchCPUClass),
         .class_init = loongarch_cpu_class_init,
     },
-    DEFINE_LOONGARCH_CPU_TYPE("la464", loongarch_la464_initfn),
+    DEFINE_LOONGARCH_CPU_TYPE("qemu64-v1.00", loongarch_la464_initfn),
 };
 
 DEFINE_TYPES(loongarch_cpu_type_infos)
-- 
2.35.1

Re: [PATCH for-7.1 3/4] target/loongarch: rename the TCG CPU "la464" to "qemu64-v1.00"

[Richard Henderson]

On 8/14/22 09:55, WANG Xuerui wrote:
> From: WANG Xuerui <git@xen0n.name>
> 
> The only LoongArch CPU implemented is modeled after the Loongson 3A5000,
> but it is not the real thing, ...

The 3A5000 is the SoC, as far as I could find, and the documentation of that says the core 
is named the la464.


> In general, high-fidelity models can and should be named after the real
> hardware model, while generic emulation-oriented models should be named
> after ISA levels.

This wasn't intended to be a generic emulation model, as far as I know.  There are missing 
features, but presumably those would eventually be filled in.


> For now, the best reference for LoongArch ISA levels
> is the revision number of the LoongArch ISA Manual, of which v1.00 is
> still the latest. (v1.01 and v1.02 are minor revisions without
> substantive change.)
> 
> As defined by various specs, the vendor and model names are also
> reflected in respective CSRs, and are 8 bytes long. So, rename "la464"
> to "qemu64-v1.00", with "QEMU64" as vendor name and "v1.00" as model
> name.

Eh, I suppose.  I'm not really keen on this though, as I would presume there will be 
eventual forward progress on completing the real cpu model.  We simply won't give any 
compatibility guarantees for loongarch until we are ready to do so.


r~

Re: [PATCH for-7.1 3/4] target/loongarch: rename the TCG CPU "la464" to "qemu64-v1.00"

[chen huacai]

Hi, Richard and Xuerui,

On Mon, Aug 15, 2022 at 4:54 AM Richard Henderson
<richard.henderson@linaro.org> wrote:
>
> On 8/14/22 09:55, WANG Xuerui wrote:
> > From: WANG Xuerui <git@xen0n.name>
> >
> > The only LoongArch CPU implemented is modeled after the Loongson 3A5000,
> > but it is not the real thing, ...
>
> The 3A5000 is the SoC, as far as I could find, and the documentation of that says the core
> is named the la464.
>
>
> > In general, high-fidelity models can and should be named after the real
> > hardware model, while generic emulation-oriented models should be named
> > after ISA levels.
>
> This wasn't intended to be a generic emulation model, as far as I know.  There are missing
> features, but presumably those would eventually be filled in.
>
>
> > For now, the best reference for LoongArch ISA levels
> > is the revision number of the LoongArch ISA Manual, of which v1.00 is
> > still the latest. (v1.01 and v1.02 are minor revisions without
> > substantive change.)
> >
> > As defined by various specs, the vendor and model names are also
> > reflected in respective CSRs, and are 8 bytes long. So, rename "la464"
> > to "qemu64-v1.00", with "QEMU64" as vendor name and "v1.00" as model
> > name.
>
> Eh, I suppose.  I'm not really keen on this though, as I would presume there will be
> eventual forward progress on completing the real cpu model.  We simply won't give any
> compatibility guarantees for loongarch until we are ready to do so.
In my opinion, real cpu name (Loongson-3A5000, Loongson-3A6000, etc.)
and generic qemu emulated name (qemu64-v1.00, qemu64-v2.00, vx.xx is
the ISA level, I found this style is used for x86) are both
acceptable. But la464 is not a good cpu name, because la264 and la464
are in the same ISA level, while la664 will be in a new level.

Huacai

>
>
> r~
>


-- 
Huacai Chen

Re: [PATCH for-7.1 3/4] target/loongarch: rename the TCG CPU "la464" to "qemu64-v1.00"

[gaosong]

在 2022/8/17 上午10:36, chen huacai 写道:
> Hi, Richard and Xuerui,
>
> On Mon, Aug 15, 2022 at 4:54 AM Richard Henderson
> <richard.henderson@linaro.org> wrote:
>> On 8/14/22 09:55, WANG Xuerui wrote:
>>> From: WANG Xuerui <git@xen0n.name>
>>>
>>> The only LoongArch CPU implemented is modeled after the Loongson 3A5000,
>>> but it is not the real thing, ...
>> The 3A5000 is the SoC, as far as I could find, and the documentation of that says the core
>> is named the la464.
>>
>>
>>> In general, high-fidelity models can and should be named after the real
>>> hardware model, while generic emulation-oriented models should be named
>>> after ISA levels.
>> This wasn't intended to be a generic emulation model, as far as I know.  There are missing
>> features, but presumably those would eventually be filled in.
>>
>>
>>> For now, the best reference for LoongArch ISA levels
>>> is the revision number of the LoongArch ISA Manual, of which v1.00 is
>>> still the latest. (v1.01 and v1.02 are minor revisions without
>>> substantive change.)
>>>
>>> As defined by various specs, the vendor and model names are also
>>> reflected in respective CSRs, and are 8 bytes long. So, rename "la464"
>>> to "qemu64-v1.00", with "QEMU64" as vendor name and "v1.00" as model
>>> name.
>> Eh, I suppose.  I'm not really keen on this though, as I would presume there will be
>> eventual forward progress on completing the real cpu model.  We simply won't give any
>> compatibility guarantees for loongarch until we are ready to do so.
> In my opinion, real cpu name (Loongson-3A5000, Loongson-3A6000, etc.)
> and generic qemu emulated name (qemu64-v1.00, qemu64-v2.00, vx.xx is
> the ISA level, I found this style is used for x86) are both
> acceptable. But la464 is not a good cpu name, because la264 and la464
> are in the same ISA level, while la664 will be in a new level.
I think that 'la264' , 'la464' and 'la664'  are  cpu core name. used 
them as cpu type is more suitable.
Although la264 and la464 are in the same ISA level,   but the features 
should be different.

Thanks.
Song Gao
> Huacai
>
>>
>> r~
>>
>

Re: [PATCH for-7.1 3/4] target/loongarch: rename the TCG CPU "la464" to "qemu64-v1.00"

[WANG Xuerui]

On 2022/8/17 16:11, gaosong wrote:
>
> 在 2022/8/17 上午10:36, chen huacai 写道:
>> Hi, Richard and Xuerui,
>>
>> On Mon, Aug 15, 2022 at 4:54 AM Richard Henderson
>> <richard.henderson@linaro.org> wrote:
>>> On 8/14/22 09:55, WANG Xuerui wrote:
>>>> From: WANG Xuerui <git@xen0n.name>
>>>>
>>>> The only LoongArch CPU implemented is modeled after the Loongson 
>>>> 3A5000,
>>>> but it is not the real thing, ...
>>> The 3A5000 is the SoC, as far as I could find, and the documentation 
>>> of that says the core
>>> is named the la464.
>>>
>>>
>>>> In general, high-fidelity models can and should be named after the 
>>>> real
>>>> hardware model, while generic emulation-oriented models should be 
>>>> named
>>>> after ISA levels.
>>> This wasn't intended to be a generic emulation model, as far as I 
>>> know.  There are missing
>>> features, but presumably those would eventually be filled in.
>>>
>>>
>>>> For now, the best reference for LoongArch ISA levels
>>>> is the revision number of the LoongArch ISA Manual, of which v1.00 is
>>>> still the latest. (v1.01 and v1.02 are minor revisions without
>>>> substantive change.)
>>>>
>>>> As defined by various specs, the vendor and model names are also
>>>> reflected in respective CSRs, and are 8 bytes long. So, rename "la464"
>>>> to "qemu64-v1.00", with "QEMU64" as vendor name and "v1.00" as model
>>>> name.
>>> Eh, I suppose.  I'm not really keen on this though, as I would 
>>> presume there will be
>>> eventual forward progress on completing the real cpu model. We 
>>> simply won't give any
>>> compatibility guarantees for loongarch until we are ready to do so.
>> In my opinion, real cpu name (Loongson-3A5000, Loongson-3A6000, etc.)
>> and generic qemu emulated name (qemu64-v1.00, qemu64-v2.00, vx.xx is
>> the ISA level, I found this style is used for x86) are both
>> acceptable. But la464 is not a good cpu name, because la264 and la464
>> are in the same ISA level, while la664 will be in a new level.
> I think that 'la264' , 'la464' and 'la664'  are  cpu core name. used 
> them as cpu type is more suitable.
> Although la264 and la464 are in the same ISA level,   but the features 
> should be different.

 From my own experiences, different use cases care about different 
aspects of the CPU, and that IMO is an argument in favor of providing 
both (high-fidelity models named after actual product model names, and 
virtual models named after ISA levels). But before we have truly 
high-fidelity models I think we should start with the virtual ones 
first. And don't pretend the currently implemented model is LA464 -- the 
kernel change I've linked to [1] implies the opposite.

If you're emulating certain boards to test kernels/drivers or similar 
things, it could help to be able to specify exact CPU models and/or 
machine type. However, for the linux-user case, it is almost always the 
ISA level that actually matters, and I don't think LA264/LA364/LA464 are 
going to differ w.r.t. unprivileged instruction behavior. Having to 
choose an overly specific model for a broad ISA level match seems 
inappropriate to my aesthetic sense.

[1]: 
https://github.com/torvalds/linux/commit/71610ab1d017e131a9888ef8acd035284fb0e1dd

Re: [PATCH for-7.1 3/4] target/loongarch: rename the TCG CPU "la464" to "qemu64-v1.00"

[Richard Henderson]

On 8/17/22 04:10, WANG Xuerui wrote:
>  From my own experiences, different use cases care about different aspects of the CPU, and 
> that IMO is an argument in favor of providing both (high-fidelity models named after 
> actual product model names, and virtual models named after ISA levels). But before we have 
> truly high-fidelity models I think we should start with the virtual ones first. And don't 
> pretend the currently implemented model is LA464 -- the kernel change I've linked to [1] 
> implies the opposite.

No, it simply pointed to a bug in qemu that could have been fixed.

The trouble with inventing virtual models is that no one knows what they mean.  Targeting 
real hardware is better, because we have a documented standard.


r~

Re: [PATCH for-7.1 3/4] target/loongarch: rename the TCG CPU "la464" to "qemu64-v1.00"

[WANG Xuerui]

On 2022/8/17 21:26, Richard Henderson wrote:
> On 8/17/22 04:10, WANG Xuerui wrote:
>>  From my own experiences, different use cases care about different 
>> aspects of the CPU, and that IMO is an argument in favor of providing 
>> both (high-fidelity models named after actual product model names, 
>> and virtual models named after ISA levels). But before we have truly 
>> high-fidelity models I think we should start with the virtual ones 
>> first. And don't pretend the currently implemented model is LA464 -- 
>> the kernel change I've linked to [1] implies the opposite.
>
> No, it simply pointed to a bug in qemu that could have been fixed.
>
> The trouble with inventing virtual models is that no one knows what 
> they mean.  Targeting real hardware is better, because we have a 
> documented standard.
>
Hmm, I've looked up more context and it is indeed reasonable to 
generally name the QEMU models after real existing models. But in this 
case we could face a problem with Loongson's nomenclature: all of 
Loongson 3A5000, 3C5000 and 3C5000L are LA464, yet they should be 
distinguishable software-side by checking the model name CSR. But with 
only one CPU model that is LA464, currently this CSR is hard-coded to 
read "3A5000", and this can hurt IMO. And when we finally add LA264 and 
LA364 they would be identical ISA-level-wise, again the only 
differentiator is the model name CSR.

And by "not high-fidelity", I mean some of the features present on real 
HW might never get implemented, or actually implementable, like the DVFS 
mechanism needed by cpufreq. And I believe Bibo wouldn't have to change 
the kernel if it's not needed after all to run the unmodified upstream 
kernel on top of qemu-system-loongarch64. (I would of course accept, and 
learn something along the way, if this turns out not to be the case though.)

Lastly, the "ISA level" I proposed is not arbitrarily made up; it's 
direct reference to the ISA manual revision. Each time the ISA gets some 
addition/revision the ISA manual has to be updated, and currently the 
manual's revision is the only reliable source of said information. 
(Loongson has a history of naming cores badly, like with the MIPS 3B1500 
and 3A4000, both were "GS464V"; and 3A5000 was originally GS464V too, 
even though the insn encodings and some semantics have been entirely 
different.)

In conclusion, I'd accept the micro-architecture naming if the model CSR 
behavior could be sorted out, otherwise I'd personally prefer real model 
names if ISA level naming is not going to fly. This is not a strong 
objection to the current way of doing things though, more like some 
minor but anyway needed discussion that happened a bit late. Sorry for 
not chiming in earlier during the review process.

Re: [PATCH for-7.1 3/4] target/loongarch: rename the TCG CPU "la464" to "qemu64-v1.00"

[maobibo]

在 2022/8/18 10:31, WANG Xuerui 写道:
> On 2022/8/17 21:26, Richard Henderson wrote:
>> On 8/17/22 04:10, WANG Xuerui wrote:
>>>  From my own experiences, different use cases care about different aspects of the CPU, and that IMO is an argument in favor of providing both (high-fidelity models named after actual product model names, and virtual models named after ISA levels). But before we have truly high-fidelity models I think we should start with the virtual ones first. And don't pretend the currently implemented model is LA464 -- the kernel change I've linked to [1] implies the opposite.
>>
>> No, it simply pointed to a bug in qemu that could have been fixed.
>>
>> The trouble with inventing virtual models is that no one knows what they mean.  Targeting real hardware is better, because we have a documented standard.
>>
> Hmm, I've looked up more context and it is indeed reasonable to generally name the QEMU models after real existing models. But in this case we could face a problem with Loongson's nomenclature: all of Loongson 3A5000, 3C5000 and 3C5000L are LA464, yet they should be distinguishable software-side by checking the model name CSR. But with only one CPU model that is LA464, currently this CSR is hard-coded to read "3A5000", and this can hurt IMO. And when we finally add LA264 and LA364 they would be identical ISA-level-wise, again the only differentiator is the model name CSR.
We will add LA264 later, there are some small different features with LA464, such as virtual/physical address width, unaligned address access, vector fpu width etc.
 

> And by "not high-fidelity", I mean some of the features present on real HW might never get implemented, or actually implementable, like the DVFS mechanism needed by cpufreq. And I believe Bibo wouldn't have to change the kernel if it's not needed after all to run the unmodified upstream kernel on top of qemu-system-loongarch64. (I would of course accept, and learn something along the way, if this turns out not to be the case though.)
qemu does not emulation actual voltage/freq function,  cpu freq 2000MHZ in qemu is not real freq, it is only function emulation rather than timing emulation.

regards
bibo,mao 

> Lastly, the "ISA level" I proposed is not arbitrarily made up; it's direct reference to the ISA manual revision. Each time the ISA gets some addition/revision the ISA manual has to be updated, and currently the manual's revision is the only reliable source of said information. (Loongson has a history of naming cores badly, like with the MIPS 3B1500 and 3A4000, both were "GS464V"; and 3A5000 was originally GS464V too, even though the insn encodings and some semantics have been entirely different.)
> 
> In conclusion, I'd accept the micro-architecture naming if the model CSR behavior could be sorted out, otherwise I'd personally prefer real model names if ISA level naming is not going to fly. This is not a strong objection to the current way of doing things though, more like some minor but anyway needed discussion that happened a bit late. Sorry for not chiming in earlier during the review process.

Re: [PATCH for-7.1 3/4] target/loongarch: rename the TCG CPU "la464" to "qemu64-v1.00"

[Richard Henderson]

On 8/17/22 19:31, WANG Xuerui wrote:
> Hmm, I've looked up more context and it is indeed reasonable to generally name the QEMU 
> models after real existing models. But in this case we could face a problem with 
> Loongson's nomenclature: all of Loongson 3A5000, 3C5000 and 3C5000L are LA464, yet they 
> should be distinguishable software-side by checking the model name CSR. But with only one 
> CPU model that is LA464, currently this CSR is hard-coded to read "3A5000", and this can 
> hurt IMO. And when we finally add LA264 and LA364 they would be identical ISA-level-wise, 
> again the only differentiator is the model name CSR.

Indeed, I believe that I pointed this out during review, and asked for loongarch_qemu_read 
to be moved.  But apparently I missed it the next time around, and it snuck in.  There's 
nothing in that memory region that is related to the core.


> And by "not high-fidelity", I mean some of the features present on real HW might never get 
> implemented, or actually implementable, like the DVFS mechanism needed by cpufreq.

Certainly we can add stub versions of any such registers.  Such things are extremely 
common under target/arm/.

> Lastly, the "ISA level" I proposed is not arbitrarily made up; it's direct reference to 
> the ISA manual revision. Each time the ISA gets some addition/revision the ISA manual has 
> to be updated, and currently the manual's revision is the only reliable source of said 
> information. (Loongson has a history of naming cores badly, like with the MIPS 3B1500 and 
> 3A4000, both were "GS464V"; and 3A5000 was originally GS464V too, even though the insn 
> encodings and some semantics have been entirely different.)

That is a good argument for your isa level scheme, at least as aliases.


r~

Re: [PATCH for-7.1 3/4] target/loongarch: rename the TCG CPU "la464" to "qemu64-v1.00"

[maobibo]

QEMU64 cpu model can be added, however la464 cpu model should be kept here
still. Actually there is no formal micro-achitecture name for loongarch, I
prefer to la464 still :)

Also host cpu model can be added later, which has the same features with
host processor. What is meaning for QEMU64/KVM64 cpu model? Does it mean
that minimum required CPU features for current popular OSV?

regards
bibo,mao


在 2022/8/14 22:55, WANG Xuerui 写道:
> From: WANG Xuerui <git@xen0n.name>
> 
> The only LoongArch CPU implemented is modeled after the Loongson 3A5000,
> but it is not the real thing, and at least one feature [1] is missing
> that actually made the model incompatible with the real 3A5000. What's
> more, the model is currently named "la464", while none of the
> micro-architecture-specific things are currently present, further making
> things needlessly complex.
> 
> In general, high-fidelity models can and should be named after the real
> hardware model, while generic emulation-oriented models should be named
> after ISA levels. For now, the best reference for LoongArch ISA levels
> is the revision number of the LoongArch ISA Manual, of which v1.00 is
> still the latest. (v1.01 and v1.02 are minor revisions without
> substantive change.)
> 
> As defined by various specs, the vendor and model names are also
> reflected in respective CSRs, and are 8 bytes long. So, rename "la464"
> to "qemu64-v1.00", with "QEMU64" as vendor name and "v1.00" as model
> name.
> 
> As the QEMU 7.1 hasn't been officially released, no downstream is
> expected to depend on the old name, so this change should be safe for
> 7.1.
> 
> [1]: https://lore.kernel.org/loongarch/20220726094049.7200-2-maobibo@loongson.cn/
> 
> Signed-off-by: WANG Xuerui <git@xen0n.name>
> ---
>  hw/loongarch/virt.c    | 14 ++------------
>  target/loongarch/cpu.c |  6 +++---
>  2 files changed, 5 insertions(+), 15 deletions(-)
> 
> diff --git a/hw/loongarch/virt.c b/hw/loongarch/virt.c
> index 5cc0b05538..35e2174a17 100644
> --- a/hw/loongarch/virt.c
> +++ b/hw/loongarch/virt.c
> @@ -626,7 +626,6 @@ static void loongarch_direct_kernel_boot(LoongArchMachineState *lams)
>  static void loongarch_init(MachineState *machine)
>  {
>      LoongArchCPU *lacpu;
> -    const char *cpu_model = machine->cpu_type;
>      ram_addr_t offset = 0;
>      ram_addr_t ram_size = machine->ram_size;
>      uint64_t highram_size = 0;
> @@ -634,15 +633,6 @@ static void loongarch_init(MachineState *machine)
>      LoongArchMachineState *lams = LOONGARCH_MACHINE(machine);
>      int i;
>  
> -    if (!cpu_model) {
> -        cpu_model = LOONGARCH_CPU_TYPE_NAME("la464");
> -    }
> -
> -    if (!strstr(cpu_model, "la464")) {
> -        error_report("LoongArch/TCG needs cpu type la464");
> -        exit(1);
> -    }
> -
>      if (ram_size < 1 * GiB) {
>          error_report("ram_size must be greater than 1G.");
>          exit(1);
> @@ -749,10 +739,10 @@ static void loongarch_class_init(ObjectClass *oc, void *data)
>  {
>      MachineClass *mc = MACHINE_CLASS(oc);
>  
> -    mc->desc = "Loongson-3A5000 LS7A1000 machine";
> +    mc->desc = "LoongArch64 v1.00-compatible LS7A1000 machine";
>      mc->init = loongarch_init;
>      mc->default_ram_size = 1 * GiB;
> -    mc->default_cpu_type = LOONGARCH_CPU_TYPE_NAME("la464");
> +    mc->default_cpu_type = LOONGARCH_CPU_TYPE_NAME("qemu64-v1.00");
>      mc->default_ram_id = "loongarch.ram";
>      mc->max_cpus = LOONGARCH_MAX_VCPUS;
>      mc->is_default = 1;
> diff --git a/target/loongarch/cpu.c b/target/loongarch/cpu.c
> index 4663539443..0a41509a0c 100644
> --- a/target/loongarch/cpu.c
> +++ b/target/loongarch/cpu.c
> @@ -527,9 +527,9 @@ static uint64_t loongarch_qemu_read(void *opaque, hwaddr addr, unsigned size)
>          return 1ULL << IOCSRF_MSI | 1ULL << IOCSRF_EXTIOI |
>                 1ULL << IOCSRF_CSRIPI;
>      case VENDOR_REG:
> -        return 0x6e6f73676e6f6f4cULL; /* "Loongson" */
> +        return 0x3436554d4551ULL; /* "QEMU64" */
>      case CPUNAME_REG:
> -        return 0x303030354133ULL;     /* "3A5000" */
> +        return 0x30302e3176ULL;   /* "v1.00" */
>      case MISC_FUNC_REG:
>          return 1ULL << IOCSRM_EXTIOI_EN;
>      }
> @@ -715,7 +715,7 @@ static const TypeInfo loongarch_cpu_type_infos[] = {
>          .class_size = sizeof(LoongArchCPUClass),
>          .class_init = loongarch_cpu_class_init,
>      },
> -    DEFINE_LOONGARCH_CPU_TYPE("la464", loongarch_la464_initfn),
> +    DEFINE_LOONGARCH_CPU_TYPE("qemu64-v1.00", loongarch_la464_initfn),
>  };
>  
>  DEFINE_TYPES(loongarch_cpu_type_infos)

[PATCH for-7.1 4/4] docs, target/loongarch: Rewrite the LoongArch docs

[WANG Xuerui]

From: WANG Xuerui <git@xen0n.name>

Much information is already outdated in its current form, not to mention
the hard-to-understand Chinglish. Rewrite to hopefully de-duplicate and
re-organize things, and reflect the latest status of LoongArch at
upstream.

Signed-off-by: WANG Xuerui <git@xen0n.name>
---
 docs/system/loongarch/loongson3.rst | 41 ------------
 docs/system/loongarch/virt.rst      | 41 ++++++++++++
 target/loongarch/README             | 99 -----------------------------
 target/loongarch/README.md          | 75 ++++++++++++++++++++++
 4 files changed, 116 insertions(+), 140 deletions(-)
 delete mode 100644 docs/system/loongarch/loongson3.rst
 create mode 100644 docs/system/loongarch/virt.rst
 delete mode 100644 target/loongarch/README
 create mode 100644 target/loongarch/README.md

diff --git a/docs/system/loongarch/loongson3.rst b/docs/system/loongarch/loongson3.rst
deleted file mode 100644
index fa3acd01c0..0000000000
--- a/docs/system/loongarch/loongson3.rst
+++ /dev/null
@@ -1,41 +0,0 @@
-:orphan:
-
-==========================================
-loongson3 virt generic platform (``virt``)
-==========================================
-
-The ``virt`` machine use gpex host bridge, and there are some
-emulated devices on virt board, such as loongson7a RTC device,
-IOAPIC device, ACPI device and so on.
-
-Supported devices
------------------
-
-The ``virt`` machine supports:
-- Gpex host bridge
-- Ls7a RTC device
-- Ls7a IOAPIC device
-- Ls7a ACPI device
-- Fw_cfg device
-- PCI/PCIe devices
-- Memory device
-- CPU device. Type: Loongson-3A5000.
-
-CPU and machine Type
---------------------
-
-The ``qemu-system-loongarch64`` provides emulation for virt
-machine. You can specify the machine type ``virt`` and
-cpu type ``Loongson-3A5000``.
-
-Boot options
-------------
-
-Now the ``virt`` machine can run test program in ELF format and the
-method of compiling is in target/loongarch/README.
-
-.. code-block:: bash
-
-  $ qemu-system-loongarch64 -machine virt -m 4G -cpu Loongson-3A5000 \
-      -smp 1 -kernel hello -monitor none -display none \
-      -chardev file,path=hello.out,id=output -serial chardev:output
diff --git a/docs/system/loongarch/virt.rst b/docs/system/loongarch/virt.rst
new file mode 100644
index 0000000000..2d8f7e1db5
--- /dev/null
+++ b/docs/system/loongarch/virt.rst
@@ -0,0 +1,41 @@
+:orphan:
+
+=================================================
+LoongArch generic virtualized platform (``virt``)
+=================================================
+
+The ``virt`` machine has a GPEX host bridge, and some more emulated devices
+such as the LS7A RTC, IOAPIC, ACPI device and so on.
+
+Being a machine type designed for virtualized use cases, the machine resembles
+a Loongson 3A5000 + LS7A1000 board, but is not an exact emulation.
+For example, only cascading of the EXTIOI interrupt is implemented.
+Also, only the RTC block of the LS7A1000 is emulated; for the other devices
+the QEMU models are used.
+Normally you do not need to care about any of these.
+
+Supported devices
+-----------------
+
+The ``virt`` machine supports:
+
+- GPEX host bridge
+- LS7A RTC device
+- LS7A IOAPIC device
+- LS7A ACPI device
+- fw_cfg device
+- PCI/PCIe devices
+- Memory device
+- CPU device. Defaults to ``qemu64-v1.00``.
+
+Boot options
+------------
+
+Some more information could be found in the QEMU sources at
+``target/loongarch/README.md``. A simple example being:
+
+.. code-block:: bash
+
+  $ qemu-system-loongarch64 -machine virt -m 4G -smp 1 -kernel hello \
+      -monitor none -display none \
+      -chardev file,path=hello.out,id=output -serial chardev:output
diff --git a/target/loongarch/README b/target/loongarch/README
deleted file mode 100644
index 1823375d04..0000000000
--- a/target/loongarch/README
+++ /dev/null
@@ -1,99 +0,0 @@
-- Introduction
-
-  LoongArch is the general processor architecture of Loongson.
-
-  The following versions of the LoongArch core are supported
-    core: 3A5000
-    https://github.com/loongson/LoongArch-Documentation/releases/download/2021.08.17/LoongArch-Vol1-v1.00-EN.pdf
-
-  We can get the latest loongarch documents at https://github.com/loongson/LoongArch-Documentation/tags.
-
-
-- System emulation
-
-  Mainly emulate a virt 3A5000 board and ls7a bridge that is not exactly the same as the host.
-  3A5000 support multiple interrupt cascading while here we just emulate the extioi interrupt
-  cascading. LS7A1000 host bridge support multiple devices, such as sata, gmac, uart, rtc
-  and so on. But we just realize the rtc. Others use the qemu common devices. It does not affect
-  the general use. We also introduced the emulation of devices at docs/system/loongarch/virt.rst.
-
-  This version only supports running binary files in ELF format, and does not depend on BIOS and kernel file.
-  You can compile the test program with 'make & make check-tcg' and run the test case with the following command:
-
-  1. Install LoongArch cross-tools on X86 machines.
-
-    Download cross-tools.
-
-      wget https://github.com/loongson/build-tools/releases/download/2022.05.29/loongarch64-clfs-5.0-cross-tools-gcc-full.tar.xz
-
-      tar -vxf loongarch64-clfs-5.0-cross-tools-gcc-full.tar.xz -C /opt
-
-    Config cross-tools env.
-
-      . setenv.sh
-
-      setenv.sh:
-
-          #!/bin/sh
-          set -x
-          CC_PREFIX=/opt/cross-tools
-
-          export PATH=$CC_PREFIX/bin:$PATH
-          export LD_LIBRARY_PATH=$CC_PREFIX/lib:$LD_LIBRARY_PATH
-          export LD_LIBRARY_PATH=$CC_PREFIX/loongarch64-unknown-linux-gnu/lib/:$LD_LIBRARY_PATH
-          set +x
-
-  2. Test tests/tcg/multiarch.
-
-    ./configure --disable-rdma --disable-pvrdma --prefix=/usr  \
-            --target-list="loongarch64-softmmu"  \
-            --disable-libiscsi --disable-libnfs --disable-libpmem \
-            --disable-glusterfs --enable-libusb --enable-usb-redir \
-            --disable-opengl --disable-xen --enable-spice --disable-werror \
-            --enable-debug --disable-capstone --disable-kvm --enable-profiler
-
-    cd  build/
-
-    make && make check-tcg
-
-    or
-
-    ./build/qemu-system-loongarch64 -machine virt -m 4G -cpu Loongson-3A5000 -smp 1 -kernel build/tests/tcg/loongarch64-softmmu/hello -monitor none -display none -chardev file,path=hello.out,id=output -serial chardev:output
-
-- Linux-user emulation
-
-  We already support Linux user emulation. We can use LoongArch cross-tools to build LoongArch executables on X86 machines,
-  and We can also use qemu-loongarch64 to run LoongArch executables.
-
-  1. Config cross-tools env.
-
-     see System emulation.
-
-  2. Test tests/tcg/multiarch.
-
-     ./configure  --static  --prefix=/usr  --disable-werror --target-list="loongarch64-linux-user" --enable-debug
-
-     cd build
-
-     make && make check-tcg
-
-  3. Run LoongArch system basic command with loongarch-clfs-system.
-
-     - Config clfs env.
-
-       wget https://github.com/loongson/build-tools/releases/download/2022.05.29/loongarch64-clfs-system-5.0.tar.bz2
-
-       tar -vxf loongarch64-clfs-system-5.0.tar.bz2 -C /opt/clfs
-
-       cp /opt/clfs/lib64/ld-linux-loongarch-lp64d.so.1  /lib64
-
-       export LD_LIBRARY_PATH="/opt/clfs/lib64"
-
-     - Run LoongArch system basic command.
-
-       ./qemu-loongarch64  /opt/clfs/usr/bin/bash
-       ./qemu-loongarch64  /opt/clfs/usr/bin/ls
-       ./qemu-loongarch64  /opt/clfs/usr/bin/pwd
-
-- Note.
-  We can get the latest LoongArch documents or LoongArch tools at https://github.com/loongson/
diff --git a/target/loongarch/README.md b/target/loongarch/README.md
new file mode 100644
index 0000000000..6a5ff8acd5
--- /dev/null
+++ b/target/loongarch/README.md
@@ -0,0 +1,75 @@
+# QEMU LoongArch target
+
+## Introduction
+
+LoongArch is the general-purpose instruction set architecture developed by
+Loongson. Documentation can be found at [the LoongArch Documentation repository][docs-repo].
+
+[docs-repo]: https://github.com/loongson/LoongArch-Documentation
+
+Currently the following CPU models are supported:
+
+|`-cpu name`|Description|
+|:----------|:----------|
+|`qemu64-v1.00`|Virtual model similar to the Loongson 3A5000, compatible with LoongArch64 v1.00.|
+
+## Trying out
+
+For some of the steps or development/debug purposes, you may have to set up
+cross toolchains if you are not running on native LoongArch hardware.
+
+Now that LoongArch support has been merged in the GNU toolchain packages and
+Linux, you may make your own toolchains like with any other architectures;
+Loongson also has made available [their pre-compiled toolchain binaries for x86][build-tools].
+You may follow the respective instructions to set up your development
+environment.
+
+[build-tools]: https://github.com/loongson/build-tools
+
+### System emulation
+
+Both raw ELF images and EFI stub kernels together with UEFI firmware image are
+supported.
+
+For running raw ELF images with system emulation:
+
+```sh
+# In the build directory:
+./qemu-system-loongarch64 -m 4G -smp 1 \
+    -kernel build/tests/tcg/loongarch64-softmmu/hello \
+    -monitor none -display none \
+    -chardev file,path=hello.out,id=output -serial chardev:output
+```
+
+For a more complete emulation with UEFI firmware, currently there is no
+pre-compiled firmware blob yet, but in the meantime you may compile your own
+firmware image with Loongson's forked [EDK II][edk2] and
+[corresponding platform code][edk2-plat].
+
+[edk2]: https://github.com/loongson/edk2-LoongarchVirt
+[edk2-plat]: https://github.com/loongson/edk2-platforms
+
+Once you have the firmware image in place, you could boot EFI images with it.
+For example:
+
+```sh
+./qemu-system-loongarch64 -m 4G smp 4 \
+    -bios path/to/your/QEMU_EFI.fd \
+    -kernel path/to/your/vmlinux \
+    -initrd path/to/your/initramfs/if/you/have/one \
+    -append 'root=/dev/ram rdinit=/sbin/init console=ttyS0,115200'
+    -nographic
+```
+
+### Linux-user emulation
+
+Linux-user emulation is fully supported, and there are already several Linux
+distributions available with ready-to-use sysroot tarballs, for example
+[CLFS][clfs] and [Gentoo][gentoo].
+
+You may compile static qemu-user binaries then follow suitable instructions
+for your distribution (set up binfmt\_misc, etc.) to make yourself a LoongArch
+chroot for experimentation.
+
+[clfs]: https://github.com/sunhaiyong1978/CLFS-for-LoongArch
+[gentoo]: https://wiki.gentoo.org/wiki/Project:LoongArch
-- 
2.35.1