[PATCH v4 09/10] KVM: arm64: Stage-2 huge mappings for np-guests

Marc Zyngier maz at kernel.org
Fri May 16 06:28:27 PDT 2025


On Fri, 09 May 2025 14:17:05 +0100,
Vincent Donnefort <vdonnefort at google.com> wrote:
> 
> Now np-guests hypercalls with range are supported, we can let the
> hypervisor to install block mappings whenever the Stage-1 allows it,
> that is when backed by either Hugetlbfs or THPs. The size of those block
> mappings is limited to PMD_SIZE.
> 
> Signed-off-by: Vincent Donnefort <vdonnefort at google.com>
> 
> diff --git a/arch/arm64/kvm/hyp/nvhe/mem_protect.c b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
> index 78fb9cea2034..97e0fea9db4e 100644
> --- a/arch/arm64/kvm/hyp/nvhe/mem_protect.c
> +++ b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
> @@ -167,7 +167,7 @@ int kvm_host_prepare_stage2(void *pgt_pool_base)
>  static bool guest_stage2_force_pte_cb(u64 addr, u64 end,
>  				      enum kvm_pgtable_prot prot)
>  {
> -	return true;
> +	return false;
>  }

Can we get rid of this callback now? And of the .force_pte_cb field in
the kvm_pgtable struct?

>  
>  static void *guest_s2_zalloc_pages_exact(size_t size)
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index 754f2fe0cc67..7c8be22e81f9 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -1537,7 +1537,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>  	 * logging_active is guaranteed to never be true for VM_PFNMAP
>  	 * memslots.
>  	 */
> -	if (logging_active || is_protected_kvm_enabled()) {
> +	if (logging_active) {
>  		force_pte = true;
>  		vma_shift = PAGE_SHIFT;
>  	} else {
> @@ -1547,7 +1547,8 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>  	switch (vma_shift) {
>  #ifndef __PAGETABLE_PMD_FOLDED
>  	case PUD_SHIFT:
> -		if (fault_supports_stage2_huge_mapping(memslot, hva, PUD_SIZE))
> +		if (!is_protected_kvm_enabled() &&
> +		    fault_supports_stage2_huge_mapping(memslot, hva, PUD_SIZE))

Can you move this new condition into the fault_supports...() helper instead?

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.



More information about the linux-arm-kernel mailing list