From: Marc Zyngier <maz@kernel.org>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org,
Will Deacon <will@kernel.org>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Keqian Zhu <zhukeqian1@huawei.com>,
Christoffer Dall <christoffer.dall@arm.com>,
Jiang Yi <giangyi@amazon.com>, James Morse <james.morse@arm.com>,
Andrew Scull <ascull@google.com>,
Zenghui Yu <yuzenghui@huawei.com>,
Julien Thierry <julien.thierry.kdev@gmail.com>,
David Brazdil <dbrazdil@google.com>,
Alexandru Elisei <alexandru.elisei@arm.com>,
Ard Biesheuvel <ardb@kernel.org>, Fuad Tabba <tabba@google.com>,
linux-arm-kernel@lists.infradead.org
Subject: [PATCH 12/24] KVM: arm64: Unify handling THP backed host memory
Date: Fri, 29 May 2020 17:01:09 +0100 [thread overview]
Message-ID: <20200529160121.899083-13-maz@kernel.org> (raw)
In-Reply-To: <20200529160121.899083-1-maz@kernel.org>
From: Suzuki K Poulose <suzuki.poulose@arm.com>
We support mapping host memory backed by PMD transparent hugepages
at stage2 as huge pages. However the checks are now spread across
two different places. Let us unify the handling of the THPs to
keep the code cleaner (and future proof for PUD THP support).
This patch moves transparent_hugepage_adjust() closer to the caller
to avoid a forward declaration for fault_supports_stage2_huge_mappings().
Also, since we already handle the case where the host VA and the guest
PA may not be aligned, the explicit VM_BUG_ON() is not required.
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Zenghui Yu <yuzenghui@huawei.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20200507123546.1875-3-yuzenghui@huawei.com
---
arch/arm64/kvm/mmu.c | 115 ++++++++++++++++++++++---------------------
1 file changed, 60 insertions(+), 55 deletions(-)
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index ccb44e7d30d9..66eb8e3f6e8c 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -1375,47 +1375,6 @@ int kvm_phys_addr_ioremap(struct kvm *kvm, phys_addr_t guest_ipa,
return ret;
}
-static bool transparent_hugepage_adjust(kvm_pfn_t *pfnp, phys_addr_t *ipap)
-{
- kvm_pfn_t pfn = *pfnp;
- gfn_t gfn = *ipap >> PAGE_SHIFT;
-
- if (kvm_is_transparent_hugepage(pfn)) {
- unsigned long mask;
- /*
- * The address we faulted on is backed by a transparent huge
- * page. However, because we map the compound huge page and
- * not the individual tail page, we need to transfer the
- * refcount to the head page. We have to be careful that the
- * THP doesn't start to split while we are adjusting the
- * refcounts.
- *
- * We are sure this doesn't happen, because mmu_notifier_retry
- * was successful and we are holding the mmu_lock, so if this
- * THP is trying to split, it will be blocked in the mmu
- * notifier before touching any of the pages, specifically
- * before being able to call __split_huge_page_refcount().
- *
- * We can therefore safely transfer the refcount from PG_tail
- * to PG_head and switch the pfn from a tail page to the head
- * page accordingly.
- */
- mask = PTRS_PER_PMD - 1;
- VM_BUG_ON((gfn & mask) != (pfn & mask));
- if (pfn & mask) {
- *ipap &= PMD_MASK;
- kvm_release_pfn_clean(pfn);
- pfn &= ~mask;
- kvm_get_pfn(pfn);
- *pfnp = pfn;
- }
-
- return true;
- }
-
- return false;
-}
-
/**
* stage2_wp_ptes - write protect PMD range
* @pmd: pointer to pmd entry
@@ -1663,6 +1622,59 @@ static bool fault_supports_stage2_huge_mapping(struct kvm_memory_slot *memslot,
(hva & ~(map_size - 1)) + map_size <= uaddr_end;
}
+/*
+ * Check if the given hva is backed by a transparent huge page (THP) and
+ * whether it can be mapped using block mapping in stage2. If so, adjust
+ * the stage2 PFN and IPA accordingly. Only PMD_SIZE THPs are currently
+ * supported. This will need to be updated to support other THP sizes.
+ *
+ * Returns the size of the mapping.
+ */
+static unsigned long
+transparent_hugepage_adjust(struct kvm_memory_slot *memslot,
+ unsigned long hva, kvm_pfn_t *pfnp,
+ phys_addr_t *ipap)
+{
+ kvm_pfn_t pfn = *pfnp;
+
+ /*
+ * Make sure the adjustment is done only for THP pages. Also make
+ * sure that the HVA and IPA are sufficiently aligned and that the
+ * block map is contained within the memslot.
+ */
+ if (kvm_is_transparent_hugepage(pfn) &&
+ fault_supports_stage2_huge_mapping(memslot, hva, PMD_SIZE)) {
+ /*
+ * The address we faulted on is backed by a transparent huge
+ * page. However, because we map the compound huge page and
+ * not the individual tail page, we need to transfer the
+ * refcount to the head page. We have to be careful that the
+ * THP doesn't start to split while we are adjusting the
+ * refcounts.
+ *
+ * We are sure this doesn't happen, because mmu_notifier_retry
+ * was successful and we are holding the mmu_lock, so if this
+ * THP is trying to split, it will be blocked in the mmu
+ * notifier before touching any of the pages, specifically
+ * before being able to call __split_huge_page_refcount().
+ *
+ * We can therefore safely transfer the refcount from PG_tail
+ * to PG_head and switch the pfn from a tail page to the head
+ * page accordingly.
+ */
+ *ipap &= PMD_MASK;
+ kvm_release_pfn_clean(pfn);
+ pfn &= ~(PTRS_PER_PMD - 1);
+ kvm_get_pfn(pfn);
+ *pfnp = pfn;
+
+ return PMD_SIZE;
+ }
+
+ /* Use page mapping if we cannot use block mapping. */
+ return PAGE_SIZE;
+}
+
static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
struct kvm_memory_slot *memslot, unsigned long hva,
unsigned long fault_status)
@@ -1776,20 +1788,13 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
if (mmu_notifier_retry(kvm, mmu_seq))
goto out_unlock;
- if (vma_pagesize == PAGE_SIZE && !force_pte) {
- /*
- * Only PMD_SIZE transparent hugepages(THP) are
- * currently supported. This code will need to be
- * updated to support other THP sizes.
- *
- * Make sure the host VA and the guest IPA are sufficiently
- * aligned and that the block is contained within the memslot.
- */
- if (fault_supports_stage2_huge_mapping(memslot, hva, PMD_SIZE) &&
- transparent_hugepage_adjust(&pfn, &fault_ipa))
- vma_pagesize = PMD_SIZE;
- }
-
+ /*
+ * If we are not forced to use page mapping, check if we are
+ * backed by a THP and thus use block mapping if possible.
+ */
+ if (vma_pagesize == PAGE_SIZE && !force_pte)
+ vma_pagesize = transparent_hugepage_adjust(memslot, hva,
+ &pfn, &fault_ipa);
if (writable)
kvm_set_pfn_dirty(pfn);
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-05-29 16:09 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-29 16:00 [GIT PULL] KVM/arm64 updates for Linux 5.8 Marc Zyngier
2020-05-29 16:00 ` [PATCH 01/24] KVM: arm64: Move virt/kvm/arm to arch/arm64 Marc Zyngier
2020-05-29 16:00 ` [PATCH 02/24] KVM: arm64: Kill off CONFIG_KVM_ARM_HOST Marc Zyngier
2020-05-29 16:01 ` [PATCH 03/24] KVM: arm64: Update help text Marc Zyngier
2020-05-29 16:01 ` [PATCH 04/24] KVM: arm64: Change CONFIG_KVM to a menuconfig entry Marc Zyngier
2020-05-29 16:01 ` [PATCH 05/24] KVM: arm64: Clean up kvm makefiles Marc Zyngier
2020-05-29 16:01 ` [PATCH 06/24] KVM: arm64: Simplify __kvm_timer_set_cntvoff implementation Marc Zyngier
2020-05-29 16:01 ` [PATCH 07/24] KVM: arm64: Use cpus_have_final_cap for has_vhe() Marc Zyngier
2020-05-29 16:01 ` [PATCH 08/24] KVM: Fix spelling in code comments Marc Zyngier
2020-05-29 16:01 ` [PATCH 09/24] KVM: arm64: Sidestep stage2_unmap_vm() on vcpu reset when S2FWB is supported Marc Zyngier
2020-05-29 16:01 ` [PATCH 10/24] KVM: arm/arm64: Release kvm->mmu_lock in loop to prevent starvation Marc Zyngier
2020-05-29 16:01 ` [PATCH 11/24] KVM: arm64: Clean up the checking for huge mapping Marc Zyngier
2020-05-29 16:01 ` Marc Zyngier [this message]
2020-05-29 16:01 ` [PATCH 13/24] KVM: arm64: Support enabling dirty log gradually in small chunks Marc Zyngier
2020-05-29 16:01 ` [PATCH 14/24] KVM: arm64: Make KVM_CAP_MAX_VCPUS compatible with the selected GIC version Marc Zyngier
2020-05-29 16:01 ` [PATCH 15/24] KVM: arm64: Clean up cpu_init_hyp_mode() Marc Zyngier
2020-05-29 16:01 ` [PATCH 16/24] KVM: arm64: Fix incorrect comment on kvm_get_hyp_vector() Marc Zyngier
2020-05-29 16:01 ` [PATCH 17/24] KVM: arm64: Remove obsolete kvm_virt_to_phys abstraction Marc Zyngier
2020-05-29 16:01 ` [PATCH 18/24] KVM: arm64: vgic-v3: Take cpu_if pointer directly instead of vcpu Marc Zyngier
2020-05-29 16:01 ` [PATCH 19/24] KVM: arm64: Refactor vcpu_{read,write}_sys_reg Marc Zyngier
2020-05-29 16:01 ` [PATCH 20/24] KVM: arm64: Add missing reset handlers for PMU emulation Marc Zyngier
2020-05-29 16:01 ` [PATCH 21/24] KVM: arm64: Move sysreg reset check to boot time Marc Zyngier
2020-05-29 16:01 ` [PATCH 22/24] KVM: arm64: Don't use empty structures as CPU reset state Marc Zyngier
2020-05-29 16:01 ` [PATCH 23/24] KVM: arm64: Parametrize exception entry with a target EL Marc Zyngier
2020-05-29 16:01 ` [PATCH 24/24] KVM: arm64: Drop obsolete comment about sys_reg ordering Marc Zyngier
2020-06-01 8:27 ` [GIT PULL] KVM/arm64 updates for Linux 5.8 Paolo Bonzini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200529160121.899083-13-maz@kernel.org \
--to=maz@kernel.org \
--cc=alexandru.elisei@arm.com \
--cc=ardb@kernel.org \
--cc=ascull@google.com \
--cc=christoffer.dall@arm.com \
--cc=dbrazdil@google.com \
--cc=giangyi@amazon.com \
--cc=james.morse@arm.com \
--cc=julien.thierry.kdev@gmail.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=mark.rutland@arm.com \
--cc=pbonzini@redhat.com \
--cc=suzuki.poulose@arm.com \
--cc=tabba@google.com \
--cc=will@kernel.org \
--cc=yuzenghui@huawei.com \
--cc=zhukeqian1@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).