• State Accepted Answer
  • Locked Locked
  • Replies 1 reply
  • Subscribers 349 subscribers
  • Views 4901 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

EL1 behavior when MMU is off

armdev

Hi,

I am facing issues with EL1 Guest OS.  I have enabled EL2 stage 2 page tables and set up all the virtualization registers {HCR_EL2, VTCR_EL2 and VTTBR_EL2 etc.}

I am mapping my Guest OS memory to stage 2 tables but as I try to do "eret" from EL2 mode and jump to Guest OS I am getting "Bus error on memory operation"

My questions is if the MMU is off for EL1 mode then is it right that translation will be done using stage 2 tables as Guest OS job is to setup its own page tables and tun on MMU ?

Thanks

  • 0 Arm Employee Badge

    armdev wrote:

    My questions is if the MMU is off for EL1 mode then is it right that translation will be done using stage 2 tables as Guest OS job is to setup its own page tables and tun on MMU ?

    Yes.  (Strictly, with the stage 1 MMU disabled VA=IPA)  With the IPA to PA mapping handled by the stage 2 table)  Attributes are a little different, in that the result of the stage 1 and 2 are combined following rules in the ARM ARM.  Although, I doubt that's the problem here.

    In terms of debugging, I have a couple of suggestions...

    • Have you disabled the stage 1 MMU, or just not enabled it?  The difference being that the architecture does not guarantee the reset value of SCTLR_EL1, if EL2 and/or EL3 is implemented.
    • From the error message (and previous threads), I think the message you are seeing is from the debugger and you are stepping the code.  Correct?  If so, I'd suggest setting breakpoints in the vector table and running (not stepping) until you hit the breakpoint.  Preferably with the breakpoint after the reads of ESR_EL2 and FAR_EL2.  The reason being that every time you step the debugger is refreshing all it windows, often using memory accesses.  This can be a pain when investigating some problems.
    • Before the ERET, you could try using the AT instruction.  This lets you do test translations (with the result written to PAR_EL2).