[Libre-soc-bugs] [Bug 982] Support PowerPC ABI in ISACaller

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=982

--- Comment #106 from Dmitry Selyutin <ghostmansd at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #104)
> (In reply to Dmitry Selyutin from comment #102)
> > I've updated the code logic so that it executes in a common way, except that
> > we can use emulation if this was desired:
> > 
> > https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;
> > h=c215d24e6a3983e9da525ea04bc710abb605c256
> 
> briilliant. so yes, if self.syscalls is not set up, that's perfect.
> 
> errr hang on though, you forgot these:
> 
>    -                self.update_pc_next()
>    -                return

https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/isa/test_syscall.py;h=74b336839ae677be9f25e66a8f3f422d7ef18718;hb=a31c1b972039ff28c0d4e289e759c93e22bf65ff#l19

This is explicitly checked here. The trick is that some code later already does
it. Also, if we return, we won't execute the pseudocode, which is something we
want to do.

> the actual sequence *to be emulated* is (i left out MSR):
> 
>    PC=0x00000 addi r0,r0,N # syscall number
>    PC=0x00004 sc LEV=0     # syscall which causes saving to SRR1/SRR0
>    PC=0x00C00 ....         # OS starts doing context-switch here
>    PC=0x00C70 ....         # OS starts doing actual syscall about here
>    PC=0x00Ce0 ....         # OS starts RESTORING context here
>    PC=0x00Ce4 rfid         # rfid *RESTORES* SRR1/SRR0 into MSR/PC...
>    PC=0x00008 usercode     # ... aaand we are back to after the syscall
> 
> therefore hmmm what must be done by the emulator is:
> 
>    PC=0x00000 addi r0,r0,N # syscall number
>    PC=0x00004 sc LEV=0     # syscall *and effect of sc and rfid* EMULATED
>    PC=0x00008 usercode     # ... aaand we are back to after the syscall

Is rfid handled by the kernel? Kinda like sysret/sysexit in x86?

> strictly speaking some bits of MSR must be set to zero,
> it must be as if sc is called then rfid called.
> 
> > I also checked that sc test from trap_cases works.
> > I tried to adopt the SRR1 and MSR checks there, but the values I got are
> > different, no idea why.
> 
> ah. right. ok.  the clue is the modifications to SRR1 and MSR made
> by the back-to-back sc and rfid.
> 
> BUT... to properly check this you have to have a program that
> does both an sc and an rfid, hmmm....

I don't quite get how trap_cases do it. They have separate tests for rfid,
that's true. But I don't see rfid in the sc test case itself...

> but for now you are missing the "updatepcnext" and the return,

See above.

> but this is still *not* quite correct, see below
> 
> 
> > https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;
> > h=a31c1b972039ff28c0d4e289e759c93e22bf65ff
> > 
> > Ideas on SRR1/MSR checks are highly appreciated.
> 
> ok i know what to do.
> 
> 1943     def call(self, name, CHEAT=False):
> 
> 2056         # Usermode system call emulation
> 2057         if asmop in ("sc", "scv") and self.syscall is not None
>                                        AND NOT CHEAT:
>                  # must emulate the effect of sc followed by rfid.
>                  self.call(asmop, CHEAT=True)
>                  # now do the emulated syscall...
> 2058             identifier = self.gpr(0)
> 2059             arguments = map(self.gpr, range(3, 9))
> 2060             result = self.syscall(identifier, *arguments)
> 2061             self.gpr.write(3, result, False, self.namespace["XLEN"])
>                  # now emulate "return from interrupt"
>                  self.call("rfid")
>                  # and we are done here. above, rfid updates pc already
>                  return

This seems to update PC twice, if I'm not mistaken.

> to be absolutely honest there's no point when you can just do
> self.call("sc") and self.call("rfid")

Yes, mine impression is the same. After all, emulating system calls is not the
only thing we have to support in order to emulate user mode; however, I feel
that the rest is outside of the scope of the changes we initially discussed.

> what i suggest is just to set MSR=0xfffffffffffffff and see what value
> it gets set to afterwards.  then use that to work out the "masking"
> effect.
> 
> test_syscall.py:
> 
> +        initial_sprs = {'SRR0': 0x12345678, 'SRR1': 0x5678}
> +        sim = run_tst(prog, initial_regs,
> +            initial_sprs=initial_sprs,
>              initial_msr=0xffffffffffffffff,
> +            use_syscall_emu=True)

Sorry, I didn't get it. Do you suggest to check that MSR just got changed from
that initial value (assertNotEqual)?

-- 
You are receiving this mail because:
You are on the CC list for the bug.