Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp3924993pxb; Mon, 8 Feb 2021 03:45:19 -0800 (PST) X-Google-Smtp-Source: ABdhPJyhcMTJkgeg6foaB3uPm/uWZrjLV4n/+JvH38JtjtkQ5j9Yc3pAVaVmofr+4iT3tbCYZZs7 X-Received: by 2002:a50:ccc1:: with SMTP id b1mr9274016edj.307.1612784719540; Mon, 08 Feb 2021 03:45:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612784719; cv=none; d=google.com; s=arc-20160816; b=NuAulVquTQU7r/cjP1I0J1UH7SFzkjkumT5HBxnciaJaIP0xA1+nFoZ0Hvw28Pp8FC U78LeVdfW8bHejfyMYYZTkH0zae4A6mfBdz13atjG7VIB4U/nC7mTkYtgiQCjIZZFa36 9lV8jXXdoUenpoq/P1ogDLfwrwNhg4EC2c0tQp3DmyM+yoVbJLjJRIliu52fhEpY4HaM IaUI5WaB7uN1CR/GCU9I1kgaOX78JSlxW8NxMQMdheG4b2Xf65zjchLuwNif1n9uK98N ep0jRhdXjXCjBG/L8p19NwP4sVCcuKnZ4e+2X9YKoBYWJ+/KoP/1Qd3E5pzpnf1ifd8R TPNg== 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=+nLkPYHnkevtk0Yl9j7IbnDr6SmV3RF+L2GHlzUcJKs=; b=EhH+CqXE/Os5SYT/RUJeVd8RyEhw3SGsTTkn4G9zhLG1mqSrJzbOu/ix1XrB/cW6FJ nvtByv1YywZtXj4PPBdMy7WCoBpJ9/6lDuVKL5Xh4rUqELdRm4QvHhh4o2nrRbDi+A7c sl5zPxFk9LbU8RPOkOkieVhzqP/G7UkjSqMYt+2QBopO2QD2Gbi+02zvXUtKsrQtTsEW 4xjcvQ1U9CepaYc1JBwb3Pc0ppfvOIH5bb2OxJm2TbskcE9KyrIkdCE1K4BpGHTPKmbu RcJLLjIFstcoUE9gbSfY9i2bWFCxiKzX2KzZPmyVcXIu58J5qmBJPY78QRVFxrzjGEoL Wkhw== 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 y8si11955780edp.207.2021.02.08.03.44.55; Mon, 08 Feb 2021 03:45:19 -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 S233003AbhBHLoT (ORCPT + 99 others); Mon, 8 Feb 2021 06:44:19 -0500 Received: from szxga04-in.huawei.com ([45.249.212.190]:11703 "EHLO szxga04-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233070AbhBHLXs (ORCPT ); Mon, 8 Feb 2021 06:23:48 -0500 Received: from DGGEMS411-HUB.china.huawei.com (unknown [172.30.72.60]) by szxga04-in.huawei.com (SkyGuard) with ESMTP id 4DZ3W558lPzlHb3; Mon, 8 Feb 2021 19:21:21 +0800 (CST) Received: from DESKTOP-TMVL5KK.china.huawei.com (10.174.187.128) by DGGEMS411-HUB.china.huawei.com (10.3.19.211) with Microsoft SMTP Server id 14.3.498.0; Mon, 8 Feb 2021 19:22:57 +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 4/4] KVM: arm64: Distinguish cases of memcache allocations completely Date: Mon, 8 Feb 2021 19:22:50 +0800 Message-ID: <20210208112250.163568-5-wangyanan55@huawei.com> X-Mailer: git-send-email 2.8.4.windows.1 In-Reply-To: <20210208112250.163568-1-wangyanan55@huawei.com> References: <20210208112250.163568-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 d151927a7d62..550498a9104e 100644 --- a/arch/arm64/kvm/mmu.c +++ b/arch/arm64/kvm/mmu.c @@ -815,19 +815,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 @@ -887,6 +874,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.23.0