From: Punit Agrawal <punit.agrawal@arm.com>
To: Christoffer Dall <christoffer.dall@arm.com>
Cc: marc.zyngier@arm.com, will.deacon@arm.com,
linux-kernel@vger.kernel.org, stable@vger.kernel.org,
kvmarm@lists.cs.columbia.edu,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v8 1/9] KVM: arm/arm64: Ensure only THP is candidate for adjustment
Date: Wed, 31 Oct 2018 17:15:10 +0000 [thread overview]
Message-ID: <87d0rqrqap.fsf@e105922-lin.cambridge.arm.com> (raw)
In-Reply-To: <87h8h2rwwr.fsf@e105922-lin.cambridge.arm.com> (Punit Agrawal's message of "Wed, 31 Oct 2018 14:52:20 +0000")
Punit Agrawal <punit.agrawal@arm.com> writes:
> Christoffer Dall <christoffer.dall@arm.com> writes:
>
>> On Mon, Oct 01, 2018 at 04:54:35PM +0100, Punit Agrawal wrote:
>>> PageTransCompoundMap() returns true for hugetlbfs and THP
>>> hugepages. This behaviour incorrectly leads to stage 2 faults for
>>> unsupported hugepage sizes (e.g., 64K hugepage with 4K pages) to be
>>> treated as THP faults.
>>>
>>> Tighten the check to filter out hugetlbfs pages. This also leads to
>>> consistently mapping all unsupported hugepage sizes as PTE level
>>> entries at stage 2.
>>>
>>> Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
>>> Reviewed-by: Suzuki Poulose <suzuki.poulose@arm.com>
>>> Cc: Christoffer Dall <christoffer.dall@arm.com>
>>> Cc: Marc Zyngier <marc.zyngier@arm.com>
>>> Cc: stable@vger.kernel.org # v4.13+
>>
>>
>> Hmm, this function is only actually called from user_mem_abort() if we
>> have (!hugetlb), so I'm not sure the cc stable here was actually
>> warranted, nor that this patch is strictly necessary.
>>
>> It doesn't hurt, and makes the code potentially more robust for the
>> future though.
>>
>> Am I missing something?
>
> !hugetlb is only true for hugepage sizes supported at stage 2.
Of course I meant "hugetlb" above (Note the lack of "!").
> The function also got called for unsupported hugepage size at stage 2,
> e.g., 64k hugepage with 4k page size, which then ended up doing the
> wrong thing.
>
> Hope that adds some context. I should've added this to the commit log.
>
>>
>> Thanks,
>>
>> Christoffer
>>
>>> ---
>>> virt/kvm/arm/mmu.c | 8 +++++++-
>>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
>>> index 7e477b3cae5b..c23a1b323aad 100644
>>> --- a/virt/kvm/arm/mmu.c
>>> +++ b/virt/kvm/arm/mmu.c
>>> @@ -1231,8 +1231,14 @@ static bool transparent_hugepage_adjust(kvm_pfn_t *pfnp, phys_addr_t *ipap)
>>> {
>>> kvm_pfn_t pfn = *pfnp;
>>> gfn_t gfn = *ipap >> PAGE_SHIFT;
>>> + struct page *page = pfn_to_page(pfn);
>>>
>>> - if (PageTransCompoundMap(pfn_to_page(pfn))) {
>>> + /*
>>> + * PageTransCompoungMap() returns true for THP and
>>> + * hugetlbfs. Make sure the adjustment is done only for THP
>>> + * pages.
>>> + */
>>> + if (!PageHuge(page) && PageTransCompoundMap(page)) {
>>> unsigned long mask;
>>> /*
>>> * The address we faulted on is backed by a transparent huge
>>> --
>>> 2.18.0
>>>
> _______________________________________________
> kvmarm mailing list
> kvmarm@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
next prev parent reply other threads:[~2018-10-31 17:15 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-01 15:54 [PATCH v8 0/9] KVM: Support PUD hugepage at stage 2 Punit Agrawal
2018-10-01 15:54 ` [PATCH v8 1/9] KVM: arm/arm64: Ensure only THP is candidate for adjustment Punit Agrawal
2018-10-03 10:50 ` Marc Zyngier
2018-10-03 10:59 ` Punit Agrawal
2018-10-31 14:36 ` Christoffer Dall
2018-10-31 14:52 ` Punit Agrawal
2018-10-31 17:15 ` Punit Agrawal [this message]
2018-11-01 8:31 ` Christoffer Dall
2018-10-01 15:54 ` [PATCH v8 2/9] KVM: arm/arm64: Share common code in user_mem_abort() Punit Agrawal
2018-10-01 17:44 ` Suzuki K Poulose
2018-10-03 15:20 ` Marc Zyngier
2018-10-03 16:25 ` Punit Agrawal
2018-10-01 15:54 ` [PATCH v8 3/9] KVM: arm/arm64: Re-factor setting the Stage 2 entry to exec on fault Punit Agrawal
2018-10-01 15:54 ` [PATCH v8 4/9] KVM: arm/arm64: Introduce helpers to manipulate page table entries Punit Agrawal
2018-10-01 15:54 ` [PATCH v8 5/9] KVM: arm64: Support dirty page tracking for PUD hugepages Punit Agrawal
2018-10-01 15:54 ` [PATCH v8 6/9] KVM: arm64: Support PUD hugepage in stage2_is_exec() Punit Agrawal
2018-10-01 15:54 ` [PATCH v8 7/9] KVM: arm64: Support handling access faults for PUD hugepages Punit Agrawal
2018-10-01 15:54 ` [PATCH v8 8/9] KVM: arm64: Update age handlers to support " Punit Agrawal
2018-10-01 15:54 ` [PATCH v8 9/9] KVM: arm64: Add support for creating PUD hugepages at stage 2 Punit Agrawal
2018-10-01 21:30 ` Suzuki K Poulose
2018-10-02 8:52 ` Punit Agrawal
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=87d0rqrqap.fsf@e105922-lin.cambridge.arm.com \
--to=punit.agrawal@arm.com \
--cc=christoffer.dall@arm.com \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marc.zyngier@arm.com \
--cc=stable@vger.kernel.org \
--cc=will.deacon@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox