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

[ckim]

Hello, Peter Maydell,

I've added print in get_phys_addr at the entrance
'printf("address = %llx\n", address);'
And found actualy it's called not that many times. (3 or 4 times before this 
thing happens)
Right after I set sctlr_el3 register, this get_phys_addr is again called. And I 
get
        Address = 28c.
But when I see the objdump code, it is like 

   1027c:   d53ec002    mrs x2, vbar_el3
   10280:   d5380702    mrs x2, id_aa64mmfr0_el1
   10284:   d53e2042    mrs x2, tcr_el3
   10288:   d51e1000    msr sctlr_el3, x0   <=== trap seems to happen here
   1028c:   d51c1000    msr sctlr_el2, x0    <=== accessing virtual address 
28c, not 1028c.
   10290:   d5181000    msr sctlr_el1, x0
   10294:   d5034fff    msr daifclr, #0xf
   10298:   d53e1100    mrs x0, scr_el3
   1029c:   b27e0000    orr x0, x0, #0x4

The next command (msr sctlr_el2, x0) is at 0x1028c, but the get_phy_addr 
function was called with virtual address 0x28c. Is this normal? I don't know 
why there is this difference of 0x10000.(0x10000 is the start address of page 
table)

Could you advise me on this? Thanks!

Chan Kim

> -----Original Message-----
> From: ckim@etri.re.kr <ckim@etri.re.kr>
> Sent: Wednesday, March 10, 2021 5:12 PM
> To: 'Peter Maydell' <peter.maydell@linaro.org>
> Cc: 'qemu-discuss' <qemu-discuss@nongnu.org>
> Subject: RE: What does soft-mmu mean? What happens when we set MMU
> registers? (aarch64)
> 
> 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