From: Will Deacon <will@kernel.org>
To: kvmarm@lists.cs.columbia.edu
Cc: kernel-team@android.com, Marc Zyngier <maz@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
linux-arm-kernel@lists.infradead.org
Subject: [PATCH v5 21/21] KVM: arm64: Don't constrain maximum IPA size based on host configuration
Date: Fri, 11 Sep 2020 14:25:29 +0100 [thread overview]
Message-ID: <20200911132529.19844-22-will@kernel.org> (raw)
In-Reply-To: <20200911132529.19844-1-will@kernel.org>
Now that the guest stage-2 page-tables are managed independently from
the host stage-1 page-tables, we can avoid constraining the IPA size
based on the host and instead limit it only based on the PARange field
of the ID_AA64MMFR0 register.
Cc: Marc Zyngier <maz@kernel.org>
Cc: Quentin Perret <qperret@google.com>
Reviewed-by: Gavin Shan <gshan@redhat.com>
Signed-off-by: Will Deacon <will@kernel.org>
---
arch/arm64/kvm/reset.c | 40 ++++++----------------------------------
1 file changed, 6 insertions(+), 34 deletions(-)
diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
index ee33875c5c2a..2202b710d44c 100644
--- a/arch/arm64/kvm/reset.c
+++ b/arch/arm64/kvm/reset.c
@@ -339,7 +339,7 @@ u32 get_kvm_ipa_limit(void)
int kvm_set_ipa_limit(void)
{
- unsigned int ipa_max, pa_max, va_max, parange, tgran_2;
+ unsigned int parange, tgran_2;
u64 mmfr0;
mmfr0 = read_sanitised_ftr_reg(SYS_ID_AA64MMFR0_EL1);
@@ -376,39 +376,11 @@ int kvm_set_ipa_limit(void)
break;
}
- pa_max = id_aa64mmfr0_parange_to_phys_shift(parange);
-
- /* Clamp the IPA limit to the PA size supported by the kernel */
- ipa_max = (pa_max > PHYS_MASK_SHIFT) ? PHYS_MASK_SHIFT : pa_max;
- /*
- * Since our stage2 table is dependent on the stage1 page table code,
- * we must always honor the following condition:
- *
- * Number of levels in Stage1 >= Number of levels in Stage2.
- *
- * So clamp the ipa limit further down to limit the number of levels.
- * Since we can concatenate upto 16 tables at entry level, we could
- * go upto 4bits above the maximum VA addressable with the current
- * number of levels.
- */
- va_max = PGDIR_SHIFT + PAGE_SHIFT - 3;
- va_max += 4;
-
- if (va_max < ipa_max)
- ipa_max = va_max;
-
- /*
- * If the final limit is lower than the real physical address
- * limit of the CPUs, report the reason.
- */
- if (ipa_max < pa_max)
- pr_info("kvm: Limiting the IPA size due to kernel %s Address limit\n",
- (va_max < pa_max) ? "Virtual" : "Physical");
-
- WARN(ipa_max < KVM_PHYS_SHIFT,
- "KVM IPA limit (%d bit) is smaller than default size\n", ipa_max);
- kvm_ipa_limit = ipa_max;
- kvm_info("IPA Size Limit: %dbits\n", kvm_ipa_limit);
+ kvm_ipa_limit = id_aa64mmfr0_parange_to_phys_shift(parange);
+ WARN(kvm_ipa_limit < KVM_PHYS_SHIFT,
+ "KVM IPA Size Limit (%d bits) is smaller than default size\n",
+ kvm_ipa_limit);
+ kvm_info("IPA Size Limit: %d bits\n", kvm_ipa_limit);
return 0;
}
--
2.28.0.618.gf4bc123cb7-goog
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will@kernel.org>
To: kvmarm@lists.cs.columbia.edu
Cc: kernel-team@android.com, Gavin Shan <gshan@redhat.com>,
Suzuki Poulose <suzuki.poulose@arm.com>,
Marc Zyngier <maz@kernel.org>,
Quentin Perret <qperret@google.com>,
Alexandru Elisei <alexandru.elisei@arm.com>,
James Morse <james.morse@arm.com>,
Andrew Scull <ascull@google.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
linux-arm-kernel@lists.infradead.org
Subject: [PATCH v5 21/21] KVM: arm64: Don't constrain maximum IPA size based on host configuration
Date: Fri, 11 Sep 2020 14:25:29 +0100 [thread overview]
Message-ID: <20200911132529.19844-22-will@kernel.org> (raw)
In-Reply-To: <20200911132529.19844-1-will@kernel.org>
Now that the guest stage-2 page-tables are managed independently from
the host stage-1 page-tables, we can avoid constraining the IPA size
based on the host and instead limit it only based on the PARange field
of the ID_AA64MMFR0 register.
Cc: Marc Zyngier <maz@kernel.org>
Cc: Quentin Perret <qperret@google.com>
Reviewed-by: Gavin Shan <gshan@redhat.com>
Signed-off-by: Will Deacon <will@kernel.org>
---
arch/arm64/kvm/reset.c | 40 ++++++----------------------------------
1 file changed, 6 insertions(+), 34 deletions(-)
diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
index ee33875c5c2a..2202b710d44c 100644
--- a/arch/arm64/kvm/reset.c
+++ b/arch/arm64/kvm/reset.c
@@ -339,7 +339,7 @@ u32 get_kvm_ipa_limit(void)
int kvm_set_ipa_limit(void)
{
- unsigned int ipa_max, pa_max, va_max, parange, tgran_2;
+ unsigned int parange, tgran_2;
u64 mmfr0;
mmfr0 = read_sanitised_ftr_reg(SYS_ID_AA64MMFR0_EL1);
@@ -376,39 +376,11 @@ int kvm_set_ipa_limit(void)
break;
}
- pa_max = id_aa64mmfr0_parange_to_phys_shift(parange);
-
- /* Clamp the IPA limit to the PA size supported by the kernel */
- ipa_max = (pa_max > PHYS_MASK_SHIFT) ? PHYS_MASK_SHIFT : pa_max;
- /*
- * Since our stage2 table is dependent on the stage1 page table code,
- * we must always honor the following condition:
- *
- * Number of levels in Stage1 >= Number of levels in Stage2.
- *
- * So clamp the ipa limit further down to limit the number of levels.
- * Since we can concatenate upto 16 tables at entry level, we could
- * go upto 4bits above the maximum VA addressable with the current
- * number of levels.
- */
- va_max = PGDIR_SHIFT + PAGE_SHIFT - 3;
- va_max += 4;
-
- if (va_max < ipa_max)
- ipa_max = va_max;
-
- /*
- * If the final limit is lower than the real physical address
- * limit of the CPUs, report the reason.
- */
- if (ipa_max < pa_max)
- pr_info("kvm: Limiting the IPA size due to kernel %s Address limit\n",
- (va_max < pa_max) ? "Virtual" : "Physical");
-
- WARN(ipa_max < KVM_PHYS_SHIFT,
- "KVM IPA limit (%d bit) is smaller than default size\n", ipa_max);
- kvm_ipa_limit = ipa_max;
- kvm_info("IPA Size Limit: %dbits\n", kvm_ipa_limit);
+ kvm_ipa_limit = id_aa64mmfr0_parange_to_phys_shift(parange);
+ WARN(kvm_ipa_limit < KVM_PHYS_SHIFT,
+ "KVM IPA Size Limit (%d bits) is smaller than default size\n",
+ kvm_ipa_limit);
+ kvm_info("IPA Size Limit: %d bits\n", kvm_ipa_limit);
return 0;
}
--
2.28.0.618.gf4bc123cb7-goog
_______________________________________________
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-09-11 13:26 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-11 13:25 [PATCH v5 00/21] KVM: arm64: Rewrite page-table code and fault handling Will Deacon
2020-09-11 13:25 ` Will Deacon
2020-09-11 13:25 ` [PATCH v5 01/21] KVM: arm64: Remove kvm_mmu_free_memory_caches() Will Deacon
2020-09-11 13:25 ` Will Deacon
2020-09-11 13:25 ` [PATCH v5 02/21] KVM: arm64: Add stand-alone page-table walker infrastructure Will Deacon
2020-09-11 13:25 ` Will Deacon
2020-09-11 13:25 ` [PATCH v5 03/21] KVM: arm64: Add support for creating kernel-agnostic stage-1 page tables Will Deacon
2020-09-11 13:25 ` Will Deacon
2020-09-11 13:25 ` [PATCH v5 04/21] KVM: arm64: Use generic allocator for hyp stage-1 page-tables Will Deacon
2020-09-11 13:25 ` Will Deacon
2020-09-11 13:25 ` [PATCH v5 05/21] KVM: arm64: Add support for creating kernel-agnostic stage-2 page tables Will Deacon
2020-09-11 13:25 ` Will Deacon
2020-09-11 13:25 ` [PATCH v5 06/21] KVM: arm64: Add support for stage-2 map()/unmap() in generic page-table Will Deacon
2020-09-11 13:25 ` Will Deacon
2020-09-15 10:47 ` Alexandru Elisei
2020-09-15 10:47 ` Alexandru Elisei
2020-09-11 13:25 ` [PATCH v5 07/21] KVM: arm64: Convert kvm_phys_addr_ioremap() to generic page-table API Will Deacon
2020-09-11 13:25 ` Will Deacon
2020-09-11 13:25 ` [PATCH v5 08/21] KVM: arm64: Convert kvm_set_spte_hva() " Will Deacon
2020-09-11 13:25 ` Will Deacon
2020-09-11 13:25 ` [PATCH v5 09/21] KVM: arm64: Convert unmap_stage2_range() " Will Deacon
2020-09-11 13:25 ` Will Deacon
2020-09-15 10:57 ` Alexandru Elisei
2020-09-15 10:57 ` Alexandru Elisei
2020-09-11 13:25 ` [PATCH v5 10/21] KVM: arm64: Add support for stage-2 page-aging in generic page-table Will Deacon
2020-09-11 13:25 ` Will Deacon
2020-09-11 13:25 ` [PATCH v5 11/21] KVM: arm64: Convert page-aging and access faults to generic page-table API Will Deacon
2020-09-11 13:25 ` Will Deacon
2020-09-11 13:25 ` [PATCH v5 12/21] KVM: arm64: Add support for stage-2 write-protect in generic page-table Will Deacon
2020-09-11 13:25 ` Will Deacon
2020-09-11 13:25 ` [PATCH v5 13/21] KVM: arm64: Convert write-protect operation to generic page-table API Will Deacon
2020-09-11 13:25 ` Will Deacon
2020-09-11 13:25 ` [PATCH v5 14/21] KVM: arm64: Add support for stage-2 cache flushing in generic page-table Will Deacon
2020-09-11 13:25 ` Will Deacon
2020-09-11 13:25 ` [PATCH v5 15/21] KVM: arm64: Convert memslot cache-flushing code to generic page-table API Will Deacon
2020-09-11 13:25 ` Will Deacon
2020-09-11 13:25 ` [PATCH v5 16/21] KVM: arm64: Add support for relaxing stage-2 perms in generic page-table code Will Deacon
2020-09-11 13:25 ` Will Deacon
2020-09-15 16:16 ` Alexandru Elisei
2020-09-15 16:16 ` Alexandru Elisei
2020-09-11 13:25 ` [PATCH v5 17/21] KVM: arm64: Convert user_mem_abort() to generic page-table API Will Deacon
2020-09-11 13:25 ` Will Deacon
2020-09-11 13:25 ` [PATCH v5 18/21] KVM: arm64: Check the pgt instead of the pgd when modifying page-table Will Deacon
2020-09-11 13:25 ` Will Deacon
2020-09-11 13:25 ` [PATCH v5 19/21] KVM: arm64: Remove unused page-table code Will Deacon
2020-09-11 13:25 ` Will Deacon
2020-09-11 13:25 ` [PATCH v5 20/21] KVM: arm64: Remove unused 'pgd' field from 'struct kvm_s2_mmu' Will Deacon
2020-09-11 13:25 ` Will Deacon
2020-09-11 13:25 ` Will Deacon [this message]
2020-09-11 13:25 ` [PATCH v5 21/21] KVM: arm64: Don't constrain maximum IPA size based on host configuration Will Deacon
2020-09-11 15:04 ` [PATCH v5 00/21] KVM: arm64: Rewrite page-table code and fault handling Marc Zyngier
2020-09-11 15:04 ` Marc Zyngier
2020-10-01 10:21 ` Alexandru Elisei
2020-10-01 10:21 ` Alexandru Elisei
2020-10-01 12:28 ` Will Deacon
2020-10-01 12:28 ` Will Deacon
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=20200911132529.19844-22-will@kernel.org \
--to=will@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=kernel-team@android.com \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=maz@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.