From da74c951e4e58080583daaad373b0d38a3f8bc83 Mon Sep 17 00:00:00 2001 From: Andrew Cooper Date: Tue, 14 Jun 2022 16:18:36 +0100 Subject: [PATCH] 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 Reviewed-by: Jan Beulich --- xen/common/wait.c | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/xen/common/wait.c b/xen/common/wait.c index e45345ede704..86d3b15419db 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(). *