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
