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

[Sean Christopherson <seanjc@google.com>]

On Tue, Apr 21, 2026, Kai Huang wrote:
> 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?

We don't really have that luxury.  On SHUTDOWN (even intercepted SHUTDOWN), the
state of the VMCB is technically undefined.  I.e. KVM needs to write _something_.

Hmm, actually, how is that going to work?  Dropping PML entries just because a
vCPU hit SHUTDOWN isn't going to fly.  E.g. if a VM crashes while it's being
migrated by the host, then it could end up with corrupted, incoherent data on
the target due to leaving dirtied pages behind.

> 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.