All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v3 0/3] KVM: Do not reset dirty GFNs in a memslot not enabling dirty tracking
@ 2025-08-22  8:01 Yan Zhao
  2025-08-22  8:02 ` [PATCH v3 1/3] " Yan Zhao
                   ` (2 more replies)
  0 siblings, 3 replies; 8+ messages in thread
From: Yan Zhao @ 2025-08-22  8:01 UTC (permalink / raw)
  To: pbonzini, seanjc; +Cc: peterx, rick.p.edgecombe, linux-kernel, kvm, Yan Zhao

Hi,
This series addresses a bug where userspace can request KVM to reset dirty
GFNs in memslots that do not have dirty tracking enabled.

Patch 1 provides the fix.
Patch 2 is an optimization to avoid unnecessary invoking of handlers in
        kvm_handle_hva_range() when a GFN range is entirely private.

        Patch 2 is not directly related to the issue in this series, but
        was found while implementing the selftest in patch 3. It also
        enhance reliability of the selftest results in patch 3 by ruling
        out the zap-related changes to private mappings of the test slot.

Patch 3 converts the TDX-specific selftest in v2 to test
        KVM_X86_SW_PROTECTED_VM VMs.

        Unlike TDX cases which would generate KVM_BUG_ON() when GFNs are
        incorrectly reset in memslots not enabling dirty tracking, there
        are not obvious errors for KVM_X86_SW_PROTECTED_VMs. So, patch 3
        detects the event kvm_tdp_mmu_spte_changed instead.

        Will provide TDX cases once the TDX selftest framework is
        finalized.

v3:
- Rebased patch 1.
- Added patch 2.
- Converted patch 3 to test KVM_X86_SW_PROTECTED_VM VMs.
- code base: kvm-x86-next-2025.08.21

v2: https://lore.kernel.org/all/20241223070427.29583-1-yan.y.zhao@intel.com
- Added a comment in patch 1, explaining that it's possible to try to
  update a memslot that isn't being dirty-logged if userspace is
  misbehaving. Specifically, userspace can write arbitrary data into the
  ring. (Sean)

v1: https://lore.kernel.org/all/20241220082027.15851-1-yan.y.zhao@intel.com


Yan Zhao (3):
  KVM: Do not reset dirty GFNs in a memslot not enabling dirty tracking
  KVM: Skip invoking shared memory handler for entirely private GFN
    ranges
  KVM: selftests: Test resetting dirty ring in gmem slots in protected
    VMs

 tools/testing/selftests/kvm/Makefile.kvm      |   1 +
 .../kvm/x86/reset_dirty_ring_on_gmem_test.c   | 392 ++++++++++++++++++
 virt/kvm/dirty_ring.c                         |   8 +-
 virt/kvm/kvm_main.c                           |  11 +
 4 files changed, 411 insertions(+), 1 deletion(-)
 create mode 100644 tools/testing/selftests/kvm/x86/reset_dirty_ring_on_gmem_test.c

-- 
2.43.2


^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2025-08-26  6:52 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-08-22  8:01 [PATCH v3 0/3] KVM: Do not reset dirty GFNs in a memslot not enabling dirty tracking Yan Zhao
2025-08-22  8:02 ` [PATCH v3 1/3] " Yan Zhao
2025-08-25 20:42   ` Sean Christopherson
2025-08-26  1:22     ` Yan Zhao
2025-08-22  8:02 ` [PATCH v3 2/3] KVM: Skip invoking shared memory handler for entirely private GFN ranges Yan Zhao
2025-08-25 21:05   ` Sean Christopherson
2025-08-26  6:51     ` Yan Zhao
2025-08-22  8:03 ` [PATCH v3 3/3] KVM: selftests: Test resetting dirty ring in gmem slots in protected VMs Yan Zhao

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.