[xen master] xen/wait: Describe RSB safety

[patchbot@xxxxxxx]

commit da74c951e4e58080583daaad373b0d38a3f8bc83
Author:     Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
AuthorDate: Tue Jun 14 16:18:36 2022 +0100
Commit:     Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
CommitDate: Fri Aug 5 12:16:59 2022 +0100

    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@xxxxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
---
 xen/common/wait.c | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/xen/common/wait.c b/xen/common/wait.c
index e45345ede7..86d3b15419 100644
--- a/xen/common/wait.c
+++ b/xen/common/wait.c
@@ -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().
      *
--
generated by git-patchbot for /home/xen/git/xen.git#master