The VMCS cache can be safely flushed to guest memory at any time.
However, I think your proposal has some unfortunate consequences:
1. If KVM_SET_NESTED_STATE is asynchronous, then any subsequent set
operations (e.g. KVM_SET_SREGS) may be overridden on the next KVM_RUN.
2. Guest memory (at least the cached VMCS page(s)) has to be saved
after KVM_GET_NESTED_STATE.
3. KVM_GET_NESTED_STATE is not transparent to the guest.
On Wed, Feb 15, 2017 at 3:56 AM, Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote:
>
>
> On 09/12/2016 16:26, Paolo Bonzini wrote:
>> Let's prepare the API for nested SVM too. Please rename it to
>> KVM_CAP/GET/SET_NESTED_STATE and let's organize it like this:
>>
>> /* In addition to guest mode and run pending, please
>> * add one for GIF.
>> */
>> __u16 flags;
>> /* 0 for VMX, 1 for SVM. */
>> __u16 format;
>> /* 128 for SVM, 128 + VMCS size for VMX. */
>> __u32 size;
>> /* Both structs padded to 120 bytes. */
>> union {
>> /* VMXON, VMCS */
>> struct kvm_vmx_state vmx;
>> /* HSAVE_PA, VMCB */
>> struct kvm_svm_state svm;
>> }
>> __u8 data[0];
>
> Thinking again about this, do we really need to store the VMCS in the
> ioctl? What would be the issues if we just flushed it to memory and
> reloaded it at KVM_REQ_GET_VMCS12_PAGES time?
>
> Paolo
