From: Marc Zyngier <maz@kernel.org>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Alexandru Elisei <alexandru.elisei@arm.com>,
Andrew Jones <drjones@redhat.com>,
Eric Auger <eric.auger@redhat.com>, Gavin Shan <gshan@redhat.com>,
Steven Price <steven.price@arm.com>,
kernel-team@android.com, linux-arm-kernel@lists.infradead.org,
kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org,
stable@vger.kernel.org
Subject: [PATCH 7/9] KVM: arm64: Do not try to map PUDs when they are folded into PMD
Date: Fri, 4 Sep 2020 11:45:28 +0100 [thread overview]
Message-ID: <20200904104530.1082676-8-maz@kernel.org> (raw)
In-Reply-To: <20200904104530.1082676-1-maz@kernel.org>
For the obscure cases where PMD and PUD are the same size
(64kB pages with 42bit VA, for example, which results in only
two levels of page tables), we can't map anything as a PUD,
because there is... erm... no PUD to speak of. Everything is
either a PMD or a PTE.
So let's only try and map a PUD when its size is different from
that of a PMD.
Cc: stable@vger.kernel.org
Fixes: b8e0ba7c8bea ("KVM: arm64: Add support for creating PUD hugepages at stage 2")
Reported-by: Gavin Shan <gshan@redhat.com>
Reported-by: Eric Auger <eric.auger@redhat.com>
Reviewed-by: Alexandru Elisei <alexandru.elisei@arm.com>
Reviewed-by: Gavin Shan <gshan@redhat.com>
Tested-by: Gavin Shan <gshan@redhat.com>
Tested-by: Eric Auger <eric.auger@redhat.com>
Tested-by: Alexandru Elisei <alexandru.elisei@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/kvm/mmu.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 0121ef2c7c8d..16b8660ddbcc 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -1964,7 +1964,12 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
(fault_status == FSC_PERM &&
stage2_is_exec(mmu, fault_ipa, vma_pagesize));
- if (vma_pagesize == PUD_SIZE) {
+ /*
+ * If PUD_SIZE == PMD_SIZE, there is no real PUD level, and
+ * all we have is a 2-level page table. Trying to map a PUD in
+ * this case would be fatally wrong.
+ */
+ if (PUD_SIZE != PMD_SIZE && vma_pagesize == PUD_SIZE) {
pud_t new_pud = kvm_pfn_pud(pfn, mem_type);
new_pud = kvm_pud_mkhuge(new_pud);
--
2.27.0
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: kvm@vger.kernel.org, kernel-team@android.com,
stable@vger.kernel.org, Steven Price <steven.price@arm.com>,
kvmarm@lists.cs.columbia.edu,
linux-arm-kernel@lists.infradead.org
Subject: [PATCH 7/9] KVM: arm64: Do not try to map PUDs when they are folded into PMD
Date: Fri, 4 Sep 2020 11:45:28 +0100 [thread overview]
Message-ID: <20200904104530.1082676-8-maz@kernel.org> (raw)
In-Reply-To: <20200904104530.1082676-1-maz@kernel.org>
For the obscure cases where PMD and PUD are the same size
(64kB pages with 42bit VA, for example, which results in only
two levels of page tables), we can't map anything as a PUD,
because there is... erm... no PUD to speak of. Everything is
either a PMD or a PTE.
So let's only try and map a PUD when its size is different from
that of a PMD.
Cc: stable@vger.kernel.org
Fixes: b8e0ba7c8bea ("KVM: arm64: Add support for creating PUD hugepages at stage 2")
Reported-by: Gavin Shan <gshan@redhat.com>
Reported-by: Eric Auger <eric.auger@redhat.com>
Reviewed-by: Alexandru Elisei <alexandru.elisei@arm.com>
Reviewed-by: Gavin Shan <gshan@redhat.com>
Tested-by: Gavin Shan <gshan@redhat.com>
Tested-by: Eric Auger <eric.auger@redhat.com>
Tested-by: Alexandru Elisei <alexandru.elisei@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/kvm/mmu.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 0121ef2c7c8d..16b8660ddbcc 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -1964,7 +1964,12 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
(fault_status == FSC_PERM &&
stage2_is_exec(mmu, fault_ipa, vma_pagesize));
- if (vma_pagesize == PUD_SIZE) {
+ /*
+ * If PUD_SIZE == PMD_SIZE, there is no real PUD level, and
+ * all we have is a 2-level page table. Trying to map a PUD in
+ * this case would be fatally wrong.
+ */
+ if (PUD_SIZE != PMD_SIZE && vma_pagesize == PUD_SIZE) {
pud_t new_pud = kvm_pfn_pud(pfn, mem_type);
new_pud = kvm_pud_mkhuge(new_pud);
--
2.27.0
_______________________________________________
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: Marc Zyngier <maz@kernel.org>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Andrew Jones <drjones@redhat.com>, Gavin Shan <gshan@redhat.com>,
kvm@vger.kernel.org, kernel-team@android.com,
stable@vger.kernel.org, Steven Price <steven.price@arm.com>,
Eric Auger <eric.auger@redhat.com>,
Alexandru Elisei <alexandru.elisei@arm.com>,
kvmarm@lists.cs.columbia.edu,
linux-arm-kernel@lists.infradead.org
Subject: [PATCH 7/9] KVM: arm64: Do not try to map PUDs when they are folded into PMD
Date: Fri, 4 Sep 2020 11:45:28 +0100 [thread overview]
Message-ID: <20200904104530.1082676-8-maz@kernel.org> (raw)
In-Reply-To: <20200904104530.1082676-1-maz@kernel.org>
For the obscure cases where PMD and PUD are the same size
(64kB pages with 42bit VA, for example, which results in only
two levels of page tables), we can't map anything as a PUD,
because there is... erm... no PUD to speak of. Everything is
either a PMD or a PTE.
So let's only try and map a PUD when its size is different from
that of a PMD.
Cc: stable@vger.kernel.org
Fixes: b8e0ba7c8bea ("KVM: arm64: Add support for creating PUD hugepages at stage 2")
Reported-by: Gavin Shan <gshan@redhat.com>
Reported-by: Eric Auger <eric.auger@redhat.com>
Reviewed-by: Alexandru Elisei <alexandru.elisei@arm.com>
Reviewed-by: Gavin Shan <gshan@redhat.com>
Tested-by: Gavin Shan <gshan@redhat.com>
Tested-by: Eric Auger <eric.auger@redhat.com>
Tested-by: Alexandru Elisei <alexandru.elisei@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/kvm/mmu.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 0121ef2c7c8d..16b8660ddbcc 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -1964,7 +1964,12 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
(fault_status == FSC_PERM &&
stage2_is_exec(mmu, fault_ipa, vma_pagesize));
- if (vma_pagesize == PUD_SIZE) {
+ /*
+ * If PUD_SIZE == PMD_SIZE, there is no real PUD level, and
+ * all we have is a 2-level page table. Trying to map a PUD in
+ * this case would be fatally wrong.
+ */
+ if (PUD_SIZE != PMD_SIZE && vma_pagesize == PUD_SIZE) {
pud_t new_pud = kvm_pfn_pud(pfn, mem_type);
new_pud = kvm_pud_mkhuge(new_pud);
--
2.27.0
_______________________________________________
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-04 10:48 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-04 10:45 [GIT PULL] KVM/arm64 fixes for 5.9 Marc Zyngier
2020-09-04 10:45 ` Marc Zyngier
2020-09-04 10:45 ` Marc Zyngier
2020-09-04 10:45 ` [PATCH 1/9] KVM: arm64: pvtime: steal-time is only supported when configured Marc Zyngier
2020-09-04 10:45 ` Marc Zyngier
2020-09-04 10:45 ` Marc Zyngier
2020-09-04 10:45 ` [PATCH 2/9] KVM: arm64: pvtime: Fix potential loss of stolen time Marc Zyngier
2020-09-04 10:45 ` Marc Zyngier
2020-09-04 10:45 ` Marc Zyngier
2020-09-04 10:45 ` [PATCH 3/9] KVM: arm64: Drop type input from kvm_put_guest Marc Zyngier
2020-09-04 10:45 ` Marc Zyngier
2020-09-04 10:45 ` Marc Zyngier
2020-09-04 10:45 ` [PATCH 4/9] KVM: arm64: pvtime: Fix stolen time accounting across migration Marc Zyngier
2020-09-04 10:45 ` Marc Zyngier
2020-09-04 10:45 ` Marc Zyngier
2020-09-04 10:45 ` [PATCH 5/9] KVM: Documentation: Minor fixups Marc Zyngier
2020-09-04 10:45 ` Marc Zyngier
2020-09-04 10:45 ` Marc Zyngier
2020-09-04 10:45 ` [PATCH 6/9] arm64/x86: KVM: Introduce steal-time cap Marc Zyngier
2020-09-04 10:45 ` Marc Zyngier
2020-09-04 10:45 ` Marc Zyngier
2020-09-04 10:45 ` Marc Zyngier [this message]
2020-09-04 10:45 ` [PATCH 7/9] KVM: arm64: Do not try to map PUDs when they are folded into PMD Marc Zyngier
2020-09-04 10:45 ` Marc Zyngier
2020-09-09 3:23 ` Punit Agrawal
2020-09-09 3:23 ` Punit Agrawal
2020-09-09 3:23 ` Punit Agrawal
2020-09-04 10:45 ` [PATCH 8/9] KVM: arm64: Fix address truncation in traces Marc Zyngier
2020-09-04 10:45 ` Marc Zyngier
2020-09-04 10:45 ` Marc Zyngier
2020-09-04 10:45 ` [PATCH 9/9] KVM: arm64: Update page shift if stage 2 block mapping not supported Marc Zyngier
2020-09-04 10:45 ` Marc Zyngier
2020-09-04 10:45 ` Marc Zyngier
2020-09-09 15:20 ` [GIT PULL] KVM/arm64 fixes for 5.9 Paolo Bonzini
2020-09-09 15:20 ` Paolo Bonzini
2020-09-09 15:20 ` Paolo Bonzini
2020-09-09 17:15 ` Marc Zyngier
2020-09-09 17:15 ` Marc Zyngier
2020-09-09 17:15 ` Marc Zyngier
2020-09-09 17:20 ` Paolo Bonzini
2020-09-09 17:20 ` Paolo Bonzini
2020-09-09 17:20 ` 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=20200904104530.1082676-8-maz@kernel.org \
--to=maz@kernel.org \
--cc=alexandru.elisei@arm.com \
--cc=drjones@redhat.com \
--cc=eric.auger@redhat.com \
--cc=gshan@redhat.com \
--cc=kernel-team@android.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=pbonzini@redhat.com \
--cc=stable@vger.kernel.org \
--cc=steven.price@arm.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 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.