| Message ID | 20220814145522.1474927-4-i.qemu@xen0n.name |
|---|---|
| State | New |
| Headers | show |
| Series | Last-minute LoongArch CPU model naming tweaks | expand |
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~
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~ >
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)
在 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~ >> >
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
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~
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.
在 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.
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~
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)