From: Christoffer Dall <christoffer.dall@linaro.org>
To: Punit Agrawal <punit.agrawal@arm.com>
Cc: kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org,
Marc Zyngier <marc.zyngier@arm.com>
Subject: Re: [PATCH] KVM: arm/arm64: Check pagesize when allocating a hugepage at Stage 2
Date: Thu, 11 Jan 2018 13:15:42 +0100 [thread overview]
Message-ID: <20180111121542.GG15307@cbox> (raw)
In-Reply-To: <20180104182433.3790-1-punit.agrawal@arm.com>
On Thu, Jan 04, 2018 at 06:24:33PM +0000, Punit Agrawal wrote:
> KVM only supports PMD hugepages at stage 2 but doesn't actually check
> that the provided hugepage memory pagesize is PMD_SIZE before populating
> stage 2 entries.
>
> In cases where the backing hugepage size is smaller than PMD_SIZE (such
> as when using contiguous hugepages),
what are contiguous hugepages and how are they created vs. a normal
hugetlbfs? Is this a kernel config thing, or how does it work?
> KVM can end up creating stage 2
> mappings that extend beyond the supplied memory.
>
> Fix this by checking for the pagesize of userspace vma before creating
> PMD hugepage at stage 2.
>
> Fixes: ad361f093c1e31d ("KVM: ARM: Support hugetlbfs backed huge pages")
> Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
> Cc: Christoffer Dall <christoffer.dall@linaro.org>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> ---
> virt/kvm/arm/mmu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
> index b4b69c2d1012..9dea96380339 100644
> --- a/virt/kvm/arm/mmu.c
> +++ b/virt/kvm/arm/mmu.c
> @@ -1310,7 +1310,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> return -EFAULT;
> }
>
> - if (is_vm_hugetlb_page(vma) && !logging_active) {
> + if (vma_kernel_pagesize(vma) == PMD_SIZE && !logging_active) {
Don't we need to also fix this in kvm_send_hwpoison_signal?
(which probably implies this will then need a backport without that for
older stable kernels. Has this been an issue from the start or did we
add contiguous hugepage support at some point?)
> hugetlb = true;
> gfn = (fault_ipa & PMD_MASK) >> PAGE_SHIFT;
> } else {
> --
> 2.15.1
>
Thanks,
-Christoffer
next prev parent reply other threads:[~2018-01-11 12:15 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-04 18:24 [PATCH] KVM: arm/arm64: Check pagesize when allocating a hugepage at Stage 2 Punit Agrawal
2018-01-04 18:24 ` Punit Agrawal
2018-01-11 12:15 ` Christoffer Dall [this message]
2018-01-11 13:01 ` Punit Agrawal
2018-01-11 13:49 ` Christoffer Dall
2018-01-11 14:23 ` Punit Agrawal
2018-01-11 14:25 ` Christoffer Dall
2018-01-11 14:25 ` Christoffer Dall
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=20180111121542.GG15307@cbox \
--to=christoffer.dall@linaro.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=marc.zyngier@arm.com \
--cc=punit.agrawal@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.