On 05/12/2011 07:51 PM, Gleb Natapov wrote:
> > But if my interpretation of the code is correct, SVM isn't much closer > than VMX to the goal of moving this logic to x86.c. When some logic is > moved there, both SVM and VMX code will need to change - perhaps even > considerably. So how will it be helpful to make VMX behave exactly like > SVM does now, when the latter will also need to change considerably? > SVM design is much close to the goal of moving the logic into x86.c because IIRC it does not bypass parsing of IDT vectoring info into arch independent structure. VMX code uses vmx->idt_vectoring_info directly. SVM is much close to working migration with nested guests for the same reason.
Ah, yes. For live migration to work, all vmcb state must be accessible via vendor-independent accessors once an exit is completely handled. For example, GPRs are accessible via kvm_register_read(), and without nesting, interrupt state is stowed in the interrupt queue, but if you keep IDT_VECTORING_INFO live between exit and entry, you can lose it if you migrate at this point.
-- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
