Re: [PATCH v4 00/13] KVM: Dirty ring support (QEMU part)

[Peter Xu]

On Fri, Jan 08, 2021 at 11:45:48AM -0500, Peter Xu wrote:
> This is v4 of the qemu dirty ring interface support.
> 
> It is merely the same as v3 content-wise, but there're a few things to mention
> besides the rebase itself:
> 
>   - I picked up two patches from Eric Farman for the linux-header updates 
> (from
>     Eric's v3 series) for convenience just in case any of the series would got
>     queued by any maintainer.
> 
>   - One more patch is added as "KVM: Disable manual dirty log when dirty ring
>     enabled".  I found this when testing the branch after rebasing to latest
>     qemu, that not only the manual dirty log capability is not needed for kvm
>     dirty ring, but more importantly INITIALLY_ALL_SET is totally against kvm
>     dirty ring and it could silently crash the guest after migration.  For 
> this
>     new commit, I touched up "KVM: Add dirty-gfn-count property" a bit.
> 
>   - A few more documentation lines in qemu-options.hx.
> 
>   - I removed the RFC tag after kernel series got merged.
> 
> Again, this is only the 1st step to support dirty ring.  Ideally dirty ring
> should grant QEMU the possibility to remove the whole layered dirty bitmap so
> that dirty ring will work similarly as auto-converge enabled but should 
> better;
> we will just throttle vcpus with the dirty ring kvm exit rather than 
> explicitly
> adding a timer to stop the vcpu thread from entering the guest again (like 
> what
> we did with current migration auto-converge).  Some more information could 
> also
> be found in the kvm forum 2020 talk regarding kvm dirty ring (slides 21/22 
> [1]).
> 
> That next step (to remove all the dirty bitmaps, as mentioned above) is still
> discussable: firstly I don't know whether there's anything I've overlooked in
> there.  Meanwhile that's also only services huge VM cases, may not be 
> extremely
> helpful with a lot major scenarios where VMs are not that huge.
> 
> There's probably other ways to fix huge VM migration issues, majorly focusing
> on responsiveness and convergence.  For example, Google has proposed some new
> userfaultfd kernel capability called "minor modes" [2] to track page minor
> faults and that could be finally served for that purpose too using postcopy.
> That's another long story so I'll stop here, but just as a marker along with
> the dirty ring series so there'll still be a record to reference.
> 
> Said that, I still think this series is very worth merging even if we don't
> persue the next steps yet, since dirty ring is disabled by default, and we can
> always work upon this series.
> 
> Please review, thanks.

Ping - Paolo, what would be your take on this series?

Thanks,

-- 
Peter Xu