Received: by 10.223.176.5 with SMTP id f5csp967916wra; Tue, 6 Feb 2018 10:14:41 -0800 (PST) X-Google-Smtp-Source: AH8x224n8FUYjBXnLbESvm0aGwX/liBTOATaLLNDBLiV/x66xaVCvG0d5O0a2CK2iptFb7gc6dWw X-Received: by 10.98.152.11 with SMTP id q11mr3267371pfd.131.1517940881093; Tue, 06 Feb 2018 10:14:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517940881; cv=none; d=google.com; s=arc-20160816; b=jVBrLV0xBFLNp664lWe9lb9aDAlUDMsKwBH4scUoHIBiW5XMi6PAEJ7q0nqGaf1pbs IZ3Zr8C5JABSSjfYRYo8uz/2VkJP8P6X2jsNidG+sRDSu7csnlPJWUE0v7XxuUTYv6XQ lwnFFE5an+l8/WXqos+qZxG1NvWp5SGUgevwEjNdQPzT/6JbXDS86K70Hbfw4iKP+IPO LWhUVDAznsS/M59sahj20XUvRCmTgAZZMnPKucEQZZS0xGD6pdxZRLh0W7QEBOMOQbKv yu24Y+j5TTlO/tRYU2sv6rKtrL0DvQp/ku48PCaZQnLCay33ijEvf4btvUmTVzwXZiI8 0iNA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:message-id :in-reply-to:date:references:subject:cc:to:from :arc-authentication-results; bh=D1zJumetSXTuv6eUq2i7OYju2yraKhI1oban77ckMOs=; b=rPgnOakNoQ9h0+eGeLZm9EwcwT4S1v3SuiQVBJvWW5gmKEEZbEXUvvEFTkNRvLsNkY mNcRVH8jQASWr3dL/jmvFvF+KdNLGrUTJE910R2gV7egYYwy7jeptt5HVHFDvlFlMp/O 25tP4sPVMHNNX0hokXSlfAkw7Mv6KDpfNZs8q60v57tyxyvfkgm3aEMxO5vU6sAOld43 aGr37Us8qjwzKJbX4ixBpj8f9j/iDugoiwLA9UXURqJ8kVVzvbf6P/7UBLZRV57WQa6H xMJaX9MrtkRw3xsVFx2cSuwbWoM9DhPZmEraM+v9N+0Liv0wmSDCn5jYx/3aWSRqfhMN CWFA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p12si7198774pgn.523.2018.02.06.10.14.26; Tue, 06 Feb 2018 10:14:41 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752816AbeBFSNp (ORCPT + 99 others); Tue, 6 Feb 2018 13:13:45 -0500 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:41722 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752536AbeBFSNl (ORCPT ); Tue, 6 Feb 2018 13:13:41 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id E96831435; Tue, 6 Feb 2018 10:13:39 -0800 (PST) Received: from localhost (e105922-lin.cambridge.arm.com [10.1.207.29]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8E2003F25C; Tue, 6 Feb 2018 10:13:39 -0800 (PST) From: Punit Agrawal To: Christoffer Dall Cc: kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, suzuki.poulose@arm.com, Marc Zyngier , Catalin Marinas Subject: Re: [RFC 4/4] KVM: arm64: Add support for PUD hugepages at stage 2 References: <20180110190729.18383-1-punit.agrawal@arm.com> <20180110190729.18383-5-punit.agrawal@arm.com> <20180206145501.GB23160@cbox> Date: Tue, 06 Feb 2018 18:13:38 +0000 In-Reply-To: <20180206145501.GB23160@cbox> (Christoffer Dall's message of "Tue, 6 Feb 2018 15:55:01 +0100") Message-ID: <87bmh2htpp.fsf@e105922-lin.cambridge.arm.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Christoffer Dall 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 >> Cc: Marc Zyngier >> Cc: Christoffer Dall >> Cc: Catalin Marinas >> --- >> 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