Re: [PATCH 2/5] KVM: nVMX: Skip VM-Exit Control vmentry checks that are necessary only if VMCS12 is dirty

[Sean Christopherson <sean.j.christopherson@intel.com>]

On Wed, Jul 10, 2019 at 12:18:55PM -0700, Krish Sadhukhan wrote:
> 
> On 7/10/19 7:28 AM, Paolo Bonzini wrote:
> >On 07/07/19 09:11, Krish Sadhukhan wrote:
> >>  	if (!vmx_control_verify(vmcs12->vm_exit_controls,
> >>  				vmx->nested.msrs.exit_ctls_low,
> >>-				vmx->nested.msrs.exit_ctls_high) ||
> >>-	    nested_vmx_check_exit_msr_switch_controls(vcpu, vmcs12))
> >>+				vmx->nested.msrs.exit_ctls_high))
> >>+		return -EINVAL;
> >>+
> >Exit controls are not shadowed, are they?
> 
> No, they aren't.   However, I see that prepare_vmcs02_constant_state() which
> is called in the path of prepare_vmcs02_early_full() writes those Exit
> Control fields:
> 
>        vmcs_write32(VM_EXIT_MSR_STORE_COUNT, 0);
>         vmcs_write64(VM_EXIT_MSR_LOAD_ADDR,
> __pa(vmx->msr_autoload.host.val));
>         vmcs_write64(VM_ENTRY_MSR_LOAD_ADDR,
> __pa(vmx->msr_autoload.guest.val));

That's writing L0's values into vmcs02 when vmcs02 is first used.  L1's
MSR load lists are processed purely in software, e.g. nested_vmx_load_msr().
The vmcs12 entries are consumed by KVM on every nested transition to
emulate the load/store functionality, but the validity of the *controls*
only needs to be checked when vmcs12 is dirty.

> 
> 
> Should we add these fields to the shadow list then ?
> 
> >
> >Paolo