| Message ID | 20210921000303.400537-8-seanjc@google.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | KVM: x86: Clean up RESET "emulation" | expand |
Sean Christopherson <seanjc@google.com> writes: > Don't zero out user return and nested MSRs during vCPU creation, and > instead rely on vcpu_vmx being zero-allocated. Explicitly zeroing MSRs > is not wrong, and is in fact necessary if KVM ever emulates vCPU RESET > outside of vCPU creation, but zeroing only a subset of MSRs is confusing. > > Poking directly into KVM's backing is also undesirable in that it doesn't > scale and is error prone. Ideally KVM would have a common RESET path for > all MSRs, e.g. by expanding kvm_set_msr(), which would obviate the need > for this out-of-bad code (to support standalone RESET). Just thinking out loud: we can probably enhance KVM_SET_MSRS making it possible for userspace VMM to set the default (as not every setting need to survive RESET). Conveniently enough, 'struct kvm_msr_entry' has 32 bits reserved and we can bite off one for 'default' flag. > > No functional change intended. > > Signed-off-by: Sean Christopherson <seanjc@google.com> > --- > arch/x86/kvm/vmx/vmx.c | 6 +----- > 1 file changed, 1 insertion(+), 5 deletions(-) > > diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c > index d44d07d5a02f..8d14066db3ea 100644 > --- a/arch/x86/kvm/vmx/vmx.c > +++ b/arch/x86/kvm/vmx/vmx.c > @@ -6819,10 +6819,8 @@ static int vmx_create_vcpu(struct kvm_vcpu *vcpu) > goto free_vpid; > } > > - for (i = 0; i < kvm_nr_uret_msrs; ++i) { > - vmx->guest_uret_msrs[i].data = 0; > + for (i = 0; i < kvm_nr_uret_msrs; ++i) > vmx->guest_uret_msrs[i].mask = -1ull; > - } > if (boot_cpu_has(X86_FEATURE_RTM)) { > /* > * TSX_CTRL_CPUID_CLEAR is handled in the CPUID interception. > @@ -6879,8 +6877,6 @@ static int vmx_create_vcpu(struct kvm_vcpu *vcpu) > > if (nested) > memcpy(&vmx->nested.msrs, &vmcs_config.nested, sizeof(vmx->nested.msrs)); > - else > - memset(&vmx->nested.msrs, 0, sizeof(vmx->nested.msrs)); > > vcpu_setup_sgx_lepubkeyhash(vcpu); Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com>
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c index d44d07d5a02f..8d14066db3ea 100644 --- a/arch/x86/kvm/vmx/vmx.c +++ b/arch/x86/kvm/vmx/vmx.c @@ -6819,10 +6819,8 @@ static int vmx_create_vcpu(struct kvm_vcpu *vcpu) goto free_vpid; } - for (i = 0; i < kvm_nr_uret_msrs; ++i) { - vmx->guest_uret_msrs[i].data = 0; + for (i = 0; i < kvm_nr_uret_msrs; ++i) vmx->guest_uret_msrs[i].mask = -1ull; - } if (boot_cpu_has(X86_FEATURE_RTM)) { /* * TSX_CTRL_CPUID_CLEAR is handled in the CPUID interception. @@ -6879,8 +6877,6 @@ static int vmx_create_vcpu(struct kvm_vcpu *vcpu) if (nested) memcpy(&vmx->nested.msrs, &vmcs_config.nested, sizeof(vmx->nested.msrs)); - else - memset(&vmx->nested.msrs, 0, sizeof(vmx->nested.msrs)); vcpu_setup_sgx_lepubkeyhash(vcpu);
Don't zero out user return and nested MSRs during vCPU creation, and instead rely on vcpu_vmx being zero-allocated. Explicitly zeroing MSRs is not wrong, and is in fact necessary if KVM ever emulates vCPU RESET outside of vCPU creation, but zeroing only a subset of MSRs is confusing. Poking directly into KVM's backing is also undesirable in that it doesn't scale and is error prone. Ideally KVM would have a common RESET path for all MSRs, e.g. by expanding kvm_set_msr(), which would obviate the need for this out-of-bad code (to support standalone RESET). No functional change intended. Signed-off-by: Sean Christopherson <seanjc@google.com> --- arch/x86/kvm/vmx/vmx.c | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-)