RE: What does soft-mmu mean? What happens when we set MMU registers? (aarch64)

[ckim]

Hi, Peter Maydell,

Thank you again for the kind explanation.
Yes, it seems like what you showed is correct.
So I checked several registers and the page table, but couldn't find any 
strange data yet(I'll continue).
Because I'm at EL3, I think the current translation regime is "Secure EL3 
translation regime", 
(single VA range, having a single stage translation)
In the code, the ttbr0_el3 and ttbr0_el0 is set to ttb0_base (the first table 
address), 
and the first entry of ttb0_base is a pointer to the second table,
The second table has many entries for 2MB blocks with attributes. 
(I couldn't find where this pgd->pte(for 2MB) configuration is shown possible 
in the document and asked at support@arm.)
I also checked the pflag.img (for ROM) actually has the tables.
I just found this link (with your answer, 
https://stackoverflow.com/questions/31187709/qemu-trace-mmu-operation ) and 
will try adding some debug prints in get_phys_addr function 
(target/arm/helper.c)
(there will be too many prints but I hope it be worth it)
Thank you and best regards,

Chan Kim

> -----Original Message-----
> From: Peter Maydell <peter.maydell@linaro.org>
> Sent: Tuesday, March 9, 2021 7:31 PM
> To: Chan Kim <ckim@etri.re.kr>
> Cc: qemu-discuss <qemu-discuss@nongnu.org>
> Subject: Re: What does soft-mmu mean? What happens when we set MMU
> registers? (aarch64)
> 
> On Tue, 9 Mar 2021 at 01:37, <ckim@etri.re.kr> wrote:
> >
> >
> > I found If I turn off the 'M' bit (MMU on) of x0 before I write it to
> sctrl_el3, sctrl_el2, and sctrl_el1, it doesn't cause exception.
> > So it's related to MMU (not SMMU of course). And using the -d
> int,exec,in_asm, the EC(exception class) was "“Instruction Abort taken
> without a change in Exception level k”.
> > Below is the debug output (from -d int,exec,in_asm), exception is caused
> at "msr sctlr_el3, x0".
> >
> > IN:
> > 0x0000024c:  d53e1000  mrs      x0, sctlr_el3
> > 0x00000250:  b27e0000  orr      x0, x0, #4
> > 0x00000254:  b2740000  orr      x0, x0, #0x1000
> > 0x00000258:  b2400000  orr      x0, x0, #1
> > 0x0000025c:  926cf800  and      x0, x0, #0xfffffffffff7ffff
> > 0x00000260:  b27d0000  orr      x0, x0, #8
> > 0x00000264:  927ef800  and      x0, x0, #0xfffffffffffffffd
> > 0x00000268:  d53e1002  mrs      x2, sctlr_el3    <-- just to check initial
> value
> > 0x0000026c:  d53c1002  mrs      x2, sctlr_el2    <-- just to check initial
> value
> > 0x00000270:  d5381002  mrs      x2, sctlr_el1    <-- just to check initial
> value
> > 0x00000274:  d51e1000  msr      sctlr_el3, x0    <-- exception happens.
> >
> > Trace 0: 0x7f82e73844c0 [0000000000000000/000000000000024c/0x8a100000]
> > Taking exception 3 [Prefetch Abort]
> > ...from EL3 to EL3
> > ...with ESR 0x21/0x86000010
> > ...with FAR 0x278
> > ...with ELR 0x278
> > ...to EL3 PC 0x1200 PSTATE 0x3cd
> > Taking exception 3 [Prefetch Abort]
> > ...from EL3 to EL3
> > ...with ESR 0x21/0x86000010
> > ...with FAR 0x1200
> > ...with ELR 0x1200
> > ...to EL3 PC 0x1200 PSTATE 0x3cd
> 
> You're at EL3, with the MMU off. You turn on the MMU. The next instruction
> fetch (for address 0x278) is therefore translated via your page tables.
> Your page tables don't have a mapping for 0x278. We take a prefetch abort.
> This means we try to load the insn at the start of the exception handler,
> which is at 0x1200. The MMU is still on. There's no mapping in your page
> tables for this either. We take another Prefetch Abort (and again and
> again...)
> 
> When you turn on the MMU for the EL you are currently running at, you need
> to ensure that the page tables you set up have a valid mapping for the
> code you're executing (usually a 1:1 mapping) so that the instruction
> fetches with the MMU on can load the insns.
> 
> On real hardware you may find that the CPU continues to execute some
> instructions after the write to SCTLR_EL3 because it had already fetched
> them; QEMU makes the MMU-enablement take effect immediately.
> The architecture permits either behaviour -- the only requirement is that
> the system register write must have taken effect at the point when the
> guest executes a subsequent barrier insn to force context synchronization.
> 
> thanks
> -- PMM