On Thu, Sep 20, 2018 at 03:12:00PM -0700, Jim Mattson wrote: > On Thu, Sep 20, 2018 at 3:07 PM, Sean Christopherson > <sean.j.christopherson@xxxxxxxxx> wrote: > > > vm_exit_controls_shadow, which is written by vm_exit_controls_init(), > > is a shadow of the VM_EXIT_CONTROLS VMCS field. The shadow is used to > > elide VMREADs and VMWRITEs to VM_EXIT_CONTROLS, i.e. we don't need to > > VMREAD the field when toggling a bit and we can skip VMWRITE if the > > desired value matches the shadow (and therefore matches the VMCS). > > vm_exit_controls_shadow needs to be kept in sync with the VMCS field > > at all times, otherwise we might incorrectly skip a VMWRITE, e.g. if > > VM_EXIT_LOAD_IA32_EFER bit is set in the shadow but not the actual > > VMCS field. When we switch to vmcs02 we need to re-initialize the > > shadow because the shadow is per-VCPU, not per-VMCS. > > Perhaps the shadow should be per-VMCS? I don't think a per-VMCS shadow is justifiable with the current code base. There's effectively zero overhead when switching to vmcs02 since we unconditionally write the VMCS field during prepare_vmcs02(). When switching back to vmcs01 the overhead is a single VMREAD to reset the shadow, which peanuts compared to the overall cost of nested VMEnter/VMExit. That being said, at some point I do want to experiment with per-VMCS shadows. The pie in the sky goal would be to get to the point where a basic nested transition doesn't VMWRITE any vmcs02 control fields so that we can take advantage of hardware's dirty field optimizations.
