On 4/28/2016 2:08 PM, Radim Krčmář wrote:
> 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?
KVM_MT_DIRTY_TRIGGER can be folded into KVM_INIT_MT. I'll change that.
> * Is there a reason to call KVM_ENABLE_MT often?
KVM_ENABLE_MT can be called multiple times during a protected
VM's lifecycle in a checkpointing system. A protected VM has two
instances, primary and secondary. Memory tracking is only enabled on
the primary. When we do a polite failover, memory tracking is
disabled on the old primary and enabled on the new primary. Memory
tracking is also disabled when the secondary goes away, in which case
checkpoint cycle stops and there is no need for memory tracking. When
the secondary comes back, memory tracking is re-enabled and the two
instances sync up and checkpoint cycle starts.
> * How significant is the benefit of MT_FETCH_WAIT?
This allows the user thread that harvest dirty pages to park instead
of doing busy wait when there is no or very few dirty pages.
> * When would you disable MT_FETCH_REARM?
In a checkpointing system, dirty pages are harvested after the VM is
paused. Userspace can choose to rearm the write traps all at once after
all the dirty pages have been fetched using KVM_REARM_DIRTY_PAGES, in
which case the traps don't need to be armed during each fetch.
> * What drawbacks had an interface without explicit checkpointing cycles?
Checkpointing cycle has to be implemented in userspace to use this
interface.
>
>> 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.
>
Will do.
>> +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.
>
I'll respond to your latest comments about memslot/offset.
Thanks!
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
