Re: [RFC PATCH 0/3] target/mips: Make the number of TLB entries a CPU property

[Victor Kamensky (kamensky)]

In order just to keep on the same thread, here is piece of information
I found:

I looked at "MIPS32® 34Kf™ Processor Core Datasheet" [1]

Page 8 in "Joint TLB (JTLB)" section says:

"The JTLB is a fully associative TLB cache containing 16, 32,
or 64-dual-entries mapping up to 128 virtual pages to their
corresponding physical addresses."

So "34Kf-64tlb" cpu model I proposed turns out not to be "fictitious"
after all. Having 64 TLBs is all within this CPU spec. It is not clear
why original 34Kf model choose worst case scenario wrt
TLB numbers. Commit log where 34Kf was introduced does not
have much details.

So IMO on 34Kf route we have the following choices:

1) I can rephrase commit message and resubmit commit for
"34Kf-64tlb" cpu model, if it could be merged

2) We can bump up number of TLBs to 64 in existing 34Kf model
since it is within the spec.

3) Use Phil's series and tlb-entries cpu parameter would cover all
3 variants of 16,32,64 TLBs allowed by 34Kf data sheet spec.

Please see inline wrt asked '-cpu P5600' testing. Look for 'victor2>'

[1] 
https://s3-eu-west-1.amazonaws.com/downloads-mips/documents/MD00419-2B-34Kf-DTS-01.20.pdf

________________________________________
From: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com> on behalf of 
Philippe Mathieu-Daudé <f4bug@amsat.org>
Sent: Wednesday, October 14, 2020 7:53 AM
To: Richard Purdie; Victor Kamensky (kamensky); qemu-devel@nongnu.org
Cc: Aleksandar Rikalo; Khem Raj; Aleksandar Markovic; Aurelien Jarno; Richard 
Henderson
Subject: Re: [RFC PATCH 0/3] target/mips: Make the number of TLB entries a CPU 
property

On 10/14/20 9:14 AM, Richard Purdie wrote:
> On Wed, 2020-10-14 at 01:36 +0000, Victor Kamensky (kamensky) wrote:
>> Thank you very much for looking at this. I gave a spin to
>> your 3 patch series in original setup, and as expected with
>> '-cpu 34Kf,tlb-entries=64' option it works great.
>>
>> If nobody objects, and your patches could be merged, we
>> would greatly appreciate it.
>
> Speaking as one of the Yocto Project maintainers, this is really
> helpful for us, thanks!
>
> qemumips is one of our slowest platforms for automated testing so this
> performance improvement helps a lot.

Could you try Richard's suggestion? Using '-cpu P5600' instead?
It is available in Linux since v5.8.

victor2> I've tried exact image that works on 34Kf and 34Kf-64tlb models
victor2> image with '-cpu P5600'. it does not boot: it dies in init (systemd).
victor2> I can look under gdb with qemu -s -S options, what is going on there
victor2> but it will take time.
victor2> If someone have some clues what might cause it please let
victor2> me know. Here is high level information about setup:
victor2>    - qemu version is 5.1.0
victor2>    - kernel base version is 5.8.9
victor2>    - systemd version is 1_246.6
victor2>    - user land CPU related build options "-meb -meb -mabi=32 
-mhard-float -march=mips32r2 -mllsc -mips32r2"

Thanks,
Victor

>
> Cheers,
>
> Richard
>
>