Re: [PATCH v2 2/5] KVM: arm64: Reject the stage-2 flush hypercalls under pKVM

[Suzuki K Poulose <suzuki.poulose@arm.com>]

On 11/10/2026 15:36, Fuad Tabba wrote:
> The stage-2 TLB and context flush hypercalls remain callable once pKVM
> has finalised, and five of the six dereference a host-supplied
> struct kvm_s2_mmu pointer. Under pKVM none has a valid caller: the host
> walks no guest stage-2, its TLB flushes go through the handle-based
> __pkvm_tlb_flush_vmid, and kvm_arch_vcpu_load() skips both the VMID
> update and the CPU context flush.
> 
> Move them into the band the dispatcher rejects once pKVM has finalised.
> 
> Reported-by: Sashiko <sashiko-bot@kernel.org>
> Closes: https://lore.kernel.org/all/20260914130152.F0D5F1F000FF@smtp.kernel.org/
> Signed-off-by: Fuad Tabba <fuad.tabba@linux.dev>
> ---
>   arch/arm64/include/asm/kvm_asm.h   | 12 ++++++------
>   arch/arm64/kvm/hyp/nvhe/hyp-main.c | 11 ++++++-----
>   2 files changed, 12 insertions(+), 11 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h
> index ea319c496bb26..b182c908c1a98 100644
> --- a/arch/arm64/include/asm/kvm_asm.h
> +++ b/arch/arm64/include/asm/kvm_asm.h
> @@ -64,6 +64,12 @@ enum __kvm_host_smccc_func {
>   	__KVM_HOST_SMCCC_FUNC___vgic_v3_get_gic_config,
>   	__KVM_HOST_SMCCC_FUNC___vgic_v5_save_apr,
>   	__KVM_HOST_SMCCC_FUNC___vgic_v5_restore_vmcr_apr,
> +	__KVM_HOST_SMCCC_FUNC___kvm_flush_vm_context,
> +	__KVM_HOST_SMCCC_FUNC___kvm_tlb_flush_vmid_ipa,
> +	__KVM_HOST_SMCCC_FUNC___kvm_tlb_flush_vmid_ipa_nsh,

For a moment (pardon my inexperience with pKVM code base) I thought we
could get this called via

pkvm_stage2_relax_perms() ->... kvm_stage2_relax_perms() for the host, 
but we are in EL2 already and it is a direct call.

So, yes makes sense to me.

FWIW:

Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>

> +	__KVM_HOST_SMCCC_FUNC___kvm_tlb_flush_vmid,
> +	__KVM_HOST_SMCCC_FUNC___kvm_tlb_flush_vmid_range,
> +	__KVM_HOST_SMCCC_FUNC___kvm_flush_cpu_context,
>   
>   	MARKER(__KVM_HOST_SMCCC_FUNC_MIN_PKVM),
>   
> @@ -72,12 +78,6 @@ enum __kvm_host_smccc_func {
>   	/* Hypercalls that are always available and common to [nh]VHE/pKVM. */
>   	__KVM_HOST_SMCCC_FUNC___kvm_adjust_pc,
>   	__KVM_HOST_SMCCC_FUNC___kvm_vcpu_run,
> -	__KVM_HOST_SMCCC_FUNC___kvm_flush_vm_context,
> -	__KVM_HOST_SMCCC_FUNC___kvm_tlb_flush_vmid_ipa,
> -	__KVM_HOST_SMCCC_FUNC___kvm_tlb_flush_vmid_ipa_nsh,
> -	__KVM_HOST_SMCCC_FUNC___kvm_tlb_flush_vmid,
> -	__KVM_HOST_SMCCC_FUNC___kvm_tlb_flush_vmid_range,
> -	__KVM_HOST_SMCCC_FUNC___kvm_flush_cpu_context,
>   	__KVM_HOST_SMCCC_FUNC___kvm_timer_set_cntvoff,
>   	__KVM_HOST_SMCCC_FUNC___tracing_load,
>   	__KVM_HOST_SMCCC_FUNC___tracing_unload,
> diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> index 7c939baf9c1ba..b2657a3c65b40 100644
> --- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> +++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> @@ -913,16 +913,16 @@ static const hcall_t host_hcall[] = {
>   	HANDLE_FUNC(__vgic_v3_get_gic_config),
>   	HANDLE_FUNC(__vgic_v5_save_apr),
>   	HANDLE_FUNC(__vgic_v5_restore_vmcr_apr),
> -	HANDLE_FUNC(__pkvm_prot_finalize),
> -
> -	HANDLE_FUNC(__kvm_adjust_pc),
> -	HANDLE_FUNC(__kvm_vcpu_run),
>   	HANDLE_FUNC(__kvm_flush_vm_context),
>   	HANDLE_FUNC(__kvm_tlb_flush_vmid_ipa),
>   	HANDLE_FUNC(__kvm_tlb_flush_vmid_ipa_nsh),
>   	HANDLE_FUNC(__kvm_tlb_flush_vmid),
>   	HANDLE_FUNC(__kvm_tlb_flush_vmid_range),
>   	HANDLE_FUNC(__kvm_flush_cpu_context),
> +	HANDLE_FUNC(__pkvm_prot_finalize),
> +
> +	HANDLE_FUNC(__kvm_adjust_pc),
> +	HANDLE_FUNC(__kvm_vcpu_run),
>   	HANDLE_FUNC(__kvm_timer_set_cntvoff),
>   	HANDLE_FUNC(__tracing_load),
>   	HANDLE_FUNC(__tracing_unload),
> @@ -969,7 +969,8 @@ static void handle_host_hcall(struct kvm_cpu_context *host_ctxt)
>   
>   	/*
>   	 * If pKVM has been initialised then reject any calls to the
> -	 * early "privileged" hypercalls. Note that we cannot reject
> +	 * early "privileged" hypercalls, and to the ones the host has no
> +	 * use for in protected mode. Note that we cannot reject
>   	 * calls to __pkvm_prot_finalize for two reasons: (1) The static
>   	 * key used to determine initialisation must be toggled prior to
>   	 * finalisation and (2) finalisation is performed on a per-CPU