Message ID | 20230131181820.179033-1-bgardon@google.com |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp57553wrn; Tue, 31 Jan 2023 10:20:45 -0800 (PST) X-Google-Smtp-Source: AK7set/feExEymODc4ys3fYsJn0Qu4kD0e5FtUuE4qGXsYo3jvudx6WgbT5dIrRLXk2YuUXpe2DT X-Received: by 2002:a05:6a20:c1a8:b0:be:fa43:9476 with SMTP id bg40-20020a056a20c1a800b000befa439476mr1994931pzb.35.1675189245432; Tue, 31 Jan 2023 10:20:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1675189245; cv=none; d=google.com; s=arc-20160816; b=mcFIfh5Sg39G8fcJqBNyEmqd1XpQ5i7ytltdiGM8jjIEQBg3oPrs5BYcUh7aw0TyQ5 o35JzibUFp4UIDhaE66DrQgjdAl7MOc0CmJnCj8g7wVcOz8NZLfkafDyMxerasNMUS7+ rVrlOXNFNq0qNnrVPz+BdiajwJR5cMnLZ0RgUmORskroe4ATkUmvpwtSlixq92+dki+x qGAB4tON7JuGsoMD7L0A02jJ7IXDMJKS1YGAXDu0fj3fsHFQEQUfqXx1W3GDXUpmDowo ve5GQjjGjeLuOiFgb6vqyFgv/qzzddwYTYZjrGbHe7ZuWE2W8l8nMSmAHVLIPC+Y/G5g 2srA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:from:subject:message-id:mime-version:date :dkim-signature; bh=WG4JpoiMii42ipY3eUc5x3VppysZgl8p2dC8kvhLf3M=; b=ZaJezkHkkB8Udh4fkI7rtrB/s4FH1IVpMHgFtCLUHHKIwPaq/0F+cXm0smYgjy4eUr EEcFdmFFfssyhiPLLS0j0xXmWk9S5lEl+Z5Yu6TzqgvA+7S9xXdOadV7K3jhiA7ptA4E hLu7+jOo/l+eL9SZ9kA0nCp/vfScLlLGcA85u+nc6nJkW8gOkcy0FSx66pvNy0VML0go 1BNB+Hc3qaDJwlhAJ1YStsINVHaWSKZJ+A9k1lvGElgHo0H/K4s+2dVsqmsXo71NNyWs ukHS2H4JgboPDQkSQT+8HiygbPfVNKQYIMoQXMFJEoFmFgrM8WabmcR1HKnhuvGHIkub qHCw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=Xgn01Yv5; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id s2-20020a637702000000b004e05c11538csi13439728pgc.49.2023.01.31.10.20.32; Tue, 31 Jan 2023 10:20:45 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=Xgn01Yv5; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230177AbjAaSS0 (ORCPT <rfc822;maxin.john@gmail.com> + 99 others); Tue, 31 Jan 2023 13:18:26 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44956 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229985AbjAaSSY (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 31 Jan 2023 13:18:24 -0500 Received: from mail-pf1-x449.google.com (mail-pf1-x449.google.com [IPv6:2607:f8b0:4864:20::449]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 01CF92BF23 for <linux-kernel@vger.kernel.org>; Tue, 31 Jan 2023 10:18:23 -0800 (PST) Received: by mail-pf1-x449.google.com with SMTP id x9-20020aa79409000000b00593a1f7c3d8so4299167pfo.14 for <linux-kernel@vger.kernel.org>; Tue, 31 Jan 2023 10:18:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:from:subject:message-id:mime-version:date:from:to:cc:subject :date:message-id:reply-to; bh=WG4JpoiMii42ipY3eUc5x3VppysZgl8p2dC8kvhLf3M=; b=Xgn01Yv5aSNZI779Uc30n/qInl1dWVuWWpaFj1e5bwDqA2UECvux/B4QCJCx44xw4D R620NxEdqzm0mwOPzGcUc8XOB79mVKdDLCZRw2dOA/ULrF68hcQOzbm8718GKhAmzKtp mxQ2jdDKy+ZYmPSjIfdsnUl+AgO0hwLPF0NJtp6Lwit4v/D2p5eLCrIolZDrTKNSgjzy pXSU/VPHOejMfDBZvnXZ658ozSRGZfPi5xtslW1zDhYCnihMN8k55MatHyql+yFuWtwg uHd45MeY0SzQJ7SMyRa9Y6iuKRVihkmgYX5Jxt6HhDvw4FEjLWu13vLan80/8DhV/13+ RSdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:from:subject:message-id:mime-version:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=WG4JpoiMii42ipY3eUc5x3VppysZgl8p2dC8kvhLf3M=; b=SUYddyqHHmRv78LhfFMAe0TXoSHt72mfn4VQ64nQPE8EavmtmMmJjF4mgAMCL6jQv1 cwcH63Vs3Uvs1pkEaiVsy6zDxC2leh06S0+HSePmfxVkH5f1vIQqzkRcTk1aJI9hbGzM mdK5xtFa3j5YIM4Gp+sBE6KnTtM26ILJba55Ua7Z5Por4MPTVHCyOrxnXeIy0b+EDjn2 cOAD0sUfG1nUdb5twhWmaaB6ORCxEzUN+e4vF/K35NGDLlmoJ/D+IIH1U8p9IY93ZwJA WTSGLdbjEITUjijgCtoPSYcSRCI3t8VqQf/Nwu1A37jqg2uwtHdl2M1b1p6tP6qcY4dD 0eTg== X-Gm-Message-State: AO0yUKWuv21CA/YIUkhzHGOUENQx8WBzPtaEa3LmaVfjBhk2GC62/fqv htzV7NPc0OMCnDlWj6sivDWd8mgS1Pec3xY0FBNqkCh6fFiivolAop5aKb/0qHHa3noS/DyQMEE flTqNkEZRc6XMPki962bE6o2znkFtLiFmkrjRQ7olU8NrBEalmRdJYuvtlbSROJzsOcYJd90u X-Received: from sweer.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:e45]) (user=bgardon job=sendgmr) by 2002:a17:902:e54e:b0:196:5cd3:d88a with SMTP id n14-20020a170902e54e00b001965cd3d88amr2445592plf.12.1675189103207; Tue, 31 Jan 2023 10:18:23 -0800 (PST) Date: Tue, 31 Jan 2023 18:18:18 +0000 Mime-Version: 1.0 X-Mailer: git-send-email 2.39.1.456.gfc5497dd1b-goog Message-ID: <20230131181820.179033-1-bgardon@google.com> Subject: [PATCH V5 0/2] selftests: KVM: Add a test for eager page splitting From: Ben Gardon <bgardon@google.com> To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: Paolo Bonzini <pbonzini@redhat.com>, Peter Xu <peterx@redhat.com>, Sean Christopherson <seanjc@google.com>, David Matlack <dmatlack@google.com>, Vipin Sharma <vipinsh@google.com>, Ricardo Koller <ricarkol@google.com>, Ben Gardon <bgardon@google.com> Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-9.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1756563238196388135?= X-GMAIL-MSGID: =?utf-8?q?1756563238196388135?= |
Series |
selftests: KVM: Add a test for eager page splitting
|
|
Message
Ben Gardon
Jan. 31, 2023, 6:18 p.m. UTC
David Matlack recently added a feature known as eager page splitting to x86 KVM. This feature improves vCPU performance during dirty logging because the splitting operation is moved out of the page fault path, avoiding EPT/NPT violations or allowing the vCPU threads to resolve the violation in the fast path. While this feature is a great performance improvement, it does not have adequate testing in KVM selftests. Add a test to provide coverage of eager page splitting. Patch 1 is a quick refactor to be able to re-use some code from dirty_log_perf_test. Patch 2 adds the actual test. V4->V5: - V4: https://lore.kernel.org/all/Y9lIfGtMEEsaw6cd@google.com/ - Separated a helper function to just run vCPUs for an iteration and not also collect the stats. Suggested by Vipin. - Added a log message when the host does not support MANUAL_PROTECT, and so testing with that capability is skipped. Also suggested by Vipin. - Added RB from Vipin. V3->V4: - Added the copyright notices back. Thanks Vipin for the right thing to do there. V2->V3: - Removed copyright notice from the top of dirty_log_page_splitting.c - Adopted ASSERT_EQ for test assertions - Now skipping testing with MANUAL_PROTECT if unsupported V1->V2: - Run test in multiple modes, as suggested by David and Ricardo - Cleanups from shameful copy-pasta, as suggested by David Ben Gardon (2): selftests: KVM: Move dirty logging functions to memstress.(c|h) selftests: KVM: Add dirty logging page splitting test tools/testing/selftests/kvm/Makefile | 1 + .../selftests/kvm/dirty_log_perf_test.c | 84 +----- .../selftests/kvm/include/kvm_util_base.h | 1 + .../testing/selftests/kvm/include/memstress.h | 8 + tools/testing/selftests/kvm/lib/kvm_util.c | 5 + tools/testing/selftests/kvm/lib/memstress.c | 72 +++++ .../x86_64/dirty_log_page_splitting_test.c | 260 ++++++++++++++++++ 7 files changed, 354 insertions(+), 77 deletions(-) create mode 100644 tools/testing/selftests/kvm/x86_64/dirty_log_page_splitting_test.c
Comments
On Tue, Jan 31, 2023 at 7:18 PM Ben Gardon <bgardon@google.com> wrote: > > David Matlack recently added a feature known as eager page splitting > to x86 KVM. This feature improves vCPU performance during dirty > logging because the splitting operation is moved out of the page > fault path, avoiding EPT/NPT violations or allowing the vCPU threads > to resolve the violation in the fast path. > > While this feature is a great performance improvement, it does not > have adequate testing in KVM selftests. Add a test to provide coverage > of eager page splitting. > > Patch 1 is a quick refactor to be able to re-use some code from > dirty_log_perf_test. > Patch 2 adds the actual test. I have finally queued it, but made a small change to allow running it with non-hugetlbfs page types. Also, see the "KVM: selftests: skip hugetlb tests if huge pages are not available" patch I have just sent, which makes the test not fail in a default kernel configuration. Thanks, Paolo
On Tue, Mar 14, 2023 at 2:27 PM Paolo Bonzini <pbonzini@redhat.com> wrote: > I have finally queued it, but made a small change to allow running it > with non-hugetlbfs page types. Oops, it fails on my AMD workstation: $ tools/testing/selftests/kvm/x86_64/dirty_log_page_splitting_test Testing guest mode: PA-bits:ANY, VA-bits:48, 4K pages guest physical test memory: [0x7fc7fe00000, 0x7fcffe00000) ==== Test Assertion Failure ==== x86_64/dirty_log_page_splitting_test.c:195: __a == __b pid=1378203 tid=1378203 errno=0 - Success 1 0x0000000000402d02: run_test at dirty_log_page_splitting_test.c:195 2 0x000000000040367c: for_each_guest_mode at guest_modes.c:100 3 0x00000000004024df: main at dirty_log_page_splitting_test.c:245 4 0x00007f4227c3feaf: ?? ??:0 5 0x00007f4227c3ff5f: ?? ??:0 6 0x0000000000402594: _start at ??:? ASSERT_EQ(stats_populated.pages_4k, stats_repopulated.pages_4k) failed. stats_populated.pages_4k is 0x413 stats_repopulated.pages_4k is 0x412 Haven't debugged it yet. Paolo
On Tue, Mar 14, 2023 at 7:23 AM Paolo Bonzini <pbonzini@redhat.com> wrote: > > On Tue, Mar 14, 2023 at 2:27 PM Paolo Bonzini <pbonzini@redhat.com> wrote: > > I have finally queued it, but made a small change to allow running it > > with non-hugetlbfs page types. > > Oops, it fails on my AMD workstation: > > $ tools/testing/selftests/kvm/x86_64/dirty_log_page_splitting_test > Testing guest mode: PA-bits:ANY, VA-bits:48, 4K pages > guest physical test memory: [0x7fc7fe00000, 0x7fcffe00000) > ==== Test Assertion Failure ==== > x86_64/dirty_log_page_splitting_test.c:195: __a == __b > pid=1378203 tid=1378203 errno=0 - Success > 1 0x0000000000402d02: run_test at dirty_log_page_splitting_test.c:195 > 2 0x000000000040367c: for_each_guest_mode at guest_modes.c:100 > 3 0x00000000004024df: main at dirty_log_page_splitting_test.c:245 > 4 0x00007f4227c3feaf: ?? ??:0 > 5 0x00007f4227c3ff5f: ?? ??:0 > 6 0x0000000000402594: _start at ??:? > ASSERT_EQ(stats_populated.pages_4k, stats_repopulated.pages_4k) failed. > stats_populated.pages_4k is 0x413 > stats_repopulated.pages_4k is 0x412 > > Haven't debugged it yet. I wonder if pages are getting swapped, especially if running on a workstation. If so, mlock()ing all guest memory VMAs might be necessary to be able to assert exact page counts. > > Paolo >
On Tue, Mar 14, 2023 at 5:00 PM David Matlack <dmatlack@google.com> wrote: > On Tue, Mar 14, 2023 at 7:23 AM Paolo Bonzini <pbonzini@redhat.com> wrote: > > $ tools/testing/selftests/kvm/x86_64/dirty_log_page_splitting_test > > Testing guest mode: PA-bits:ANY, VA-bits:48, 4K pages > > guest physical test memory: [0x7fc7fe00000, 0x7fcffe00000) > > ==== Test Assertion Failure ==== > > x86_64/dirty_log_page_splitting_test.c:195: __a == __b > > pid=1378203 tid=1378203 errno=0 - Success > > 1 0x0000000000402d02: run_test at dirty_log_page_splitting_test.c:195 > > 2 0x000000000040367c: for_each_guest_mode at guest_modes.c:100 > > 3 0x00000000004024df: main at dirty_log_page_splitting_test.c:245 > > 4 0x00007f4227c3feaf: ?? ??:0 > > 5 0x00007f4227c3ff5f: ?? ??:0 > > 6 0x0000000000402594: _start at ??:? > > ASSERT_EQ(stats_populated.pages_4k, stats_repopulated.pages_4k) failed. > > stats_populated.pages_4k is 0x413 > > stats_repopulated.pages_4k is 0x412 > > I wonder if pages are getting swapped, especially if running on a > workstation. If so, mlock()ing all guest memory VMAs might be > necessary to be able to assert exact page counts. I don't think so, it's 100% reproducible and the machine is idle and only accessed via network. Also has 64 GB of RAM. :) Paolo
On 3/15/23 13:24, Paolo Bonzini wrote: > On Tue, Mar 14, 2023 at 5:00 PM David Matlack <dmatlack@google.com> wrote: >> I wonder if pages are getting swapped, especially if running on a >> workstation. If so, mlock()ing all guest memory VMAs might be >> necessary to be able to assert exact page counts. > > I don't think so, it's 100% reproducible and the machine is idle and > only accessed via network. Also has 64 GB of RAM. :) It also reproduces on Intel with pml=0 and eptad=0; the reason is due to the different semantics of dirty bits for page-table pages on AMD and Intel. Both AMD and eptad=0 Intel treat those as writes, therefore more pages are dropped before the repopulation phase when dirty logging is disabled. The "missing" page had been included in the population phase because it hosts the page tables for vcpu_args, but repopulation does not need it. This fixes it: -------------------- 8< --------------- From: Paolo Bonzini <pbonzini@redhat.com> Subject: [PATCH] selftests: KVM: perform the same memory accesses on every memstress iteration Perform the same memory accesses including the initialization steps that read from args and vcpu_args. This ensures that the state of KVM's page tables is the same after every iteration, including the pages that host the guest page tables for args and vcpu_args. This fixes a failure of dirty_log_page_splitting_test on AMD machines, as well as on Intel if PML and EPT A/D bits are both disabled. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> diff --git a/tools/testing/selftests/kvm/lib/memstress.c b/tools/testing/selftests/kvm/lib/memstress.c index 3632956c6bcf..8a429f4c86db 100644 --- a/tools/testing/selftests/kvm/lib/memstress.c +++ b/tools/testing/selftests/kvm/lib/memstress.c @@ -56,15 +56,15 @@ void memstress_guest_code(uint32_t vcpu_idx) uint64_t page; int i; - rand_state = new_guest_random_state(args->random_seed + vcpu_idx); + while (true) { + rand_state = new_guest_random_state(args->random_seed + vcpu_idx); - gva = vcpu_args->gva; - pages = vcpu_args->pages; + gva = vcpu_args->gva; + pages = vcpu_args->pages; - /* Make sure vCPU args data structure is not corrupt. */ - GUEST_ASSERT(vcpu_args->vcpu_idx == vcpu_idx); + /* Make sure vCPU args data structure is not corrupt. */ + GUEST_ASSERT(vcpu_args->vcpu_idx == vcpu_idx); - while (true) { for (i = 0; i < pages; i++) { if (args->random_access) page = guest_random_u32(&rand_state) % pages; Paolo
On Wed, Mar 15, 2023, Paolo Bonzini wrote: > On 3/15/23 13:24, Paolo Bonzini wrote: > > On Tue, Mar 14, 2023 at 5:00 PM David Matlack <dmatlack@google.com> wrote: > > > I wonder if pages are getting swapped, especially if running on a > > > workstation. If so, mlock()ing all guest memory VMAs might be > > > necessary to be able to assert exact page counts. > > > > I don't think so, it's 100% reproducible and the machine is idle and > > only accessed via network. Also has 64 GB of RAM. :) > > It also reproduces on Intel with pml=0 and eptad=0; the reason is due > to the different semantics of dirty bits for page-table pages on AMD > and Intel. Both AMD and eptad=0 Intel treat those as writes, therefore > more pages are dropped before the repopulation phase when dirty logging > is disabled. > > The "missing" page had been included in the population phase because it > hosts the page tables for vcpu_args, but repopulation does not need it. > > This fixes it: > > -------------------- 8< --------------- > From: Paolo Bonzini <pbonzini@redhat.com> > Subject: [PATCH] selftests: KVM: perform the same memory accesses on every memstress iteration > > Perform the same memory accesses including the initialization steps > that read from args and vcpu_args. This ensures that the state of > KVM's page tables is the same after every iteration, including the > pages that host the guest page tables for args and vcpu_args. > > This fixes a failure of dirty_log_page_splitting_test on AMD machines, > as well as on Intel if PML and EPT A/D bits are both disabled. > > Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> > > diff --git a/tools/testing/selftests/kvm/lib/memstress.c b/tools/testing/selftests/kvm/lib/memstress.c > index 3632956c6bcf..8a429f4c86db 100644 > --- a/tools/testing/selftests/kvm/lib/memstress.c > +++ b/tools/testing/selftests/kvm/lib/memstress.c > @@ -56,15 +56,15 @@ void memstress_guest_code(uint32_t vcpu_idx) > uint64_t page; > int i; > - rand_state = new_guest_random_state(args->random_seed + vcpu_idx); > + while (true) { > + rand_state = new_guest_random_state(args->random_seed + vcpu_idx); Doesn't this partially defeat the randomization that some tests like want? E.g. a test that wants to heavily randomize state will get the same pRNG for every iteration. Seems like we should have a knob to control whether or not each iteration needs to be identical.
On 3/15/23 20:22, Sean Christopherson wrote: > On Wed, Mar 15, 2023, Paolo Bonzini wrote: >> On 3/15/23 13:24, Paolo Bonzini wrote: >>> On Tue, Mar 14, 2023 at 5:00 PM David Matlack <dmatlack@google.com> wrote: >>>> I wonder if pages are getting swapped, especially if running on a >>>> workstation. If so, mlock()ing all guest memory VMAs might be >>>> necessary to be able to assert exact page counts. >>> >>> I don't think so, it's 100% reproducible and the machine is idle and >>> only accessed via network. Also has 64 GB of RAM. :) >> >> It also reproduces on Intel with pml=0 and eptad=0; the reason is due >> to the different semantics of dirty bits for page-table pages on AMD >> and Intel. Both AMD and eptad=0 Intel treat those as writes, therefore >> more pages are dropped before the repopulation phase when dirty logging >> is disabled. >> >> The "missing" page had been included in the population phase because it >> hosts the page tables for vcpu_args, but repopulation does not need it. >> >> This fixes it: >> >> -------------------- 8< --------------- >> From: Paolo Bonzini <pbonzini@redhat.com> >> Subject: [PATCH] selftests: KVM: perform the same memory accesses on every memstress iteration >> >> Perform the same memory accesses including the initialization steps >> that read from args and vcpu_args. This ensures that the state of >> KVM's page tables is the same after every iteration, including the >> pages that host the guest page tables for args and vcpu_args. >> >> This fixes a failure of dirty_log_page_splitting_test on AMD machines, >> as well as on Intel if PML and EPT A/D bits are both disabled. >> >> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> >> >> diff --git a/tools/testing/selftests/kvm/lib/memstress.c b/tools/testing/selftests/kvm/lib/memstress.c >> index 3632956c6bcf..8a429f4c86db 100644 >> --- a/tools/testing/selftests/kvm/lib/memstress.c >> +++ b/tools/testing/selftests/kvm/lib/memstress.c >> @@ -56,15 +56,15 @@ void memstress_guest_code(uint32_t vcpu_idx) >> uint64_t page; >> int i; >> - rand_state = new_guest_random_state(args->random_seed + vcpu_idx); >> + while (true) { >> + rand_state = new_guest_random_state(args->random_seed + vcpu_idx); > > Doesn't this partially defeat the randomization that some tests like want? E.g. > a test that wants to heavily randomize state will get the same pRNG for every > iteration. Seems like we should have a knob to control whether or not each > iteration needs to be identical. Yes, this wasn't really a full patch, just to prove what the bug is. One possibility to avoid adding a new knob is to do something like: unsigned iteration = 0; rand_state = new_guest_random_state(args->random_seed + vcpu_idx + iteration++); Paolo
On Tue, 31 Jan 2023 18:18:18 +0000, Ben Gardon wrote: > David Matlack recently added a feature known as eager page splitting > to x86 KVM. This feature improves vCPU performance during dirty > logging because the splitting operation is moved out of the page > fault path, avoiding EPT/NPT violations or allowing the vCPU threads > to resolve the violation in the fast path. > > While this feature is a great performance improvement, it does not > have adequate testing in KVM selftests. Add a test to provide coverage > of eager page splitting. > > [...] Applied to kvm-x86 selftests, thanks! [1/2] selftests: KVM: Move dirty logging functions to memstress.(c|h) https://github.com/kvm-x86/linux/commit/de10b798055d [2/2] selftests: KVM: Add dirty logging page splitting test https://github.com/kvm-x86/linux/commit/dfa78a20cc87 -- https://github.com/kvm-x86/linux/tree/next https://github.com/kvm-x86/linux/tree/fixes