Re: [PATCH v6 7/7] KVM: SVM: Add Page modification logging support

Huang, Kai
2026-04-21T23:50:56Z

On Tue, 2026-04-21 at 08:08 -0700, Sean Christopherson wrote:
> >    vCPU Reset:
> >      vcpu_enter_guest()
> >        ├─> kvm_check_request(KVM_REQ_EVENT)
> >        ├─> kvm_apic_accept_events()
> >        │     └─> kvm_vcpu_reset(..., true)
> >        │           └─> init_vmcb(..., true)
> >        │                 └─> control->pml_index = PML_HEAD_INDEX -- PML buffer was already flushed
> >        └─> kvm_x86_call(): Next VMRUN
> >
> > > Could this result in the hypervisor losing track of dirty memory during live
> > > migration, leading to memory corruption on the destination host, since
> > > svm_flush_pml_buffer() isn't called before resetting the index?
> >
> > AFAIU, no. The PML buffer is always flushed opportunistically at every VM exit.
>
> Huh.  There's a pre-existing bug here.  Commit f7f39c50edb9 ("KVM: x86: Exit to
> userspace if fastpath triggers one on instruction skip") added a path that skips
> kvm_x86_ops.handle_exit(), and specifically can give userspace control without
> going through vmx_flush_pml_buffer():
>
> if (unlikely(exit_fastpath == EXIT_FASTPATH_EXIT_USERSPACE))
> return 0;
>
> r = kvm_x86_call(handle_exit)(vcpu, exit_fastpath);
>
> Given that SVM support for PML is (obviously) on its way, it's mildly tempting
> to add a dedicated kvm_x86_ops hook to flush the buffer on a fastpath userspace
> exit.  But, I dislike one-off kvm_x86_ops hooks, and that only works if there's
> no other vendor action required.  E.g. very theoretically, a fastpath userspace
> exit could also be coincident with bus_lock_detected.

Seems vmx_vcpu_reset() doesn't reset PML index upon INIT event, which seems
to be fine since we are not losing any dirty GPA tracking AFAICT (otherwise
we already have a bug for VMX here)?

How about doing the same for SVM?

Alternatively, we can always manually flush PML buffer upon INIT before
resetting PML index. This still allows to do the
EXIT_FASTPATH_EXIT_USERSPACE check in the common code.

Not sure which way is better, though.