Am 09.12.2016 um 16:26 schrieb Paolo Bonzini:
On 30/11/2016 21:03, Jim Mattson wrote:+#define KVM_VMX_STATE_GUEST_MODE 0x00000001 +#define KVM_VMX_STATE_RUN_PENDING 0x00000002 + +/* for KVM_CAP_VMX_STATE */ +struct kvm_vmx_state { + __u64 vmxon_ptr; + __u64 current_vmptr; + __u32 flags; + __u32 data_size; + __u8 data[0]; +};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]; David, would the above make sense for s390 nested SIE too?
s390x doesn't have _any_ SIE state in the hardware. All g2 state is in g1 memory and therefore migrated. So there is nothing needed at that point for migration. It just works :) shadowed SCBs (SIE control blocks) are simply recreated on the target (after every VSIE execution, we write the data back into g1, so whenever we leave the interception handler, we act according to the SIE architecture). I would have thought that migrating the current VMLOAD and VMXON PTR (+ VMX state) should also be enough for VMX, but I haven't looked into the details of vmcs shadowing/caching yet that Jim mentioned. BTW, I assume we can't migrate while having a nested guest from Intel to AMD. Are there any checks in place for that? (being new to x86, is it even possible at all to migrate a guest from AMD <-> Intel? I assume so with apropriate CPU models). -- 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
