Gleb Natapov <gleb@xxxxxxxxxx> wrote on 17/04/2013 06:39:01 PM: > On Wed, Apr 17, 2013 at 05:59:50PM +0300, Abel Gordon wrote: > > > > > > Gleb Natapov <gleb@xxxxxxxxxx> wrote on 17/04/2013 05:34:49 PM: > > > > > > @@ -5716,6 +5725,10 @@ static void nested_vmx_failValid(struct > > > > X86_EFLAGS_SF | X86_EFLAGS_OF)) > > > > | X86_EFLAGS_ZF); > > > > get_vmcs12(vcpu)->vm_instruction_error = vm_instruction_error; > > > > + /* > > > > + * We don't need to force a shadow sync because > > > > + * VM_INSTRUCTION_ERROR is not shdowed > > > ---------------------------------------^ shadowed. > > > But lets just request sync. This is slow path anyway. > > > > Why then ? > Because we do not care how fast the error case is handled, so no point > breaking the rules for it. Yep, so let's just keep it as a not shadowed field. We don't break the rules, we just don't use an acceleration feature for the error path (trap and emulate vmreads for this field as usual). > > Note this will require to call copy_shadow_to_vmcs12 > > because nested_vmx_failValid can be called while L0 handles a L1 > > exit (for vmx instruction emulation) and the shadow vmcs could > > have been modified by L1 before the exit. > > > Right, not a big deal if this is the only case when it happens. When we > discussed accessors vs sync_shadow_vmcs flag approach I said that flag > will work only if no vmcs12 fields are changed not as part of vmexit or > vmwrite emulations. This one is such a field unfortunately. Hope it is > the only one. Yep, remember that. I answered that L0 should NOT change VMCS12 fields if L1 is running and L1 didn't execute any vmlaunch, vmresume, vmwrite... (any vmx instruction. Sorry if I wasn't clear). nested_vmx_failValid is called ONLY when L1 executes vmx instructions which L0 traps and emulate. So, can we keep this part of the code as is ? -- 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
