Am 30.11.2016 um 21:03 schrieb Jim Mattson:
This series of patches introduces checkpoint and restore operations for the VMX state of a VM, so that VMX-capable VMs can be migrated. Two new ioctls are introduced: KVM_GET_VMX_STATE and KVM_SET_VMX_STATE. The VMX state that is checkpointed/restored consists of the VMXON region address (if any), the current VMCS address (if any), and the cached current VMCS contents (if any). One piece of implementation-specific state that is also checkpointed/restored is the nested_run_pending bit. On live migration, our userspace process does not have access to guest memory when the VM is set up on the target host, so some operations that require a GPA->HPA mapping are deferred until the next vcpu_run using a new vcpu request.
This somewhat smells like giving user space the ability to directly control hardware virtualization. Will there be performed all security/filter actions on the passed in data just as when preparing the shadow vmcs? IOW could this interface allow user space to run anything unfiltered using vmx?
Why exactly can't we simply copy/filter from guest memory? (you mention that this is not available when setting up VM on the target - why can't we defer that completely then?).
-- 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
-- David -- 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
