Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp4009216pxf; Tue, 6 Apr 2021 06:02:05 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxqQalvpwp/HXsCQGiuSCqSCWOzPvUKz9M44Bsttdy8Eps7Vhud4Xd4xWaz5iZ9DOf/L5+F X-Received: by 2002:a02:8801:: with SMTP id r1mr29313500jai.51.1617714125110; Tue, 06 Apr 2021 06:02:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617714125; cv=none; d=google.com; s=arc-20160816; b=cRT1j1E3wUouImGJaj5SoMtHjvy+3IMhytWua74m2DT23PvqlTYDrOSrXhAQMsWqd6 xeM/s01HbLCbvYX5zZEJiYehuHHzbUCMeU5pbn9LITDbZUgb0i4hCzExCSJdRreCDu6o IdS6fkwcrgd+sbZBAHX+FH7g8qTTD54trhWJkKDjvrR/M/OxXKF5EB3r2dyFTpeH854N XQgKN6ZlKeQ7BrUS74Q5DCPWG/OYTdmUG1U5QG5LBE62QRkjZ7bzBqfFHfwB9oWhwRHw IzSBrBycugiKr4+QWgxYv07eHmjEN5wpcC8buwk9Y2Lbtcvv1s/4ByzSsIg+swbQi4vL EDvQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-language:content-transfer-encoding :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=pRzLZwV6fVvi/5U2fkEuXfHs4gLHyjv8NXKKiFTrpH4=; b=TmbLiVpAoue1sLnof2j0RpOkXlr8OR482WOnCB+vwfvrYYa8S97XRg9Jd+9JfALS8T L5P93CNmSqvPHMjHJsY8Yol7/BAHQs7kpyphv1TvwojsWmRLe8ClKmAl8TPnnyQrCqGp DQE4Jf9GWuMG7tDtAiUmrGm7mRE34kS+ngM4pWOPgcKu2trr0k52hBtpAbVtX0jL1uwC nf9LogBsr82joQ47UXNF/vtliQV0EPAy0WcADMHOufGzM2imt6N3VwIEOKfH3Iq9AjZN ggfspLYruRFMo3vko2ZtlRm+2aGpaE6f0eWfr3/AJhg2rd09jj/iMFdZfn7g+AAnEmIH v97Q== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v4si17091010iob.94.2021.04.06.06.01.48; Tue, 06 Apr 2021 06:02:05 -0700 (PDT) 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243515AbhDFDFe (ORCPT + 99 others); Mon, 5 Apr 2021 23:05:34 -0400 Received: from szxga02-in.huawei.com ([45.249.212.188]:3934 "EHLO szxga02-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243510AbhDFDFd (ORCPT ); Mon, 5 Apr 2021 23:05:33 -0400 Received: from dggeml405-hub.china.huawei.com (unknown [172.30.72.53]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4FDsm209M2z5lm9; Tue, 6 Apr 2021 11:03:14 +0800 (CST) Received: from dggpemm500023.china.huawei.com (7.185.36.83) by dggeml405-hub.china.huawei.com (10.3.17.49) with Microsoft SMTP Server (TLS) id 14.3.498.0; Tue, 6 Apr 2021 11:05:22 +0800 Received: from [10.174.187.128] (10.174.187.128) by dggpemm500023.china.huawei.com (7.185.36.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2106.2; Tue, 6 Apr 2021 11:05:22 +0800 Subject: Re: [PATCH v6 00/10] KVM: selftests: some improvement and a new test for kvm page table To: Paolo Bonzini , , , CC: Andrew Jones , Ben Gardon , "Sean Christopherson" , Vitaly Kuznetsov , Peter Xu , Ingo Molnar , Adrian Hunter , Jiri Olsa , "Arnaldo Carvalho de Melo" , Arnd Bergmann , Michael Kerrisk , Thomas Gleixner , , References: <20210330080856.14940-1-wangyanan55@huawei.com> From: "wangyanan (Y)" Message-ID: <31ab81be-bf14-62f3-d579-9685ccec578a@huawei.com> Date: Tue, 6 Apr 2021 11:05:22 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 MIME-Version: 1.0 In-Reply-To: <20210330080856.14940-1-wangyanan55@huawei.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: [10.174.187.128] X-ClientProxiedBy: dggeme704-chm.china.huawei.com (10.1.199.100) To dggpemm500023.china.huawei.com (7.185.36.83) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Kindly ping... Hi Paolo, Will this series be picked up soon, or is there any other work for me to do? Regards, Yanan On 2021/3/30 16:08, Yanan Wang wrote: > Hi, > This v6 series can mainly include two parts. > Rebased on kvm queue branch: https://git.kernel.org/pub/scm/virt/kvm/kvm.git/log/?h=queue > > In the first part, all the known hugetlb backing src types specified > with different hugepage sizes are listed, so that we can specify use > of hugetlb source of the exact granularity that we want, instead of > the system default ones. And as all the known hugetlb page sizes are > listed, it's appropriate for all architectures. Besides, a helper that > can get granularity of different backing src types(anonumous/thp/hugetlb) > is added, so that we can use the accurate backing src granularity for > kinds of alignment or guest memory accessing of vcpus. > > In the second part, a new test is added: > This test is added to serve as a performance tester and a bug reproducer > for kvm page table code (GPA->HPA mappings), it gives guidance for the > people trying to make some improvement for kvm. And the following explains > what we can exactly do through this test. > > The function guest_code() can cover the conditions where a single vcpu or > multiple vcpus access guest pages within the same memory region, in three > VM stages(before dirty logging, during dirty logging, after dirty logging). > Besides, the backing src memory type(ANONYMOUS/THP/HUGETLB) of the tested > memory region can be specified by users, which means normal page mappings > or block mappings can be chosen by users to be created in the test. > > If ANONYMOUS memory is specified, kvm will create normal page mappings > for the tested memory region before dirty logging, and update attributes > of the page mappings from RO to RW during dirty logging. If THP/HUGETLB > memory is specified, kvm will create block mappings for the tested memory > region before dirty logging, and split the blcok mappings into normal page > mappings during dirty logging, and coalesce the page mappings back into > block mappings after dirty logging is stopped. > > So in summary, as a performance tester, this test can present the > performance of kvm creating/updating normal page mappings, or the > performance of kvm creating/splitting/recovering block mappings, > through execution time. > > When we need to coalesce the page mappings back to block mappings after > dirty logging is stopped, we have to firstly invalidate *all* the TLB > entries for the page mappings right before installation of the block entry, > because a TLB conflict abort error could occur if we can't invalidate the > TLB entries fully. We have hit this TLB conflict twice on aarch64 software > implementation and fixed it. As this test can imulate process from dirty > logging enabled to dirty logging stopped of a VM with block mappings, > so it can also reproduce this TLB conflict abort due to inadequate TLB > invalidation when coalescing tables. > > Links about the TLB conflict abort: > https://lore.kernel.org/lkml/20201201201034.116760-3-wangyanan55@huawei.com/ > > --- > > Change logs: > > v5->v6: > - Address Andrew Jones's comments for v5 series > - Add Andrew Jones's R-b tags in some patches > - Rebased on newest kvm/queue tree > - v5: https://lore.kernel.org/lkml/20210323135231.24948-1-wangyanan55@huawei.com/ > > v4->v5: > - Use synchronization(sem_wait) for time measurement > - Add a new patch about TEST_ASSERT(patch 4) > - Address Andrew Jones's comments for v4 series > - Add Andrew Jones's R-b tags in some patches > - v4: https://lore.kernel.org/lkml/20210302125751.19080-1-wangyanan55@huawei.com/ > > v3->v4: > - Add a helper to get system default hugetlb page size > - Add tags of Reviewed-by of Ben in the patches > - v3: https://lore.kernel.org/lkml/20210301065916.11484-1-wangyanan55@huawei.com/ > > v2->v3: > - Add tags of Suggested-by, Reviewed-by in the patches > - Add a generic micro to get hugetlb page sizes > - Some changes for suggestions about v2 series > - v2: https://lore.kernel.org/lkml/20210225055940.18748-1-wangyanan55@huawei.com/ > > v1->v2: > - Add a patch to sync header files > - Add helpers to get granularity of different backing src types > - Some changes for suggestions about v1 series > - v1: https://lore.kernel.org/lkml/20210208090841.333724-1-wangyanan55@huawei.com/ > > --- > > Yanan Wang (10): > tools headers: sync headers of asm-generic/hugetlb_encode.h > mm/hugetlb: Add a macro to get HUGETLB page sizes for mmap > KVM: selftests: Use flag CLOCK_MONOTONIC_RAW for timing > KVM: selftests: Print the errno besides error-string in TEST_ASSERT > KVM: selftests: Make a generic helper to get vm guest mode strings > KVM: selftests: Add a helper to get system configured THP page size > KVM: selftests: Add a helper to get system default hugetlb page size > KVM: selftests: List all hugetlb src types specified with page sizes > KVM: selftests: Adapt vm_userspace_mem_region_add to new helpers > KVM: selftests: Add a test for kvm page table code > > include/uapi/linux/mman.h | 2 + > tools/include/asm-generic/hugetlb_encode.h | 3 + > tools/include/uapi/linux/mman.h | 2 + > tools/testing/selftests/kvm/.gitignore | 1 + > tools/testing/selftests/kvm/Makefile | 3 + > .../selftests/kvm/demand_paging_test.c | 8 +- > .../selftests/kvm/dirty_log_perf_test.c | 14 +- > .../testing/selftests/kvm/include/kvm_util.h | 4 +- > .../testing/selftests/kvm/include/test_util.h | 21 +- > .../selftests/kvm/kvm_page_table_test.c | 506 ++++++++++++++++++ > tools/testing/selftests/kvm/lib/assert.c | 4 +- > tools/testing/selftests/kvm/lib/kvm_util.c | 59 +- > tools/testing/selftests/kvm/lib/test_util.c | 163 +++++- > tools/testing/selftests/kvm/steal_time.c | 4 +- > 14 files changed, 733 insertions(+), 61 deletions(-) > create mode 100644 tools/testing/selftests/kvm/kvm_page_table_test.c >