public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Punit Agrawal <punit.agrawal@arm.com>
To: Christoffer Dall <christoffer.dall@linaro.org>
Cc: kvmarm@lists.cs.columbia.edu,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, suzuki.poulose@arm.com,
	Marc Zyngier <marc.zyngier@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>
Subject: Re: [RFC 4/4] KVM: arm64: Add support for PUD hugepages at stage 2
Date: Tue, 06 Feb 2018 18:13:38 +0000	[thread overview]
Message-ID: <87bmh2htpp.fsf@e105922-lin.cambridge.arm.com> (raw)
In-Reply-To: <20180206145501.GB23160@cbox> (Christoffer Dall's message of "Tue, 6 Feb 2018 15:55:01 +0100")

Christoffer Dall <christoffer.dall@linaro.org> writes:

> On Wed, Jan 10, 2018 at 07:07:29PM +0000, Punit Agrawal wrote:
>> KVM only supports PMD hugepages at stage 2. Extend the stage 2 fault
>> handling to add support for PUD hugepages.
>> 
>> Addition of PUD hugpage support enables additional hugepage sizes (1G
>
>                  *hugepage
>
>> with 4K granule and 4TB with 64k granule) which can be useful on cores
>> that have support for mapping larger block sizes in the TLB entries.
>> 
>> Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
>> Cc: Marc Zyngier <marc.zyngier@arm.com>
>> Cc: Christoffer Dall <christoffer.dall@linaro.org>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> ---
>>  arch/arm/include/asm/kvm_mmu.h         | 10 +++++
>>  arch/arm/include/asm/pgtable-3level.h  |  2 +
>>  arch/arm64/include/asm/kvm_mmu.h       | 19 +++++++++
>>  arch/arm64/include/asm/pgtable-hwdef.h |  2 +
>>  arch/arm64/include/asm/pgtable.h       |  4 ++
>>  virt/kvm/arm/mmu.c                     | 72 +++++++++++++++++++++++++++++-----
>>  6 files changed, 99 insertions(+), 10 deletions(-)
>> 

[...]

>> diff --git a/arch/arm/include/asm/pgtable-3level.h b/arch/arm/include/asm/pgtable-3level.h
>> index 1a7a17b2a1ba..97e04fdbfa85 100644
>> --- a/arch/arm/include/asm/pgtable-3level.h
>> +++ b/arch/arm/include/asm/pgtable-3level.h
>> @@ -249,6 +249,8 @@ PMD_BIT_FUNC(mkyoung,   |= PMD_SECT_AF);
>>  #define pfn_pmd(pfn,prot)	(__pmd(((phys_addr_t)(pfn) << PAGE_SHIFT) | pgprot_val(prot)))
>>  #define mk_pmd(page,prot)	pfn_pmd(page_to_pfn(page),prot)
>>  
>> +#define pud_pfn(pud)		(((pud_val(pud) & PUD_MASK) & PHYS_MASK) >> PAGE_SHIFT)
>> +
>
> does this make sense on 32-bit arm?  Is this ever going to get called
> and return something meaningful in that case?

This macro should never get called as there are no PUD_SIZE hugepages on
arm.

Ideally we want to fold the pud to fallback to pgd like in the rest of
the code. I'll have another go at this.

>
>>  /* represent a notpresent pmd by faulting entry, this is used by pmdp_invalidate */
>>  static inline pmd_t pmd_mknotpresent(pmd_t pmd)
>>  {

[...]


>> @@ -1393,17 +1424,38 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
>>  	if (mmu_notifier_retry(kvm, mmu_seq))
>>  		goto out_unlock;
>>  
>> -	if (!hugetlb && !force_pte)
>> +	if (!hugetlb && !force_pte) {
>> +		/*
>> +		 * We only support PMD_SIZE transparent
>> +		 * hugepages. This code will need updates if we enable
>> +		 * other page sizes for THP.
>> +		 */
>>  		hugetlb = transparent_hugepage_adjust(&pfn, &fault_ipa);
>> +		vma_pagesize = PMD_SIZE;
>> +	}
>>  
>>  	if (hugetlb) {
>> -		pmd_t new_pmd = stage2_build_pmd(pfn, mem_type, writable);
>> -
>> -		if (writable)
>> -			kvm_set_pfn_dirty(pfn);
>> -
>> -		coherent_cache_guest_page(vcpu, pfn, PMD_SIZE);
>> -		ret = stage2_set_pmd_huge(kvm, memcache, fault_ipa, &new_pmd);
>> +		if (vma_pagesize == PUD_SIZE) {
>> +			pud_t new_pud;
>> +
>> +			new_pud = stage2_build_pud(pfn, mem_type, writable);
>> +			if (writable)
>> +				kvm_set_pfn_dirty(pfn);
>> +
>> +			coherent_cache_guest_page(vcpu, pfn, PUD_SIZE);
>> +			ret = stage2_set_pud_huge(kvm, memcache,
>> +						  fault_ipa, &new_pud);
>> +		} else {
>> +			pmd_t new_pmd;
>> +
>> +			new_pmd = stage2_build_pmd(pfn, mem_type, writable);
>> +			if (writable)
>> +				kvm_set_pfn_dirty(pfn);
>> +
>> +			coherent_cache_guest_page(vcpu, pfn, PMD_SIZE);
>> +			ret = stage2_set_pmd_huge(kvm, memcache,
>> +						  fault_ipa, &new_pmd);
>> +		}
>
> This stuff needs rebasing onto v4.16-rc1 when we get there, and it will
> clash with Marc's icache optimizations.

Thanks for the heads up.

>
> But, you should be able to move kvm_set_pfn_dirty() out of the
> size-conditional section and also call the cache maintenance functions
> using vma_pagesize as parameter.

Agreed - I'll roll these suggestions into the next version.

Thanks a lot for the review.

Punit

      reply	other threads:[~2018-02-06 18:13 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-10 19:07 [RFC 0/4] KVM: Support PUD hugepages at stage 2 Punit Agrawal
2018-01-10 19:07 ` [RFC 1/4] arm64: Correct type for PUD macros Punit Agrawal
2018-01-16 11:17   ` Catalin Marinas
2018-01-16 11:39     ` Punit Agrawal
2018-01-10 19:07 ` [RFC 2/4] KVM: arm64: Support dirty page tracking for PUD hugepages Punit Agrawal
2018-02-06 14:55   ` Christoffer Dall
2018-02-06 18:13     ` Punit Agrawal
2018-01-10 19:07 ` [RFC 3/4] KVM: arm/arm64: Refactor Stage2 PMD hugepages support Punit Agrawal
2018-01-10 19:07 ` [RFC 4/4] KVM: arm64: Add support for PUD hugepages at stage 2 Punit Agrawal
2018-02-06 14:55   ` Christoffer Dall
2018-02-06 18:13     ` Punit Agrawal [this message]

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=87bmh2htpp.fsf@e105922-lin.cambridge.arm.com \
    --to=punit.agrawal@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=christoffer.dall@linaro.org \
    --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=suzuki.poulose@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