[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC PATCH 0/3] target/mips: Make the number of TLB entries a CPU pr
From: |
Richard Henderson |
Subject: |
Re: [RFC PATCH 0/3] target/mips: Make the number of TLB entries a CPU property |
Date: |
Tue, 13 Oct 2020 19:22:39 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 |
On 10/13/20 4:11 PM, Richard Henderson wrote:
> On 10/13/20 6:25 AM, Philippe Mathieu-Daudé wrote:
>> Yocto developers have expressed interest in running MIPS32
>> CPU with custom number of TLB:
>> https://lists.gnu.org/archive/html/qemu-devel/2020-10/msg03428.html
>>
>> Help them by making the number of TLB entries a CPU property,
>> keeping our set of CPU definitions in sync with real hardware.
>
> You mean keeping the 34kf model within qemu in sync, rather than creating a
> nonsense model that doesn't exist.
>
> Question: is this cpu parameter useful for anything else?
>
> Because the ideal solution for a CI loop is to use one of the mips cpu models
> that has the hw page table walker (CP0C3_PW). Having qemu being able to
> refill
> the tlb itself is massively faster.
>
> We do not currently implement a mips cpu that has the PW. When I downloaded
Bah, "mips32 cpu".
We do have the P5600 that does has it, though the code is wrapped up in
TARGET_MIPS64. I'll also note that the code could be better placed [*]
> (1) anyone know if the PW incompatible with mips32?
I've since found a copy of the mips32-pra in the wayback machine and have
answered this as "no" -- PW is documented for mips32.
> (2) if not, was there any mips32 hw built with PW
> that we could model?
But I still don't know about this.
A further question for the Yocto folks: could you make use of a 64-bit kernel
in testing a 32-bit userspace?
And I guess maybe we should update our recommendations in the docs. Thoughts
on this, Phil?
r~
[*] Where it is now, it can't be used for gdb (mips_cpu_get_phys_page_debug).
When used there, we should not modify cpu state, i.e. actually insert the PTE
into the MIPS TLB, but we could still make use of the information available.
- [RFC PATCH 0/3] target/mips: Make the number of TLB entries a CPU property, Philippe Mathieu-Daudé, 2020/10/13
- [RFC PATCH 1/3] target/mips: Make cpu_mips_realize_env() propagate Error, Philippe Mathieu-Daudé, 2020/10/13
- [RFC PATCH 2/3] target/mips: Store number of TLB entries in CPUMIPSState, Philippe Mathieu-Daudé, 2020/10/13
- [RFC PATCH 3/3] target/mips: Make the number of TLB entries a CPU property, Philippe Mathieu-Daudé, 2020/10/13
- Re: [RFC PATCH 0/3] target/mips: Make the number of TLB entries a CPU property, Richard Henderson, 2020/10/13
- Re: [RFC PATCH 0/3] target/mips: Make the number of TLB entries a CPU property,
Richard Henderson <=
- Re: [RFC PATCH 0/3] target/mips: Make the number of TLB entries a CPU property, Victor Kamensky (kamensky), 2020/10/13
- Re: [RFC PATCH 0/3] target/mips: Make the number of TLB entries a CPU property, Richard Purdie, 2020/10/14
- Re: [RFC PATCH 0/3] target/mips: Make the number of TLB entries a CPU property, Philippe Mathieu-Daudé, 2020/10/14
- Re: [RFC PATCH 0/3] target/mips: Make the number of TLB entries a CPU property, Victor Kamensky (kamensky), 2020/10/14
- Re: [RFC PATCH 0/3] target/mips: Make the number of TLB entries a CPU property, Khem Raj, 2020/10/14
- Re: [RFC PATCH 0/3] target/mips: Make the number of TLB entries a CPU property, Victor Kamensky (kamensky), 2020/10/15
- Re: [RFC PATCH 0/3] target/mips: Make the number of TLB entries a CPU property, Richard Henderson, 2020/10/16