Thread (19 messages) read the whole thread 19 messages, 3 authors, 2021-03-23

Re: [PATCH 1/7] KVM: arm64: Add two page mapping counters for kvm_stat

From: Marc Zyngier <maz@kernel.org>
Date: 2021-03-23 17:04:48
Also in: kvmarm

On Tue, 23 Mar 2021 11:52:38 +0000,
Keqian Zhu [off-list ref] wrote:
Hi Yoan,

On 2021/3/20 0:17, Yoan Picchi wrote:
quoted
Add a counter for when a regular page is mapped, and another
for when a huge page is mapped.

Signed-off-by: Yoan Picchi <redacted>
---
 arch/arm64/include/asm/kvm_host.h | 2 ++
 arch/arm64/kvm/guest.c            | 2 ++
 arch/arm64/kvm/mmu.c              | 7 +++++++
 3 files changed, 11 insertions(+)
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 3d10e6527..863603285 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -561,6 +561,8 @@ struct kvm_vcpu_stat {
 	u64 wfi_exit_stat;
 	u64 mmio_exit_user;
 	u64 mmio_exit_kernel;
+	u64 regular_page_mapped;
+	u64 huge_page_mapped;
 	u64 exits;
 };
 
diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
index 9bbd30e62..14b15fb8f 100644
--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -38,6 +38,8 @@ struct kvm_stats_debugfs_item debugfs_entries[] = {
 	VCPU_STAT("wfi_exit_stat", wfi_exit_stat),
 	VCPU_STAT("mmio_exit_user", mmio_exit_user),
 	VCPU_STAT("mmio_exit_kernel", mmio_exit_kernel),
+	VCPU_STAT("regular_page_mapped", regular_page_mapped),
+	VCPU_STAT("huge_page_mapped", huge_page_mapped),
 	VCPU_STAT("exits", exits),
 	VCPU_STAT("halt_poll_success_ns", halt_poll_success_ns),
 	VCPU_STAT("halt_poll_fail_ns", halt_poll_fail_ns),
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 77cb2d28f..3996b28da 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -914,6 +914,13 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
 		mark_page_dirty(kvm, gfn);
 	}
 
+	if (ret >= 0) {
+		if (vma_pagesize == PAGE_SIZE) {
+			vcpu->stat.regular_page_mapped++;
+		} else {
+			vcpu->stat.huge_page_mapped++;
+		}
+	}
This looks too simple, as we don't always map a new regular_page or
huge_page here.  We may just relax permission or change mapping
size, etc. If we mix these operations, the stat result seems not
very valuable...
I can only agree. There is no such thing as a *huge page*. We have a
whole gamut of block mappings depending on the base granule size, and
we even have concatenation of pages/blocks (not yet implemented at S2,
but there is hope...).

What is this trying to express?

Thanks,

	M.

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help