From: Wu Fei <atwufei@163.com>
To: Sean Christopherson <seanjc@google.com>
Cc: wu.fei9@sanechips.com.cn, linux-riscv@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
kvm@vger.kernel.org, kvm-riscv@lists.infradead.org,
anup@brainfault.org, atish.patra@linux.dev, pjw@kernel.org,
palmer@dabbelt.com, aou@eecs.berkeley.edu, alex@ghiti.fr,
pbonzini@redhat.com, shuah@kernel.org
Subject: Re: [PATCH 1/3] KVM: selftests: Add unit to dirty_log_test
Date: Mon, 18 May 2026 20:52:37 +0800 [thread overview]
Message-ID: <22e32ff9-3d79-4130-a3cb-3a4ec2efd498@163.com> (raw)
In-Reply-To: <agck1WqW-TyEqkqd@google.com>
On 5/15/26 21:51, Sean Christopherson wrote:
> On Wed, May 13, 2026, Wu Fei wrote:
>> On 5/13/26 08:03, Sean Christopherson wrote:
>>> On Mon, May 11, 2026, wu.fei9@sanechips.com.cn wrote:
>>>> Currently dirty_log_test hardcodes usleep 1ms in each interval, which
>>>> could be too short for guest to write and fault in enough pages, then
>>>> there is less chance to test the write protection mechanism, especially
>>>> in the case of (log_mode != LOG_MODE_DIRTY_RING).
>>>
>>> But when log_mode != LOG_MODE_DIRTY_RING, the individual sleep time is largely
>>> meaningless, because the test won't reap the bitmaps for iterations > 0.
>>>
>>> if (i && host_log_mode != LOG_MODE_DIRTY_RING)
>>> continue;
>>>
>> The first usleep matters in the case of KVM_DIRTY_LOG_INITIALLY_SET. The
>> dirty bitmap is not precise in the first get_dirty_log, all pages are marked
>> as dirty but most of them are not populated in page table, this creates the
>> situation I mentioned in the cover letter.
>
> I suspect something is messed up in your workflow, because the actual patches
> aren't properly threaded with respect to the cover letter. E.g. patch 1 has
>
> In-Reply-To: <202605111849442561v1a0B_7W1L2Z-ENusLaP@zte.com.cn>
>
> but the cover letter has:
>
> Message-Id: <202605111108.64BB8RFR010522@mse-db.zte.com.cn>
>
> Copy+pasting the entirety of the cover letter for reference:
>
> : The current gstage range walker unconditionally advances by 'page_size'
> : when a leaf PTE is not found, e.g. when the range to wp is
> : [0xfffff01fc000, 0xfffff023c000) , if found_leaf of 0xfffff01fc000
> : returns false and page_size is 2MB, it skips the whole range, but it's
> : possible to have valid entries in [0xfffff0200000, 0xfffff023c000), so
> : only [0xfffff01fc000, 0xfffff0200000) can be skipped safely. Both
> : wp/unamp have the same pattern.
> :
> : dirty_log_test intentionally sets up the unaligned guest physical
> : address, after riscv kvm enabling KVM_DIRTY_LOG_INITIALLY_SET, it's easy
> : to trigger this bug if there is a larger window for guest to write more
> : pages before first collect_dirty_pages.
>
>> "when the range to wp is
>> [0xfffff01fc000, 0xfffff023c000) , if found_leaf of 0xfffff01fc000
>> returns false and page_size is 2MB, it skips the whole range, but it's
>> possible to have valid entries in [0xfffff0200000, 0xfffff023c000), so
>> only [0xfffff01fc000, 0xfffff0200000) can be skipped safely."
>>
>>>>
>>>> Unit is introduced to replace the default 1ms if specified in command
>>>> line. The following test can't trigger failure on my riscv vm:
>>>
>>> Failure of what? And does the failure really not reproduce with a higher interval?
>>
>> On riscv, it fails to write protect some pages with valid page table entry
>> then loses track of dirty pages. Higher interval doesn't help because only
>> the first usleep matters, after the first collect_dirty_pages, all dirty
>> pages are tracked precisely then there is no such problem.
>
> Ah, gotcha. Rather than let (and force) the user to provide a larger sleep time,
> what if we instead randomize the delay before the initial reaping of the dirty
> bitmap/ring? That should provide a good balance between coverage, complexity and
> user-friendliness.
I'm fine with your solution, I applied it and it did trigger the same issue.
Thanks,
Fei.
>
> diff --git a/tools/testing/selftests/kvm/dirty_log_test.c b/tools/testing/selftests/kvm/dirty_log_test.c
> index 12446a4b6e8d..74ca096bf976 100644
> --- a/tools/testing/selftests/kvm/dirty_log_test.c
> +++ b/tools/testing/selftests/kvm/dirty_log_test.c
> @@ -694,7 +694,17 @@ static void run_test(enum vm_guest_mode mode, void *arg)
> pthread_create(&vcpu_thread, NULL, vcpu_worker, vcpu);
>
> for (iteration = 1; iteration <= p->iterations; iteration++) {
> - unsigned long i;
> + unsigned long i, reap_i;
> +
> + /*
> + * Select a random point in the time interval to reap the dirty
> + * bitmap/ring while the guest is running, i.e. randomize how
> + * long the guest gets to initially run and thus how many pages
> + * it can dirty, before collecting the dirty bitmap/ring. See
> + * the loop below for details.
> + */
> + reap_i = random() % p->interval;
> + printf("Reaping after a %lu ms delay\n", reap_i);
>
> sync_global_to_guest(vm, iteration);
>
> @@ -729,13 +739,17 @@ static void run_test(enum vm_guest_mode mode, void *arg)
> * that's effectively blocked. Collecting while the
> * guest is running also verifies KVM doesn't lose any
> * state.
> - *
> + */
> + if (i < reap_i)
> + continue;
> +
> + /*
> * For bitmap modes, KVM overwrites the entire bitmap,
> * i.e. collecting the bitmaps is destructive. Collect
> - * the bitmap only on the first pass, otherwise this
> - * test would lose track of dirty pages.
> + * the bitmap while the guest is running only once,
> + * otherwise this test would lose track of dirty pages.
> */
> - if (i && host_log_mode != LOG_MODE_DIRTY_RING)
> + if (i > reap_i && host_log_mode != LOG_MODE_DIRTY_RING)
> continue;
>
> /*
> @@ -745,7 +759,7 @@ static void run_test(enum vm_guest_mode mode, void *arg)
> * the ring on every pass would make it unlikely the
> * vCPU would ever fill the fing).
> */
> - if (i && !READ_ONCE(dirty_ring_vcpu_ring_full))
> + if (i > reap_i && !READ_ONCE(dirty_ring_vcpu_ring_full))
> continue;
>
> log_mode_collect_dirty_pages(vcpu, TEST_MEM_SLOT_INDEX,
next prev parent reply other threads:[~2026-05-18 12:55 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <202605111849442561v1a0B_7W1L2Z-ENusLaP@zte.com.cn>
2026-05-11 11:23 ` wu.fei9
2026-05-13 0:03 ` Sean Christopherson
2026-05-13 12:27 ` Wu Fei
2026-05-15 13:51 ` Sean Christopherson
2026-05-18 12:52 ` Wu Fei [this message]
2026-05-18 13:25 ` Sean Christopherson
2026-05-11 11:24 ` [PATCH 2/3] RISC-V: KVM: Fix skip of valid pages in kvm_riscv_gstage_wp_range wu.fei9
2026-06-02 8:00 ` Anup Patel
2026-05-11 11:29 ` [PATCH 3/3] RISC-V: KVM: Fix skip of valid pages in kvm_riscv_gstage_unmap_range wu.fei9
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=22e32ff9-3d79-4130-a3cb-3a4ec2efd498@163.com \
--to=atwufei@163.com \
--cc=alex@ghiti.fr \
--cc=anup@brainfault.org \
--cc=aou@eecs.berkeley.edu \
--cc=atish.patra@linux.dev \
--cc=kvm-riscv@lists.infradead.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=pbonzini@redhat.com \
--cc=pjw@kernel.org \
--cc=seanjc@google.com \
--cc=shuah@kernel.org \
--cc=wu.fei9@sanechips.com.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®