[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