kernel/tools/testing/selftests/kvm/dirty_log_test.c, branch linux-rolling-stable

KVM: arm64: selftests: Create a VGICv3 for 'default' VMs

2025-09-24T18:23:32Z

Start creating a VGICv3 by default unless explicitly opted-out by the test. While having an interrupt controller is nice, the real benefit here is clearing a hurdle for EL2 VMs which mandate the presence of a VGIC. Signed-off-by: Oliver Upton Signed-off-by: Marc Zyngier

KVM: selftests: Allow running a single iteration of dirty_log_test

2025-02-12T17:00:56Z

Now that dirty_log_test doesn't require running multiple iterations to verify dirty pages, and actually runs the requested number of iterations, drop the requirement that the test run at least "3" (which was really "2" at the time the test was written) iterations. Link: https://lore.kernel.org/r/20250111003004.1235645-21-seanjc@google.com Signed-off-by: Sean Christopherson

KVM: selftests: Fix an off-by-one in the number of dirty_log_test iterations

2025-02-12T17:00:56Z

Actually run all requested iterations, instead of iterations-1 (the count starts at '1' due to the need to avoid '0' as an in-memory value for a dirty page). Reviewed-by: Maxim Levitsky Link: https://lore.kernel.org/r/20250111003004.1235645-20-seanjc@google.com Signed-off-by: Sean Christopherson

KVM: selftests: Set per-iteration variables at the start of each iteration

2025-02-12T17:00:56Z

Set the per-iteration variables at the start of each iteration instead of setting them before the loop, and at the end of each iteration. To ensure the vCPU doesn't race ahead before the first iteration, simply have the vCPU worker want for sem_vcpu_cont, which conveniently avoids the need to special case posting sem_vcpu_cont from the loop. Link: https://lore.kernel.org/r/20250111003004.1235645-19-seanjc@google.com Signed-off-by: Sean Christopherson

KVM: selftests: Tighten checks around prev iter's last dirty page in ring

2025-02-12T17:00:56Z

Now that each iteration collects all dirty entries and ensures the guest *completes* at least one write, tighten the exemptions for the last dirty page of the previous iteration. Specifically, the only legal value (other than the current iteration) is N-1. Unlike the last page for the current iteration, the in-progress write from the previous iteration is guaranteed to have completed, otherwise the test would have hung. Reviewed-by: Maxim Levitsky Link: https://lore.kernel.org/r/20250111003004.1235645-18-seanjc@google.com Signed-off-by: Sean Christopherson

KVM: selftests: Ensure guest writes min number of pages in dirty_log_test

2025-02-12T17:00:56Z

Ensure the vCPU fully completes at least one write in each dirty_log_test iteration, as failure to dirty any pages complicates verification and forces the test to be overly conservative about possible values. E.g. verification needs to allow the last dirty page from a previous iteration to have *any* value, because the vCPU could get stuck for multiple iterations, which is unlikely but can happen in heavily overloaded and/or nested virtualization setups. Somewhat arbitrarily set the minimum to 0x100/256; high enough to be interesting, but not so high as to lead to pointlessly long runtimes. Opportunistically report the number of writes per iteration for debug purposes, and so that a human can sanity check the test. Due to each write targeting a random page, the number of dirty pages will likely be lower than the number of total writes, but it shouldn't be absurdly lower (which would suggest the pRNG is broken) Reported-by: Maxim Levitsky Reviewed-by: Maxim Levitsky Link: https://lore.kernel.org/r/20250111003004.1235645-17-seanjc@google.com Signed-off-by: Sean Christopherson

KVM: sefltests: Verify value of dirty_log_test last page isn't bogus

2025-02-12T17:00:56Z

Add a sanity check that a completely garbage value wasn't written to the last dirty page in the ring, e.g. that it doesn't contain the *next* iteration's value. Reviewed-by: Maxim Levitsky Link: https://lore.kernel.org/r/20250111003004.1235645-16-seanjc@google.com Signed-off-by: Sean Christopherson

KVM: selftests: Collect all dirty entries in each dirty_log_test iteration

2025-02-12T17:00:56Z

Collect all dirty entries during each iteration of dirty_log_test by doing a final collection after the vCPU has been stopped. To deal with KVM's destructive approach to getting the dirty bitmaps, use a second bitmap for the post-stop collection. Collecting all entries that were dirtied during an iteration simplifies the verification logic *and* improves test coverage. - If a page is written during iteration X, but not seen as dirty until X+1, the test can get a false pass if the page is also written during X+1. - If a dirty page used a stale value from a previous iteration, the test would grant a false pass. - If a missed dirty log occurs in the last iteration, the test would fail to detect the issue. E.g. modifying mark_page_dirty_in_slot() to dirty an unwritten gfn: if (memslot && kvm_slot_dirty_track_enabled(memslot)) { unsigned long rel_gfn = gfn - memslot->base_gfn; u32 slot = (memslot->as_id << 16) | memslot->id; if (!vcpu->extra_dirty && gfn_to_memslot(kvm, gfn + 1) == memslot) { vcpu->extra_dirty = true; mark_page_dirty_in_slot(kvm, memslot, gfn + 1); } if (kvm->dirty_ring_size && vcpu) kvm_dirty_ring_push(vcpu, slot, rel_gfn); else if (memslot->dirty_bitmap) set_bit_le(rel_gfn, memslot->dirty_bitmap); } isn't detected with the current approach, even with an interval of 1ms (when running nested in a VM; bare metal would be even *less* likely to detect the bug due to the vCPU being able to dirty more memory). Whereas collecting all dirty entries consistently detects failures with an interval of 700ms or more (the longer interval means a higher probability of an actual write to the prematurely-dirtied page). Link: https://lore.kernel.org/r/20250111003004.1235645-15-seanjc@google.com Signed-off-by: Sean Christopherson

KVM: selftests: Print (previous) last_page on dirty page value mismatch

2025-02-12T17:00:56Z

Print out the last dirty pages from the current and previous iteration on verification failures. In many cases, bugs (especially test bugs) occur on the edges, i.e. on or near the last pages, and being able to correlate failures with the last pages can aid in debug. Reviewed-by: Maxim Levitsky Link: https://lore.kernel.org/r/20250111003004.1235645-14-seanjc@google.com Signed-off-by: Sean Christopherson

KVM: selftests: Use continue to handle all "pass" scenarios in dirty_log_test

2025-02-12T17:00:55Z

When verifying pages in dirty_log_test, immediately continue on all "pass" scenarios to make the logic consistent in how it handles pass vs. fail. No functional change intended. Reviewed-by: Maxim Levitsky Link: https://lore.kernel.org/r/20250111003004.1235645-13-seanjc@google.com Signed-off-by: Sean Christopherson

kernel/tools/testing/selftests/kvm/dirty_log_test.c, branch linux-rolling-stable

KVM: arm64: selftests: Create a VGICv3 for 'default' VMs

KVM: selftests: Allow running a single iteration of dirty_log_test

KVM: selftests: Fix an off-by-one in the number of dirty_log_test iterations

KVM: selftests: Set per-iteration variables at the start of each iteration

KVM: selftests: Tighten checks around prev iter's last dirty page in ring

KVM: selftests: Ensure guest writes min number of pages in dirty_log_test

KVM: sefltests: Verify value of dirty_log_test last page isn't bogus

KVM: selftests: Collect *all* dirty entries in each dirty_log_test iteration

KVM: selftests: Print (previous) last_page on dirty page value mismatch

KVM: selftests: Use continue to handle all "pass" scenarios in dirty_log_test

KVM: selftests: Collect all dirty entries in each dirty_log_test iteration