On Tue, Dec 6, 2016 at 1:04 AM, David Hildenbrand <david@xxxxxxxxxx> wrote:
> 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?
All of the validity checks are performed on the VMX settings provided
from userspace.
set_vmx_state() checks that the VMXON region address is valid.
Set_vmcs_caches() checks that the current VMCS address is valid and
doesn't match the VMXON region address, and it calls
check_vmentry_prereqs() and check_vmentry_postreqs() on the contents
of the VMCS cache.
> 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?).
After the L1 VM has executed VMPTRLD, the authoritative VMCS12 data is
in L0 kernel memory (the VMCS cache) rather than in L1 guest memory.
[See commit 4f2777bc9797 ("kvm: x86: nVMX: maintain internal copy of
current VMCS").] There are many reasons why userspace may want access
to the data in the vCPU's VMCS cache in addition to live migration.
For example, a userspace instruction emulator may need access to
several VMCS fields to determine how to emulate an instruction when
the vCPU is in virtualized VMX non-root mode.
>> --
>> 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
