linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christoffer Dall <christoffer.dall@linaro.org>
To: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, kvmarm@lists.cs.columbia.edu,
	kvm@vger.kernel.org, marc.zyngier@arm.com, mark.rutland@arm.com,
	will.deacon@arm.com, catalin.marinas@arm.com
Subject: Re: [PATCH 12/17] kvm-arm: Add explicit hyp page table modifiers
Date: Fri, 8 Apr 2016 15:15:37 +0200	[thread overview]
Message-ID: <20160408131537.GR8961@cbox> (raw)
In-Reply-To: <1459787177-12767-13-git-send-email-suzuki.poulose@arm.com>

On Mon, Apr 04, 2016 at 05:26:12PM +0100, Suzuki K Poulose wrote:
> We have common routines to modify hyp and stage2 page tables
> based on the 'kvm' parameter. For a smoother transition to
> using separate routines for each, duplicate the routines
> and modify the copy to work on hyp.
> 
> Marks the forked routines with _hyp_ and gets rid of the
> kvm parameter which is no longer needed and is NULL for hyp.
> Also, gets rid of calls to kvm_tlb_flush_by_vmid_ipa() calls
> from the hyp versions. Uses explicit host page table accessors
> instead of the kvm_* page table helpers.
> 
> Suggested-by: Christoffer Dall <christoffer.dall@linaro.org>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> ---
>  arch/arm/kvm/mmu.c |  123 +++++++++++++++++++++++++++++++++++++++++++++++++---
>  1 file changed, 118 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
> index b46a337..2b491e5 100644
> --- a/arch/arm/kvm/mmu.c
> +++ b/arch/arm/kvm/mmu.c
> @@ -388,6 +388,119 @@ static void stage2_flush_vm(struct kvm *kvm)
>  	srcu_read_unlock(&kvm->srcu, idx);
>  }
>  
> +static void clear_hyp_pgd_entry(pgd_t *pgd)
> +{
> +	pud_t *pud_table __maybe_unused = pud_offset(pgd, 0UL);
> +	pgd_clear(pgd);
> +	pud_free(NULL, pud_table);
> +	put_page(virt_to_page(pgd));
> +}
> +
> +static void clear_hyp_pud_entry(pud_t *pud)
> +{
> +	pmd_t *pmd_table __maybe_unused = pmd_offset(pud, 0);
> +	VM_BUG_ON(pud_huge(*pud));
> +	pud_clear(pud);
> +	pmd_free(NULL, pmd_table);
> +	put_page(virt_to_page(pud));
> +}
> +
> +static void clear_hyp_pmd_entry(pmd_t *pmd)
> +{
> +	pte_t *pte_table = pte_offset_kernel(pmd, 0);
> +	VM_BUG_ON(pmd_thp_or_huge(*pmd));
> +	pmd_clear(pmd);
> +	pte_free_kernel(NULL, pte_table);
> +	put_page(virt_to_page(pmd));
> +}
> +
> +static void unmap_hyp_ptes(pmd_t *pmd, phys_addr_t addr, phys_addr_t end)
> +{
> +	pte_t *pte, *start_pte;
> +
> +	start_pte = pte = pte_offset_kernel(pmd, addr);
> +	do {
> +		if (!pte_none(*pte)) {
> +			pte_t old_pte = *pte;
> +
> +			kvm_set_pte(pte, __pte(0));
> +
> +			/* XXX: Do we need to invalidate the cache for device mappings ? */

no, we will not be swapping out any pages mapped in Hyp mode so you can
get rid of both of the following two lines.

> +			if (!kvm_is_device_pfn(pte_pfn(old_pte)))
> +				kvm_flush_dcache_pte(old_pte);
> +
> +			put_page(virt_to_page(pte));
> +		}
> +	} while (pte++, addr += PAGE_SIZE, addr != end);
> +
> +	if (hyp_pte_table_empty(start_pte))
> +		clear_hyp_pmd_entry(pmd);
> +}
> +
> +static void unmap_hyp_pmds(pud_t *pud, phys_addr_t addr, phys_addr_t end)
> +{
> +	phys_addr_t next;
> +	pmd_t *pmd, *start_pmd;
> +
> +	start_pmd = pmd = pmd_offset(pud, addr);
> +	do {
> +		next = pmd_addr_end(addr, end);
> +		if (!pmd_none(*pmd)) {
> +			if (pmd_thp_or_huge(*pmd)) {

do we ever actually map anything with section mappings in the Hyp
mappings?

> +				pmd_t old_pmd = *pmd;
> +
> +				pmd_clear(pmd);
> +				kvm_flush_dcache_pmd(old_pmd);
> +				put_page(virt_to_page(pmd));
> +			} else {
> +				unmap_hyp_ptes(pmd, addr, next);
> +			}
> +		}
> +	} while (pmd++, addr = next, addr != end);
> +
> +	if (hyp_pmd_table_empty(start_pmd))
> +		clear_hyp_pud_entry(pud);
> +}
> +
> +static void unmap_hyp_puds(pgd_t *pgd, phys_addr_t addr, phys_addr_t end)
> +{
> +	phys_addr_t next;
> +	pud_t *pud, *start_pud;
> +
> +	start_pud = pud = pud_offset(pgd, addr);
> +	do {
> +		next = pud_addr_end(addr, end);
> +		if (!pud_none(*pud)) {
> +			if (pud_huge(*pud)) {

do we ever actually map anything with huge pud
mappings for the Hyp space?

> +				pud_t old_pud = *pud;
> +
> +				pud_clear(pud);
> +				kvm_flush_dcache_pud(old_pud);
> +				put_page(virt_to_page(pud));
> +			} else {
> +				unmap_hyp_pmds(pud, addr, next);
> +			}
> +		}
> +	} while (pud++, addr = next, addr != end);
> +
> +	if (hyp_pud_table_empty(start_pud))
> +		clear_hyp_pgd_entry(pgd);
> +}
> +
> +static void unmap_hyp_range(pgd_t *pgdp, phys_addr_t start, u64 size)
> +{
> +	pgd_t *pgd;
> +	phys_addr_t addr = start, end = start + size;
> +	phys_addr_t next;
> +
> +	pgd = pgdp + pgd_index(addr);
> +	do {
> +		next = pgd_addr_end(addr, end);
> +		if (!pgd_none(*pgd))
> +			unmap_hyp_puds(pgd, addr, next);
> +	} while (pgd++, addr = next, addr != end);

shouldn't we flush the EL2 (hyp) TLB here, strictly speaking?

Or do we rely on all mappings ever created/torn down here to always have
the same VA/PA relationship?  Since we didn't flush the EL2 TLB in the
existing code, that indeed does seem to be the case.

That, in turn, raises the question why we don't simply map all pages
that could be referenced by a kmalloc() in Hyp mode during the init
phase and be done with all this hyp mapping/unmapping stuff?

In any case, that behavior doesn't have to change now, but if we don't
add a TLB flush here, I'd like a comment to explain why that's not
needed.

> +}
> +
>  /**
>   * free_boot_hyp_pgd - free HYP boot page tables
>   *
> @@ -398,14 +511,14 @@ void free_boot_hyp_pgd(void)
>  	mutex_lock(&kvm_hyp_pgd_mutex);
>  
>  	if (boot_hyp_pgd) {
> -		unmap_range(NULL, boot_hyp_pgd, hyp_idmap_start, PAGE_SIZE);
> -		unmap_range(NULL, boot_hyp_pgd, TRAMPOLINE_VA, PAGE_SIZE);
> +		unmap_hyp_range(boot_hyp_pgd, hyp_idmap_start, PAGE_SIZE);
> +		unmap_hyp_range(boot_hyp_pgd, TRAMPOLINE_VA, PAGE_SIZE);
>  		free_pages((unsigned long)boot_hyp_pgd, hyp_pgd_order);
>  		boot_hyp_pgd = NULL;
>  	}
>  
>  	if (hyp_pgd)
> -		unmap_range(NULL, hyp_pgd, TRAMPOLINE_VA, PAGE_SIZE);
> +		unmap_hyp_range(hyp_pgd, TRAMPOLINE_VA, PAGE_SIZE);
>  
>  	mutex_unlock(&kvm_hyp_pgd_mutex);
>  }
> @@ -430,9 +543,9 @@ void free_hyp_pgds(void)
>  
>  	if (hyp_pgd) {
>  		for (addr = PAGE_OFFSET; virt_addr_valid(addr); addr += PGDIR_SIZE)
> -			unmap_range(NULL, hyp_pgd, KERN_TO_HYP(addr), PGDIR_SIZE);
> +			unmap_hyp_range(hyp_pgd, KERN_TO_HYP(addr), PGDIR_SIZE);
>  		for (addr = VMALLOC_START; is_vmalloc_addr((void*)addr); addr += PGDIR_SIZE)
> -			unmap_range(NULL, hyp_pgd, KERN_TO_HYP(addr), PGDIR_SIZE);
> +			unmap_hyp_range(hyp_pgd, KERN_TO_HYP(addr), PGDIR_SIZE);
>  
>  		free_pages((unsigned long)hyp_pgd, hyp_pgd_order);
>  		hyp_pgd = NULL;
> -- 
> 1.7.9.5
> 

Otherwise looks good!

I'm quite happy to see the hyp/stage2 stuff decoupled.

Thanks,
-Christoffer

  reply	other threads:[~2016-04-08 13:15 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-04 16:26 [PATCH 00/17] kvm-arm: Add stage2 page table walker Suzuki K Poulose
2016-04-04 16:26 ` [PATCH 01/17] arm64: Reuse TCR field definitions for EL1 and EL2 Suzuki K Poulose
2016-04-08 12:43   ` Christoffer Dall
2016-04-04 16:26 ` [PATCH 02/17] arm64: Cleanup VTCR_EL2 and VTTBR field values Suzuki K Poulose
2016-04-08 12:43   ` Christoffer Dall
2016-04-08 12:45     ` Suzuki K Poulose
2016-04-04 16:26 ` [PATCH 03/17] kvm arm: Move fake PGD handling to arch specific files Suzuki K Poulose
2016-04-04 16:26 ` [PATCH 04/17] arm64: Introduce pmd_thp_or_huge Suzuki K Poulose
2016-04-08 12:43   ` Christoffer Dall
2016-04-04 16:26 ` [PATCH 05/17] kvm-arm: Replace kvm_pmd_huge with pmd_thp_or_huge Suzuki K Poulose
2016-04-08 12:43   ` Christoffer Dall
2016-04-04 16:26 ` [PATCH 06/17] kvm-arm: Remove kvm_pud_huge() Suzuki K Poulose
2016-04-08 12:44   ` Christoffer Dall
2016-04-04 16:26 ` [PATCH 07/17] kvm-arm: arm32: Introduce stage2 page table helpers Suzuki K Poulose
2016-04-08 12:43   ` Christoffer Dall
2016-04-08 14:39     ` Suzuki K Poulose
2016-04-04 16:26 ` [PATCH 08/17] kvm-arm: arm: Introduce hyp page table empty checks Suzuki K Poulose
2016-04-08 13:15   ` Christoffer Dall
2016-04-04 16:26 ` [PATCH 09/17] kvm-arm: arm64: Introduce stage2 page table helpers Suzuki K Poulose
2016-04-08 13:15   ` Christoffer Dall
2016-04-04 16:26 ` [PATCH 10/17] kvm-arm: arm64: Introduce hyp page table empty checks Suzuki K Poulose
2016-04-08 13:15   ` Christoffer Dall
2016-04-04 16:26 ` [PATCH 11/17] kvm-arm: Use explicit stage2 helper routines Suzuki K Poulose
2016-04-08 13:16   ` Christoffer Dall
2016-04-04 16:26 ` [PATCH 12/17] kvm-arm: Add explicit hyp page table modifiers Suzuki K Poulose
2016-04-08 13:15   ` Christoffer Dall [this message]
2016-04-08 15:09     ` Marc Zyngier
2016-04-08 15:16       ` Christoffer Dall
2016-04-08 15:22         ` Marc Zyngier
2016-04-08 15:22       ` Suzuki K Poulose
2016-04-08 15:25         ` Christoffer Dall
2016-04-04 16:26 ` [PATCH 13/17] kvm-arm: Add stage2 " Suzuki K Poulose
2016-04-08 13:42   ` Christoffer Dall
2016-04-08 15:37     ` Suzuki K Poulose
2016-04-08 17:03       ` Christoffer Dall
2016-04-08 17:07         ` Suzuki K Poulose
2016-04-08 17:25           ` Christoffer Dall
2016-04-04 16:26 ` [PATCH 14/17] kvm-arm: Cleanup kvm_* wrappers Suzuki K Poulose
2016-04-08 15:05   ` Christoffer Dall
2016-04-04 16:26 ` [PATCH 15/17] kvm: arm64: Get rid of fake page table levels Suzuki K Poulose
2016-04-08 15:05   ` Christoffer Dall
2016-04-11 14:33     ` Suzuki K Poulose
2016-04-12 12:14       ` Christoffer Dall
2016-04-12 13:03         ` Suzuki K Poulose
2016-04-12 13:11           ` Christoffer Dall
2016-04-13 17:49         ` Suzuki K Poulose
2016-04-14 12:18           ` Christoffer Dall
2016-04-04 16:26 ` [PATCH 16/17] kvm-arm: Cleanup stage2 pgd handling Suzuki K Poulose
2016-04-08 15:08   ` Christoffer Dall
2016-04-04 16:26 ` [PATCH 17/17] arm64: kvm: Add support for 16K pages Suzuki K Poulose
2016-04-08 15:13   ` Christoffer Dall
2016-04-08 15:15 ` [PATCH 00/17] kvm-arm: Add stage2 page table walker 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=20160408131537.GR8961@cbox \
    --to=christoffer.dall@linaro.org \
    --cc=catalin.marinas@arm.com \
    --cc=kvm@vger.kernel.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=mark.rutland@arm.com \
    --cc=suzuki.poulose@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).