linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Suzuki K Poulose <Suzuki.Poulose@arm.com>
To: Punit Agrawal <punit.agrawal@arm.com>
Cc: kvmarm@lists.cs.columbia.edu, marc.zyngier@arm.com,
	linux-kernel@vger.kernel.org, will.deacon@arm.com,
	Russell King <linux@armlinux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v5 7/7] KVM: arm64: Add support for creating PUD hugepages at stage 2
Date: Wed, 11 Jul 2018 17:13:54 +0100	[thread overview]
Message-ID: <fe8b92a1-2584-61ab-39e2-4d3247f92c7c@arm.com> (raw)
In-Reply-To: <87zhyxoize.fsf@e105922-lin.cambridge.arm.com>

On 11/07/18 17:05, Punit Agrawal wrote:
> Suzuki K Poulose <Suzuki.Poulose@arm.com> writes:
> 
>> On 09/07/18 15:41, Punit Agrawal wrote:
>>> KVM only supports PMD hugepages at stage 2. Now that the various page
>>> handling routines are updated, extend the stage 2 fault handling to
>>> map in PUD hugepages.
>>>
>>> Addition of PUD hugepage support enables additional page sizes (e.g.,
>>> 1G with 4K granule) which can be useful on cores that support mapping
>>> larger block sizes in the TLB entries.
>>>
>>> Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
>>> Cc: Christoffer Dall <christoffer.dall@arm.com>
>>> Cc: Marc Zyngier <marc.zyngier@arm.com>
>>> Cc: Russell King <linux@armlinux.org.uk>
>>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>>> Cc: Will Deacon <will.deacon@arm.com>
>>> ---
>>>    arch/arm/include/asm/kvm_mmu.h         | 19 +++++++
>>>    arch/arm64/include/asm/kvm_mmu.h       | 15 +++++
>>>    arch/arm64/include/asm/pgtable-hwdef.h |  2 +
>>>    arch/arm64/include/asm/pgtable.h       |  2 +
>>>    virt/kvm/arm/mmu.c                     | 78 ++++++++++++++++++++++++--
>>>    5 files changed, 112 insertions(+), 4 deletions(-)
>>>
> 
> [...]
> 
>>> diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
>>> index a6d3ac9d7c7a..d8e2497e5353 100644
>>> --- a/virt/kvm/arm/mmu.c
>>> +++ b/virt/kvm/arm/mmu.c
> 
> [...]
> 
>>> @@ -1100,6 +1139,7 @@ static int stage2_set_pte(struct kvm *kvm, struct kvm_mmu_memory_cache *cache,
>>>    			  phys_addr_t addr, const pte_t *new_pte,
>>>    			  unsigned long flags)
>>>    {
>>> +	pud_t *pud;
>>>    	pmd_t *pmd;
>>>    	pte_t *pte, old_pte;
>>>    	bool iomap = flags & KVM_S2PTE_FLAG_IS_IOMAP;
>>> @@ -1108,6 +1148,22 @@ static int stage2_set_pte(struct kvm *kvm, struct kvm_mmu_memory_cache *cache,
>>>    	VM_BUG_ON(logging_active && !cache);
>>>      	/* Create stage-2 page table mapping - Levels 0 and 1 */
>>> +	pud = stage2_get_pud(kvm, cache, addr);
>>> +	if (!pud) {
>>> +		/*
>>> +		 * Ignore calls from kvm_set_spte_hva for unallocated
>>> +		 * address ranges.
>>> +		 */
>>> +		return 0;
>>> +	}
>>> +
>>> +	/*
>>> +	 * While dirty page logging - dissolve huge PUD, then continue
>>> +	 * on to allocate page.
>>
>> Punit,
>>
>> We don't seem to allocate a page here for the PUD entry, in case if it is dissolved
>> or empty (i.e, stage2_pud_none(*pud) is true.).
> 
> I was trying to avoid duplicating the PUD allocation by reusing the
> functionality in stage2_get_pmd().
> 
> Does the below updated comment help?
> 
> 	/*
> 	 * While dirty page logging - dissolve huge PUD, it'll be
> 	 * allocated in stage2_get_pmd().
> 	 */
> 
> The other option is to duplicate the stage2_pud_none() case from
> stage2_get_pmd() here.

I think the explicit check for stage2_pud_none() suits better here.
That would make it explicit that we are tearing down the entries
from top to bottom. Also, we may be able to short cut for case
where we know we just allocated a PUD page and hence we need another
PMD level page.

Also, you are missing the comment about the assumption that stage2 PUD
level always exist with 4k fixed IPA.

Cheers
Suzuki

  reply	other threads:[~2018-07-11 16:14 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-09 14:38 [PATCH v5 0/7] KVM: Support PUD hugepages at stage 2 Punit Agrawal
2018-07-09 14:38 ` Punit Agrawal
2018-07-09 14:49   ` Punit Agrawal
2018-07-09 14:41 ` [PATCH v5 1/7] KVM: arm/arm64: Share common code in user_mem_abort() Punit Agrawal
2018-07-09 14:41   ` [PATCH v5 2/7] KVM: arm/arm64: Introduce helpers to manupulate page table entries Punit Agrawal
2018-07-11 13:00     ` Suzuki K Poulose
2018-07-11 16:10       ` Punit Agrawal
2018-07-09 14:41   ` [PATCH v5 3/7] KVM: arm64: Support dirty page tracking for PUD hugepages Punit Agrawal
2018-07-11 13:03     ` Suzuki K Poulose
2018-07-09 14:41   ` [PATCH v5 4/7] KVM: arm64: Support PUD hugepage in stage2_is_exec() Punit Agrawal
2018-07-11 13:41     ` Suzuki K Poulose
2018-07-11 15:05       ` Punit Agrawal
2018-07-09 14:41   ` [PATCH v5 5/7] KVM: arm64: Support handling access faults for PUD hugepages Punit Agrawal
2018-07-11 13:16     ` Suzuki K Poulose
2018-07-09 14:41   ` [PATCH v5 6/7] KVM: arm64: Update age handlers to support " Punit Agrawal
2018-07-11 13:23     ` Suzuki K Poulose
2018-07-09 14:41   ` [PATCH v5 7/7] KVM: arm64: Add support for creating PUD hugepages at stage 2 Punit Agrawal
2018-07-11 13:38     ` Suzuki K Poulose
2018-07-11 16:05       ` Punit Agrawal
2018-07-11 16:13         ` Suzuki K Poulose [this message]
2018-07-11 16:19           ` Punit Agrawal
2018-07-11 12:59   ` [PATCH v5 1/7] KVM: arm/arm64: Share common code in user_mem_abort() Suzuki K Poulose

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=fe8b92a1-2584-61ab-39e2-4d3247f92c7c@arm.com \
    --to=suzuki.poulose@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=marc.zyngier@arm.com \
    --cc=punit.agrawal@arm.com \
    --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;
as well as URLs for NNTP newsgroup(s).