On Mon, Jun 03, 2024 at 03:34:24PM +0100, Will Deacon wrote: > On Wed, May 29, 2024 at 01:12:11PM +0100, Pierre-Clément Tosi wrote: > > Use a name that expresses the fact that the routine might not exit > > through the guest but will always (directly or indirectly) end up > > executing hyp_panic(). > > > > Use CPU_LR_OFFSET to clarify that the routine returns to hyp_panic(). > > > > Signed-off-by: Pierre-Clément Tosi <ptosi@xxxxxxxxxx> > > --- > > arch/arm64/kvm/hyp/entry.S | 6 +++--- > > arch/arm64/kvm/hyp/hyp-entry.S | 2 +- > > arch/arm64/kvm/hyp/include/hyp/switch.h | 4 ++-- > > arch/arm64/kvm/hyp/nvhe/host.S | 4 ++-- > > 4 files changed, 8 insertions(+), 8 deletions(-) > > Hmm, I'm not sure about this. When is __guest_exit_panic() called outside > of guest context? AFAICT, it is also called from - the early __kvm_hyp_host_vector, installed by cpu_hyp_init_context() - the flavors of __kvm_hyp_vector, installed by cpu_hyp_init_features() which start handling exceptions long before the first guest can even be spawned. Hence __guest_exit_panic() needing to validate the context on entry. I don't get why those handlers didn't branch directly to hyp_panic() (perhaps to have a more robust flow?) but, as mentioned in [1], it is convenient for kCFI to be able to intercept all panic paths for sync exception from a single place. [1]: https://lore.kernel.org/kvm/qob5gnca2nte4ggkrnn4uil5mfbkz3p55lmk3egpxstnumixfr@lq7xomrhf6za/
