Re: [PATCH 7/8] kvm: nVMX: Introduce KVM_CAP_VMX_STATE

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 19.12.2017 22:29, Paolo Bonzini wrote:
> On 19/12/2017 20:21, Jim Mattson wrote:
>> One reason is that it is a bit awkward for GET_NESTED_STATE to modify
>> guest memory. I don't know about qemu, but our userspace agent expects
>> guest memory to be quiesced by the time it starts going through its
>> sequence of GET_* ioctls. Sure, we could introduce a pre-migration
>> ioctl, but is that the best way to handle this? Another reason is that
>> it is a bit awkward for SET_NESTED_STATE to require guest memory.
>> Again, I don't know about qemu, but our userspace agent does not
>> expect any guest memory to be available when it starts going through
>> its sequence of SET_* ioctls. Sure, we could prefetch the guest page
>> containing the current VMCS12, but is that better than simply
>> including the current VMCS12 in the NESTED_STATE payload? Moreover,
>> these unpredictable (from the guest's point of view) updates to guest
>> memory leave a bad taste in my mouth (much like SMM).
> 
> IIRC QEMU has no problem with either, but I think your concerns are
> valid.  The active VMCS is processor state, not memory state.  Same for
> the host save data in SVM.
> 
> The unstructured "blob" of data is not an issue.  If it becomes a
> problem, we can always document the structure...

Thinking about it, I agree. It might be simpler/cleaner to transfer the
"loaded" VMCS. But I think we should take care of only transferring data
that actually is CPU state and not special to our current
implementation. (e.g. nested_run_pending I would says is special to out
current implementation, but we can discuss)

So what I would consider VMX state:
- vmxon
- vmxon_ptr
- vmptr
- cached_vmcs12
- ... ?

> 
> Paolo


-- 

Thanks,

David / dhildenb



[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux