[PATCH v3 08/21] KVM: arm64: Convert kvm_set_spte_hva() to generic page-table API

Alexandru Elisei alexandru.elisei at arm.com
Wed Sep 2 11:37:18 EDT 2020


Hi Will,

There are still a few comments and code paths in stage2_set_pte referring to
kvm_set_spte_hva.

On 8/25/20 10:39 AM, Will Deacon wrote:
> Convert kvm_set_spte_hva() to use kvm_pgtable_stage2_map() instead
> of stage2_set_pte().
>
> Cc: Marc Zyngier <maz at kernel.org>
> Cc: Quentin Perret <qperret at google.com>
> Signed-off-by: Will Deacon <will at kernel.org>
> ---
>  arch/arm64/kvm/mmu.c | 23 ++++++++++-------------
>  1 file changed, 10 insertions(+), 13 deletions(-)
>
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index 33146d3dc93a..704b471a48ce 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -1911,28 +1911,27 @@ int kvm_unmap_hva_range(struct kvm *kvm,
>  
>  static int kvm_set_spte_handler(struct kvm *kvm, gpa_t gpa, u64 size, void *data)
>  {
> -	pte_t *pte = (pte_t *)data;
> +	kvm_pfn_t *pfn = (kvm_pfn_t *)data;
>  
>  	WARN_ON(size != PAGE_SIZE);
> +
>  	/*
> -	 * We can always call stage2_set_pte with KVM_S2PTE_FLAG_LOGGING_ACTIVE
> -	 * flag clear because MMU notifiers will have unmapped a huge PMD before
> -	 * calling ->change_pte() (which in turn calls kvm_set_spte_hva()) and
> -	 * therefore stage2_set_pte() never needs to clear out a huge PMD
> -	 * through this calling path.
> +	 * The MMU notifiers will have unmapped a huge PMD before calling
> +	 * ->change_pte() (which in turn calls kvm_set_spte_hva()) and
> +	 * therefore we never need to clear out a huge PMD through this
> +	 * calling path and a memcache is not required.
>  	 */
> -	stage2_set_pte(&kvm->arch.mmu, NULL, gpa, pte, 0);
> +	kvm_pgtable_stage2_map(kvm->arch.mmu.pgt, gpa, PAGE_SIZE,
> +			       __pfn_to_phys(*pfn), KVM_PGTABLE_PROT_R, NULL);

I have to admit that I managed to confuse myself.

According to the comment, this is called after unmapping a huge PMD.
__unmap_stage2_range() -> .. -> unmap_stage2_pmd() calls pmd_clear(), which means
the PMD entry is now 0.

In __kvm_pgtable_visit(), kvm_pte_table() returns false, because the entry is
invalid, and so we call stage2_map_walk_leaf(). Here, stage2_map_walker_try_leaf()
will return false, because kvm_block_mapping_supported() returns false (PMD
granule is larger than PAGE_SIZE), and then we end up allocating a table from the
memcache. memcache which will NULL, and kvm_mmu_memory_cache_alloc() will
dereference the NULL pointer.

I'm pretty sure there's something that I'm missing here, I would really appreciate
someone pointing out where I'm making a mistake.

Thanks,

Alex

>  	return 0;
>  }
>  
> -
>  int kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte)
>  {
>  	unsigned long end = hva + PAGE_SIZE;
>  	kvm_pfn_t pfn = pte_pfn(pte);
> -	pte_t stage2_pte;
>  
> -	if (!kvm->arch.mmu.pgd)
> +	if (!kvm->arch.mmu.pgt)
>  		return 0;
>  
>  	trace_kvm_set_spte_hva(hva);
> @@ -1942,9 +1941,7 @@ int kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte)
>  	 * just like a translation fault and clean the cache to the PoC.
>  	 */
>  	clean_dcache_guest_page(pfn, PAGE_SIZE);
> -	stage2_pte = kvm_pfn_pte(pfn, PAGE_S2);
> -	handle_hva_to_gpa(kvm, hva, end, &kvm_set_spte_handler, &stage2_pte);
> -
> +	handle_hva_to_gpa(kvm, hva, end, &kvm_set_spte_handler, &pfn);
>  	return 0;
>  }
>  



More information about the linux-arm-kernel mailing list