Yann Sionneau wrote:
> I think instead of "going into user mode upon eret" I should just "go
> back into previous state upon eret".

Yes, you could use the same mechanism as IE.IE / IE.EIE.

You'll also need another state bit, namely an indication whether
you're in kernel/supervisor mode or not. In kernel mode, things
like WCSR and maybe RCSR would be allowed, while they'd be
restricted outside kernel mode.

It seems that the LM32 core doesn't come with such a distinction.

For simplicity, you could just treat WCSR and RCSR as no-ops when
restricted. Restrictions would mean:

- no writes to IE, IM, EBA, and anything related to the TLB
- you may also want to deny reads of TLB registers, since they
  could be used for side channel attacks,
- likewise, reads of CC - if implemented - could be restricted to
  prevent side channel attacks.

Reset, interrupts, and exceptions would

- copy and clear the TLB enable bit(s), e.g.,

  X.EDTLB = X.DTLB;
  X.DTLB = 0;
  X.EITLB = X.ITLB;
  X.ITLB = 0;

- copy and clear the user mode bit, e.g.,

  X.EUSR = X.USR;
  X.USR = 0;

ERET would then restore the X.E* bits to X.*, without changing
X.E*. E.g.,

  PC = gpr[ea]
  X.DTLB = X.EDTLB;
  X.ITLB = X.EITLB;
  X.USR = X.EUSR;

"X" are one or more suitable registers. If you put everything into
IE, then the logic outlined above would be reasonably
backward-compatible with regular LM32.

Thinking of compatibility, if using IE, you may also want to have
a bit that controls changing X.DTLB and X.ITLB, so that you don't
need to remember these bits when disabling and restoring
interrupts.

E.g.,

  WCSR to IE would work like this:

  if (gpr[rX].TLBCNG) {
        IE.DTLB = gpr[rX].DTLB;
        IE.ITLB = gpr[rX].ITLB;
  }
  X.IE = gpr[rX].IE;

  RCSR would work like this:

  gpr[rX] = IE;
  gpr[rX].TLBCNG = 0;

  ERET would still work as above, i.e., it would always set DTLB
  and ITLB.

Implementing nested interrupts and/or exceptions would then be up
to the respective handlers.

- Werner
_______________________________________________
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode

Reply via email to