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

bugzilla-daemon at libre-soc.org bugzilla-daemon at libre-soc.org
Fri Oct 20 20:59:49 BST 2023


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

--- Comment #104 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(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

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

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....

but for now you are missing the "updatepcnext" and the return,
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

see what's happening there? the sc is performed on a "cheat", which
*runs the sc pseudocode*, then you emulate the syscall, then
pretend that there was an OS that swapped all the context back and
as the last thing, does rfid which we can emulate by *running the
rfid pseudocode*

worst most elegant hack i can think of that gets the job done fast.
otherwise you have to analyse the effect of the sc and rfid pseudocode
back-to-back:

https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=openpower/isa/system.mdwn;h=958502d3#l48


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


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)

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


More information about the libre-soc-bugs mailing list