Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp115659pxf; Wed, 10 Mar 2021 01:46:59 -0800 (PST) X-Google-Smtp-Source: ABdhPJzoI7TVJybtul3mEHIDgj6GySBqHUhGSa4Hlmv5pdcFmB1wPcVy/O4irErC5qX5sOCkn7Ap X-Received: by 2002:a05:6402:1157:: with SMTP id g23mr2273575edw.303.1615369619807; Wed, 10 Mar 2021 01:46:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1615369619; cv=none; d=google.com; s=arc-20160816; b=cbGzBSutKQQyohjiYH37LulRUMFVwUvTuSmovd1yLh3aXMyZxTkEHu+Ma+GSJK0qOT BLh8nc+4UFJdq8E9vb7YVvr588kjo4pog9EZtdqdIYUnYGlS20s7t7y51C1DxH+aJrfE b1Y/s6umdm0w9ONduhhmREq5BeDxNm2l3JQbztfz2lq5MJd5yerWlWGMvGDNFKL9jlb+ QOMulF/XXcDgS1SyUUu31wPFLeoAfdjpt1RH9edfBrm2QimK0nbXS6uGOftcgkXWb1M2 JYAROuUSm+6Mlq/CAUXEUeFBpE/ebdfbRIpurY9CYDPmfo8+2W3A8tXNFeb9GNn4lSTJ j34w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:references:in-reply-to:message-id :date:subject:cc:to:from; bh=Xo+tHkH7NWtWZtg7Zb6zp+z55F4+refFcSoRPJEcHrM=; b=ymjgndkSfoEo/AgCWjM3BWW4pOWU83pVbus7L+0iIlSkn9g49kAmcTMvpAh4iRKI+T PEz32AQg+gmRk5mOdDWQY3zZCE2mTVX4nNezMWxVPgJKYNKlPD3PnCnbmrhg+4xU0Uv8 0bXFuVa3k5yIenbTRUDrKIjnJ4JJDozEZTrc8C3vzaAyok5BuWytFdM9UhiSH+WVTcvl RQH0LE1Dhj2J2LHjqaxk73+JojDVuS8Dkyz8cZAT7ktC6BIheDgqWs0knWO4n+436X0Z w1g0AlSraxpxzsdd/QIKCN6WasdRN8YBbSBpzoJtsV5UzZGRv1dkFWfkrnxzP3RHPFuT IpXQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id x27si2478496edi.240.2021.03.10.01.46.36; Wed, 10 Mar 2021 01:46:59 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232460AbhCJJoM (ORCPT + 99 others); Wed, 10 Mar 2021 04:44:12 -0500 Received: from szxga04-in.huawei.com ([45.249.212.190]:13590 "EHLO szxga04-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232302AbhCJJnh (ORCPT ); Wed, 10 Mar 2021 04:43:37 -0500 Received: from DGGEMS412-HUB.china.huawei.com (unknown [172.30.72.60]) by szxga04-in.huawei.com (SkyGuard) with ESMTP id 4DwRtN0Syxz17J2q; Wed, 10 Mar 2021 17:41:48 +0800 (CST) Received: from DESKTOP-TMVL5KK.china.huawei.com (10.174.187.128) by DGGEMS412-HUB.china.huawei.com (10.3.19.212) with Microsoft SMTP Server id 14.3.498.0; Wed, 10 Mar 2021 17:43:25 +0800 From: Yanan Wang To: Marc Zyngier , Will Deacon , "Catalin Marinas" , James Morse , "Julien Thierry" , Suzuki K Poulose , Gavin Shan , Quentin Perret , , , , CC: , , , Yanan Wang Subject: [RFC PATCH v2 3/3] KVM: arm64: Distinguish cases of memcache allocations completely Date: Wed, 10 Mar 2021 17:43:19 +0800 Message-ID: <20210310094319.18760-4-wangyanan55@huawei.com> X-Mailer: git-send-email 2.8.4.windows.1 In-Reply-To: <20210310094319.18760-1-wangyanan55@huawei.com> References: <20210310094319.18760-1-wangyanan55@huawei.com> MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.174.187.128] X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org With a guest translation fault, the memcache pages are not needed if KVM is only about to install a new leaf entry into the existing page table. And with a guest permission fault, the memcache pages are also not needed for a write_fault in dirty-logging time if KVM is only about to update the existing leaf entry instead of collapsing a block entry into a table. By comparing fault_granule and vma_pagesize, cases that require allocations from memcache and cases that don't can be distinguished completely. Signed-off-by: Yanan Wang --- arch/arm64/kvm/mmu.c | 25 ++++++++++++------------- 1 file changed, 12 insertions(+), 13 deletions(-) diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c index 1eec9f63bc6f..05af40dc60c1 100644 --- a/arch/arm64/kvm/mmu.c +++ b/arch/arm64/kvm/mmu.c @@ -810,19 +810,6 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa, gfn = fault_ipa >> PAGE_SHIFT; mmap_read_unlock(current->mm); - /* - * Permission faults just need to update the existing leaf entry, - * and so normally don't require allocations from the memcache. The - * only exception to this is when dirty logging is enabled at runtime - * and a write fault needs to collapse a block entry into a table. - */ - if (fault_status != FSC_PERM || (logging_active && write_fault)) { - ret = kvm_mmu_topup_memory_cache(memcache, - kvm_mmu_cache_min_pages(kvm)); - if (ret) - return ret; - } - mmu_seq = vcpu->kvm->mmu_notifier_seq; /* * Ensure the read of mmu_notifier_seq happens before we call @@ -880,6 +867,18 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa, else if (cpus_have_const_cap(ARM64_HAS_CACHE_DIC)) prot |= KVM_PGTABLE_PROT_X; + /* + * Allocations from the memcache are required only when granule of the + * lookup level where the guest fault happened exceeds vma_pagesize, + * which means new page tables will be created in the fault handlers. + */ + if (fault_granule > vma_pagesize) { + ret = kvm_mmu_topup_memory_cache(memcache, + kvm_mmu_cache_min_pages(kvm)); + if (ret) + return ret; + } + /* * Under the premise of getting a FSC_PERM fault, we just need to relax * permissions only if vma_pagesize equals fault_granule. Otherwise, -- 2.19.1