2016-04-29 18:47+0000, Cao, Lei: > On 4/28/2016 2:08 PM, Radim Krčmář wrote: >> 2016-04-26 19:26+0000, Cao, Lei: >> * 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. Makes sense. >> * 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. True, mandatory polling could be ugly. >> * 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. Ah, it makes a difference when you don't plan to run the VM again. I guess all three of them are worth it. (Might change my mind when I gain better understanding.) >> * What drawbacks had an interface without explicit checkpointing cycles? > > Checkpointing cycle has to be implemented in userspace to use this > interface. But isn't the explicit cycle necessary only in userspace? The dirty list could be implemented as a circullar buffer, so KVM wouldn't need an explicit notification about the new cycle -- the userspace would just drain all dirty pages and unpause vcpus. (Quiesced can be stateless one-time kick of waiters instead.) 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
