On Sat, Mar 21, 2020 at 12:12:50PM -0700, Sean Christopherson wrote: > On Wed, Mar 18, 2020 at 12:37:12PM -0400, Peter Xu wrote: > > There's no good reason to use both the dirty bitmap logging and the > > new dirty ring buffer to track dirty bits. We should be able to even > > support both of them at the same time, but it could complicate things > > which could actually help little. Let's simply make it the rule > > before we enable dirty ring on any arch, that we don't allow these two > > interfaces to be used together. > > > > The big world switch would be KVM_CAP_DIRTY_LOG_RING capability > > enablement. That's where we'll switch from the default dirty logging > > way to the dirty ring way. As long as kvm->dirty_ring_size is setup > > correctly, we'll once and for all switch to the dirty ring buffer mode > > for the current virtual machine. > > > > Signed-off-by: Peter Xu <peterx@xxxxxxxxxx> > > --- > > Documentation/virt/kvm/api.rst | 7 +++++++ > > virt/kvm/kvm_main.c | 12 ++++++++++++ > > 2 files changed, 19 insertions(+) > > > > diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst > > index 99ee9cfc20c4..8f3a83298d3f 100644 > > --- a/Documentation/virt/kvm/api.rst > > +++ b/Documentation/virt/kvm/api.rst > > @@ -6202,3 +6202,10 @@ make sure all the existing dirty gfns are flushed to the dirty rings. > > > > The dirty ring can gets full. When it happens, the KVM_RUN of the > > vcpu will return with exit reason KVM_EXIT_DIRTY_LOG_FULL. > > + > > +NOTE: the KVM_CAP_DIRTY_LOG_RING capability and the new ioctl > > Leave off "new", it'll be stale a few months/years from now. Ok. > > > +KVM_RESET_DIRTY_RINGS are exclusive to the existing KVM_GET_DIRTY_LOG > > Did you mean "mutually exclusive with"? "exclusive to" would mean they > can only be used by KVM_GET_DIRTY_LOG with doesn't match the next > sentence. I meant "mutual-exclusive". I'll fix it up. Thanks, -- Peter Xu
