Thanks a lot Peter for the clarification. It is very helpful.
My naive understanding is that each MMU has only 1 TLB, why do we need an array
of CPUTLBDescFast structures? How are these different CPUTLBDescFast data
structures correlate with a hardware TLB?
220 typedef struct CPUTLB {
221 CPUTLBCommon c;
222 CPUTLBDesc d[NB_MMU_MODES];
223 CPUTLBDescFast f[NB_MMU_MODES];
224 } CPUTLB;
Why do we want to store a shifted (n_entries-1) in mask?
184 typedef struct CPUTLBDescFast {
185 /* Contains (n_entries - 1) << CPU_TLB_ENTRY_BITS */
186 uintptr_t mask;
187 /* The array of tlb entries itself. */
188 CPUTLBEntry *table;
189 } CPUTLBDescFast QEMU_ALIGNED(2 * sizeof(void *));
Why doesn't CPUTLBEntry have information like ASID, shared (or global) bits?
How do we know if the TLB entry is a match for a particular process?
In include/exec/cpu-defs.h:
111 typedef struct CPUTLBEntry {
112 /* bit TARGET_LONG_BITS to TARGET_PAGE_BITS : virtual address
113 bit TARGET_PAGE_BITS-1..4 : Nonzero for accesses that should not
114 go directly to ram.
115 bit 3 : indicates that the entry is invalid
116 bit 2..0 : zero
117 */
118 union {
119 struct {
120 target_ulong addr_read;
121 target_ulong addr_write;
122 target_ulong addr_code;
123 /* Addend to virtual address to get host address. IO accesses
124 use the corresponding iotlb value. */
125 uintptr_t addend;
126 };
127 /* padding to get a power of two size */
128 uint8_t dummy[1 << CPU_TLB_ENTRY_BITS];
129 };
130 } CPUTLBEntry;
Thanks!
________________________________
From: Peter Maydell <peter.mayd...@linaro.org>
Sent: October 4, 2022 9:20 AM
To: a b <blue_3...@hotmail.com>
Cc: qemu-devel@nongnu.org <qemu-devel@nongnu.org>
Subject: Re: A few QEMU questiosn
On Tue, 4 Oct 2022 at 02:10, a b <blue_3...@hotmail.com> wrote:
> I have a few newbie QEMU questions. I found that mmu_idx in aarch64-softmmu
> falls in 8, 10 and 12.
>
> I need some help to understand what they are for.
>
> I cannot find which macros are for mmu-idx 8, 10 and 12 at target/arm/cpu.h.
> It looks like all the values from ARMMMUIdx are greater than 0x10
> (ARM_MMU_IDX_A). Am I looking at the wrong place or missing something for the
> different MMU modes in aarch64?
The comment in target/arm/cpu.h and the various enum definitions
should be what you need. Note in particular the part that says
"The ARMMMUIdx and the mmu index value used by the core QEMU
TLB code are not quite the same" and also the functions in
internals.h arm_to_core_mmu_idx() and core_to_arm_mmu_idx()
which convert between these two representations.
PS: there is a refactoring patch set currently in review which
changes the MMU index allocation (essentially it collapses
the separate Secure and NonSecure MMUIdx values together),
so the specific details will likely change at some point this
release cycle.
thanks
-- PMM
