On Tue, May 25, 2021, Paolo Bonzini wrote: > On 25/05/21 18:34, Sean Christopherson wrote: > > > I actually like the idea of storing the expected value in kvm_vcpu and the > > > current value in loaded_vmcs. We might use it for other things such as > > > reload_vmcs01_apic_access_page perhaps. > > I'm not necessarily opposed to aggressively shadowing the VMCS, but if we go > > that route then it should be a standalone series that implements a framework > > that can be easily extended to arbitrary fields. Adding fields to loaded_vmcs > > one at a time will be tedious and error prone. E.g. what makes TSC_MULTIPLIER > > more special than TSC_OFFSET, GUEST_IA32_PAT, GUEST_IA32_DEBUGCTL, GUEST_BNDCFGS, > > and other number of fields that are likely to persist for a given vmcs02? > > That it can be changed via ioctls in a way that affects both vmcs01 and vmcs02. That holds true for any MSR that is conditionally loaded/cleared on enter/exit, e.g. userspace can stuff MSR_IA32_CR_PAT while L2 is active, and that can affect L1 if L1 is running without VM_EXIT_LOAD_IA32_PAT. I'm not saying that the above is likely, but neither is changing the TSC scaling ratio while L2 is active (I assume it occurs on migration, but in the grand scheme that's not a common operation).
