[PATCH v4 05/13] KVM: arm64: Rename __guest_exit_panic __hyp_panic

[Pierre-Clément Tosi]

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 at google.com>
> > ---
> >  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/