Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp3487845pxu; Mon, 30 Nov 2020 04:25:05 -0800 (PST) X-Google-Smtp-Source: ABdhPJySDEMQ0nzfNtdNu1DzhJYP5aIDjGdLrmg8zlF/djRs5+JGRuGnR/YTryemq/zPUYRtkcwA X-Received: by 2002:a17:906:fc4:: with SMTP id c4mr20675156ejk.490.1606739105300; Mon, 30 Nov 2020 04:25:05 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1606739105; cv=none; d=google.com; s=arc-20160816; b=El+zvxKwiL84Ajs7pEYEH5k+JvP3cXmDGAptDTa272HJE9HMav7ac/EGXLiXQbcxng CXQmD3rUO6Z1dHDMbBSVHYOCswqsJBYAj2G/Q4rIlrFIjZA+NWd1u90P9EhoWNtPy25n Rn6/F77sZv0fVPMluu8Bo9Wr9vYD6I2YxR4YaRzf++EFMjTvf2jXhYhx6BDyjKjINeVl 7X7H/l6Rjm9uxDLVfMNQJKiSLP63B3Du+utJ1J40Cw2k86NOSdEdgkhqb8d0vtxzOnWT NpRmGbd3J1w36/p2IhBOY8X5txvR15MiN5ZU0Pw2ScsZXGJzaMUpNiFFFoWsSeYMgjf5 5hnA== 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=MIJkRTowwVG4J6j4Cbnyiedmh2TCaBP4G7s+4IlbHKo=; b=h5apk4rTOoAJ8YcmB5hhoW+FecrsqlsBuRIfFSvrVjxwBz7A5VwfMrevgC2Y9vRAc+ wJC1WoZ2VhIny4eXH3QkRLeF3TExTil1tjjVSoFQnhfrYg8xaMkBR0FsGFIM4BjYDdKA 9Js28LUSjH/5J9oLgE8dpiNmUWF5VpsvKw7ZV0nTlFO13rbJbj89Sf8w8OOTPtBSw1T6 uwPtgeKHUcaERwt+qhMpGntugKE80dIoJAxjdrRqVE+vLk74KAUY6R3vPYnSv4IYk/DU nAegGGk9VgKNoRO+NAGGkclJB0jWRh01XKqahtdlemLeuGhfyVMY/CNXR7OdLmoqFCSD qGpA== 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 gf18si2321084ejb.202.2020.11.30.04.24.41; Mon, 30 Nov 2020 04:25:05 -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 S1727001AbgK3MUI (ORCPT + 99 others); Mon, 30 Nov 2020 07:20:08 -0500 Received: from szxga04-in.huawei.com ([45.249.212.190]:8165 "EHLO szxga04-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725902AbgK3MUH (ORCPT ); Mon, 30 Nov 2020 07:20:07 -0500 Received: from DGGEMS402-HUB.china.huawei.com (unknown [172.30.72.58]) by szxga04-in.huawei.com (SkyGuard) with ESMTP id 4Cl45j6WPjz15K9J; Mon, 30 Nov 2020 20:18:49 +0800 (CST) Received: from DESKTOP-TMVL5KK.china.huawei.com (10.174.186.123) by DGGEMS402-HUB.china.huawei.com (10.3.19.202) with Microsoft SMTP Server id 14.3.487.0; Mon, 30 Nov 2020 20:19:08 +0800 From: Yanan Wang To: , , Marc Zyngier , Catalin Marinas , Will Deacon , James Morse , "Julien Thierry" , Suzuki K Poulose , Gavin Shan , Quentin Perret CC: , , , , , , , Yanan Wang Subject: [RFC PATCH 2/3] KVM: arm64: Fix handling of merging tables into a block entry Date: Mon, 30 Nov 2020 20:18:46 +0800 Message-ID: <20201130121847.91808-3-wangyanan55@huawei.com> X-Mailer: git-send-email 2.8.4.windows.1 In-Reply-To: <20201130121847.91808-1-wangyanan55@huawei.com> References: <20201130121847.91808-1-wangyanan55@huawei.com> MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.174.186.123] X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org In dirty logging case(logging_active == True), we need to collapse a block entry into a table if necessary. After dirty logging is canceled, when merging tables back into a block entry, we should not only free the non-huge page tables but also unmap the non-huge mapping for the block. Without the unmap, inconsistent TLB entries for the pages in the the block will be created. We could also use unmap_stage2_range API to unmap the non-huge mapping, but this could potentially free the upper level page-table page which will be useful later. Signed-off-by: Yanan Wang --- arch/arm64/kvm/hyp/pgtable.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c index 696b6aa83faf..fec8dc9f2baa 100644 --- a/arch/arm64/kvm/hyp/pgtable.c +++ b/arch/arm64/kvm/hyp/pgtable.c @@ -500,6 +500,9 @@ static int stage2_map_walk_table_pre(u64 addr, u64 end, u32 level, return 0; } +static void stage2_flush_dcache(void *addr, u64 size); +static bool stage2_pte_cacheable(kvm_pte_t pte); + static int stage2_map_walk_leaf(u64 addr, u64 end, u32 level, kvm_pte_t *ptep, struct stage2_map_data *data) { @@ -507,9 +510,17 @@ static int stage2_map_walk_leaf(u64 addr, u64 end, u32 level, kvm_pte_t *ptep, struct page *page = virt_to_page(ptep); if (data->anchor) { - if (kvm_pte_valid(pte)) + if (kvm_pte_valid(pte)) { + kvm_set_invalid_pte(ptep); + kvm_call_hyp(__kvm_tlb_flush_vmid_ipa, data->mmu, + addr, level); put_page(page); + if (stage2_pte_cacheable(pte)) + stage2_flush_dcache(kvm_pte_follow(pte), + kvm_granule_size(level)); + } + return 0; } @@ -574,7 +585,7 @@ static int stage2_map_walk_table_post(u64 addr, u64 end, u32 level, * The behaviour of the LEAF callback then depends on whether or not the * anchor has been set. If not, then we're not using a block mapping higher * up the table and we perform the mapping at the existing leaves instead. - * If, on the other hand, the anchor _is_ set, then we drop references to + * If, on the other hand, the anchor _is_ set, then we unmap the mapping of * all valid leaves so that the pages beneath the anchor can be freed. * * Finally, the TABLE_POST callback does nothing if the anchor has not -- 2.19.1