[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