The rt_sigreturn() system call has a special return-to-userspace flow. It differs from a normal sysret flow in that rt_sigreturn() already prepared the context (including RSP, RFLAGS, etc.) and expects an iretq instruction at the end.
This commit special-cases this sigreturn flow in VM-based PAL assembly. Since the LibOS sigreturn handling already prepared all the context, we must introduce and use per-thread scratch registers to move temporarily to another (pseudo) stack from which the iretq instruction will pop RSP, RFLAGS, RIP, etc.
This change will become important in future commits when support for PF exception handling will be added. In particular, this change is required to run Java workloads (which do #PFs on purpose and then handle the resulting SIGSEGV signal).
How to test this PR?
When Java workload will start working (need more PRs to add proper #PF exception handling), then run Java.
Description of the changes
The
rt_sigreturn()system call has a special return-to-userspace flow. It differs from a normal sysret flow in thatrt_sigreturn()already prepared the context (including RSP, RFLAGS, etc.) and expects an iretq instruction at the end.This commit special-cases this sigreturn flow in VM-based PAL assembly. Since the LibOS sigreturn handling already prepared all the context, we must introduce and use per-thread scratch registers to move temporarily to another (pseudo) stack from which the iretq instruction will pop RSP, RFLAGS, RIP, etc.
This change will become important in future commits when support for PF exception handling will be added. In particular, this change is required to run Java workloads (which do #PFs on purpose and then handle the resulting SIGSEGV signal).
How to test this PR?
When Java workload will start working (need more PRs to add proper #PF exception handling), then run Java.
This change is