mirror of
https://github.com/xen-project/xen.git
synced 2026-10-28 02:01:24 +01:00
xen/wait: Describe RSB safety
It turns out that we do in fact have RSB safety here, but not for obvious reasons. Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com>
This commit is contained in:
1 parent
e570e8d520
commit
da74c951e4
1 file changed
+21
@@ -209,6 +209,27 @@ void check_wakeup_from_wait(void)
|
||||
do_softirq();
|
||||
}
|
||||
|
||||
/*
|
||||
* We are about to jump into a deeper call tree. In principle, this risks
|
||||
* executing more RET than CALL instructions, and underflowing the RSB.
|
||||
*
|
||||
* However, we are pinned to the same CPU as previously. Therefore,
|
||||
* either:
|
||||
*
|
||||
* 1) We've scheduled another vCPU in the meantime, and the context
|
||||
* switch path has (by default) issued IBPB which flushes the RSB, or
|
||||
*
|
||||
* 2) We're still in the same context. Returning back to the deeper
|
||||
* call tree is resuming the execution path we left, and remains
|
||||
* balanced as far as that logic is concerned.
|
||||
*
|
||||
* In fact, the path through the scheduler will execute more CALL
|
||||
* than RET instructions, making the RSB unbalanced in the safe
|
||||
* direction.
|
||||
*
|
||||
* Therefore, no actions are necessary here to maintain RSB safety.
|
||||
*/
|
||||
|
||||
/*
|
||||
* Hand-rolled longjmp().
|
||||
*
|
||||
|
||||