Flushing the VMCS cache on L2->userspace exit solves (2), but it means that L2->userspace exit is not transparent to the guest. Is this better than (3)? There is some redundancy in the VMCS cache state currently saved by GET_NESTED_STATE and the VCPU state saved by GET_SREGS and others, but it does simplify the vmcs02 initialization. (As an aside, this might be a lot easier if we eliminated the vmcs02 entirely, as I've suggested in the past.) To be honest, I'm not sure what it is that you are trying to optimize for. Is your concern the extra 4K of VCPU state? I would argue that the VMCS cache is part of the physical CPU state (though on a physical CPU, not every field is cached), and that it therefore makes sense to include the VMCS cache as part of the VCPU state, apart from guest physical memory. On Wed, Feb 15, 2017 at 8:14 AM, Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > > > On 15/02/2017 17:06, Jim Mattson wrote: >> The VMCS cache can be safely flushed to guest memory at any time. >> However, I think your proposal has some unfortunate consequences: >> >> 1. If KVM_SET_NESTED_STATE is asynchronous, then any subsequent set >> operations (e.g. KVM_SET_SREGS) may be overridden on the next KVM_RUN. >> 2. Guest memory (at least the cached VMCS page(s)) has to be saved >> after KVM_GET_NESTED_STATE. >> 3. KVM_GET_NESTED_STATE is not transparent to the guest. > > I can't choose which is the worst of the three. :) > > A better one perhaps is to flush the VMCS cache on L2->userspace exit, > since that should be pretty rare (suggested by David). I think that > would help at least with (2) and (3). > > As to (1), after KVM_SET_NESTED_STATE sets the in-guest-mode flag you > don't really need to reload all of the vmcs12 into vmcs02. Only the > host state needs to be reloaded, while the guest state is set with > KVM_SET_SREGS and others. > > Paolo
