Received: by 2002:a4a:301c:0:0:0:0:0 with SMTP id q28-v6csp620967oof; Tue, 25 Sep 2018 02:21:50 -0700 (PDT) X-Google-Smtp-Source: ACcGV62lxAw25ZinWlsIuBQImKUQCiELoc9l2OX27Hljbz5eqdhDmxX/kLjawG7yJyBtqmIl4W1F X-Received: by 2002:a17:902:6b89:: with SMTP id p9-v6mr175989plk.272.1537867310877; Tue, 25 Sep 2018 02:21:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1537867310; cv=none; d=google.com; s=arc-20160816; b=gFxKkDa1ob1CYZ4r2io0YsMv5BLgeJYGvykhtoEgV+WJntWGTsI8y0RMwFnsDpbG+I dbjmJWfI9P0v1HPClsdPsp5YGlJmJ6KlfqZaxwmXFqz5rkXca/2US+4NCzWioJmASpoJ m+sFUSBBepQRy3ogBjobAT8BI/hYJu3swa781wG/4CwxXQKKAQprnC+wPtjZ6xTVJEVL E4IWkBAhiQvwPMhIeuEi1vGfNqbo+hXKKSGeJSIwjIJ2JdYzoT1B0cliKOd08sSt5kgS j4IvbhrVymm5E803jEsPFQolAwdcrQmxy3bCWOpwMOG0XFE9Ld74xq8OghpMk43PDRLP ePTw== 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; bh=dbxOxtNYvoXcyISJp5qWFZmQcxbUyhH9IWeWbWyorWA=; b=JyDhuUegrzh3liH3I7HNYTT50QVoLGcIu2CitzEbbZbdVW9HG1bfL3ejpR/ynJzGnT 8WI0E5jOAzsGVl3Ik85uor33X+ISztJrBAROUnfXpl8ptNSAfuHP/B+1Yi5FHLxOWZ1a nZMcRPrbmnUPzFqGHWlPTdBEW85B8MTJttXyt+E6PK6AbPTp94uyZwkhqUZ5wj+oIHGd qF8rh3m3Fi5gczVKQCdxXMl3+Wt3G0zhvSlN2S07orJhoirfPyzQguHMMo94ULBRG6RN CaM3gzPiKtiB7Bs05gZ6JOs9wESf4OQBmA5T8FOw6vcQTgr8VvHIqdWZQ26H3ozWfsWb rvyw== 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 r59-v6si1826277plb.39.2018.09.25.02.21.33; Tue, 25 Sep 2018 02:21:50 -0700 (PDT) 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 S1728781AbeIYP14 (ORCPT + 99 others); Tue, 25 Sep 2018 11:27:56 -0400 Received: from foss.arm.com ([217.140.101.70]:47646 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728630AbeIYP14 (ORCPT ); Tue, 25 Sep 2018 11:27:56 -0400 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 4FAA680D; Tue, 25 Sep 2018 02:21:19 -0700 (PDT) Received: from localhost (e105922-lin.emea.arm.com [10.4.13.28]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id BCEA63F5B3; Tue, 25 Sep 2018 02:21:18 -0700 (PDT) From: Punit Agrawal To: Suzuki K Poulose Cc: , , , , , Christoffer Dall , Russell King , Catalin Marinas Subject: Re: [PATCH v7 9/9] KVM: arm64: Add support for creating PUD hugepages at stage 2 References: <20180924174552.8387-1-punit.agrawal@arm.com> <20180924174552.8387-10-punit.agrawal@arm.com> <4df146fc-f9b0-882e-becb-056111a444d4@arm.com> Date: Tue, 25 Sep 2018 10:21:17 +0100 In-Reply-To: <4df146fc-f9b0-882e-becb-056111a444d4@arm.com> (Suzuki K. Poulose's message of "Mon, 24 Sep 2018 22:21:43 +0100") Message-ID: <875zyurkz6.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 Suzuki K Poulose writes: > Hi Punit, > > > On 09/24/2018 06:45 PM, 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 >> Cc: Christoffer Dall >> Cc: Marc Zyngier >> Cc: Russell King >> Cc: Catalin Marinas >> Cc: Will Deacon > > >> >> diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h >> index a42b9505c9a7..a8e86b926ee0 100644 >> --- a/arch/arm/include/asm/kvm_mmu.h >> +++ b/arch/arm/include/asm/kvm_mmu.h >> @@ -84,11 +84,14 @@ void kvm_clear_hyp_idmap(void); >> #define kvm_pfn_pte(pfn, prot) pfn_pte(pfn, prot) >> #define kvm_pfn_pmd(pfn, prot) pfn_pmd(pfn, prot) >> +#define kvm_pfn_pud(pfn, prot) (__pud(0)) >> #define kvm_pud_pfn(pud) ({ BUG(); 0; }) >> #define kvm_pmd_mkhuge(pmd) pmd_mkhuge(pmd) >> +/* No support for pud hugepages */ >> +#define kvm_pud_mkhuge(pud) (pud) >> > > shouldn't this be BUG() like other PUD huge helpers for arm32 ? > >> /* >> * The following kvm_*pud*() functions are provided strictly to allow >> @@ -105,6 +108,23 @@ static inline bool kvm_s2pud_readonly(pud_t *pud) >> return false; >> } >> +static inline void kvm_set_pud(pud_t *pud, pud_t new_pud) >> +{ >> + BUG(); >> +} >> + >> +static inline pud_t kvm_s2pud_mkwrite(pud_t pud) >> +{ >> + BUG(); >> + return pud; >> +} >> + >> +static inline pud_t kvm_s2pud_mkexec(pud_t pud) >> +{ >> + BUG(); >> + return pud; >> +} >> + > > >> diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c >> index 3ff7ebb262d2..5b8163537bc2 100644 >> --- a/virt/kvm/arm/mmu.c >> +++ b/virt/kvm/arm/mmu.c > > ... > > >> @@ -1669,7 +1746,28 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa, >> needs_exec = exec_fault || >> (fault_status == FSC_PERM && stage2_is_exec(kvm, fault_ipa)); >> - if (hugetlb && vma_pagesize == PMD_SIZE) { >> + if (hugetlb && vma_pagesize == PUD_SIZE) { >> + /* >> + * Assuming that PUD level always exists at Stage 2 - >> + * this is true for 4k pages with 40 bits IPA >> + * currently supported. >> + * >> + * When using 64k pages, 40bits of IPA results in >> + * using only 2-levels at Stage 2. Overlooking this >> + * problem for now as a PUD hugepage with 64k pages is >> + * too big (4TB) to be practical. >> + */ >> + pud_t new_pud = kvm_pfn_pud(pfn, mem_type); > > Is this based on the Dynamic IPA series ? The cover letter seems > to suggest that it is. But I don't see the check to make sure we have > stage2 PUD level here before we go ahead and try PUD huge page at > stage2. Also the comment above seems outdated in that case. It is indeed based on the Dynamic IPA series but I seem to have lost the actual changes introducing the checks for PUD level. Let me fix that up and post an update. Sorry for the noise. Punit > >> + >> + new_pud = kvm_pud_mkhuge(new_pud); >> + if (writable) >> + new_pud = kvm_s2pud_mkwrite(new_pud); >> + >> + if (needs_exec) >> + new_pud = kvm_s2pud_mkexec(new_pud); >> + >> + ret = stage2_set_pud_huge(kvm, memcache, fault_ipa, &new_pud); >> + } else if (hugetlb && vma_pagesize == PMD_SIZE) { >> pmd_t new_pmd = kvm_pfn_pmd(pfn, mem_type); >> new_pmd = kvm_pmd_mkhuge(new_pmd); >> > > > Suzuki