qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: maobibo
Subject: Re: [PATCH for-7.1 3/4] target/loongarch: rename the TCG CPU "la464" to "qemu64-v1.00"
Date: Thu, 18 Aug 2022 13:22:06 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0


在 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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]