Re: [PATCH 6/6] KVM: Dirty memory tracking for performant checkpointing and improved live migration

["Radim Krčmář" <rkrcmar@redhat.com>]

2016-04-26 19:26+0000, Cao, Lei:
> Updates to KVM API documentation
> ---

I have five broad questions about design of the interface:

* Why are IOCTLs marked with "Called once when entering live
  migration/checkpoint mode" separate from KVM_INIT_MT?
* Is there a reason to call KVM_ENABLE_MT often?
* How significant is the benefit of MT_FETCH_WAIT?
* When would you disable MT_FETCH_REARM?
* What drawbacks had an interface without explicit checkpointing cycles?

> diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
> @@ -3120,6 +3120,176 @@ struct kvm_reinject_control {

A bit to the code itself:

> +4.99 KVM_INIT_MT
> +
> +Capability: basic

"basic" ioctls were present since the first version of KVM.
We can't change the past, so please add a new capability.

> +4.102 KVM_MT_SUBLIST_FETCH
> +
> +Capability: basic
> +Architectures: x86
> +Type: vm ioctl
> +Parameters: struct mt_sublist_fetch_info (in/out)
> +Returns: 0 on success, -1 on error
> +
> +/* for KVM_MT_SUBLIST_FETCH */
> +struct mt_gfn_list {
> +        __s32   count;
> +        __u32   max_dirty;
> +        __u64   *gfnlist;

gfn (= gpa >> PAGE_SHIFT) is not enough to specify a page for userspace,
because KVM has a concept of address spaces and pages from multiple
slots can be mapped into the same gfn (e.g. x86 SMRAM).

Providing a memslot/offset pair seems best.  (I'd start by addressing
Kai's comment on [3/6] about binding gfnlist to memslots.)

Thanks.