Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Mon, 10 May 2021 16:43:50 +0000
From:   Sean Christopherson <seanjc@google.com>
To:     Reiji Watanabe <reijiw@google.com>
Cc:     Paolo Bonzini <pbonzini@redhat.com>,
        Vitaly Kuznetsov <vkuznets@redhat.com>,
        Wanpeng Li <wanpengli@tencent.com>,
        Jim Mattson <jmattson@google.com>,
        Joerg Roedel <joro@8bytes.org>, kvm@vger.kernel.org,
        linux-kernel@vger.kernel.org, Xiaoyao Li <xiaoyao.li@intel.com>
Subject: Re: [PATCH 09/15] KVM: VMX: Use flag to indicate "active" uret MSRs
 instead of sorting list
Message-ID: <YJlixiTcwFkrnxIL@google.com>
References: <20210504171734.1434054-1-seanjc@google.com>
 <20210504171734.1434054-10-seanjc@google.com>
 <CAAeT=FyKjHykGNcQc=toqvhCR281SWc6UqNihsjyU+vuo3z5Yg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAAeT=FyKjHykGNcQc=toqvhCR281SWc6UqNihsjyU+vuo3z5Yg@mail.gmail.com>
Precedence: bulk

On Fri, May 07, 2021, Reiji Watanabe wrote:
> > -static void vmx_setup_uret_msr(struct vcpu_vmx *vmx, unsigned int msr)
> > +static void vmx_setup_uret_msr(struct vcpu_vmx *vmx, unsigned int msr,
> > +                              bool load_into_hardware)
> >  {
> > -       struct vmx_uret_msr tmp;
> > -       int from, to;
> > +       struct vmx_uret_msr *uret_msr;
> >
> > -       from = __vmx_find_uret_msr(vmx, msr);
> > -       if (from < 0)
> > +       uret_msr = vmx_find_uret_msr(vmx, msr);
> > +       if (!uret_msr)
> >                 return;
> > -       to = vmx->nr_active_uret_msrs++;
> >
> > -       tmp = vmx->guest_uret_msrs[to];
> > -       vmx->guest_uret_msrs[to] = vmx->guest_uret_msrs[from];
> > -       vmx->guest_uret_msrs[from] = tmp;
> > +       uret_msr->load_into_hardware = load_into_hardware;
> >  }
> >
> >  /*
> > @@ -1785,30 +1781,36 @@ static void vmx_setup_uret_msr(struct vcpu_vmx *vmx, unsigned int msr)
> >   */
> >  static void setup_msrs(struct vcpu_vmx *vmx)
> >  {
> > -       vmx->guest_uret_msrs_loaded = false;
> > -       vmx->nr_active_uret_msrs = 0;
> >  #ifdef CONFIG_X86_64
> > +       bool load_syscall_msrs;
> > +
> >         /*
> >          * The SYSCALL MSRs are only needed on long mode guests, and only
> >          * when EFER.SCE is set.
> >          */
> > -       if (is_long_mode(&vmx->vcpu) && (vmx->vcpu.arch.efer & EFER_SCE)) {
> > -               vmx_setup_uret_msr(vmx, MSR_STAR);
> > -               vmx_setup_uret_msr(vmx, MSR_LSTAR);
> > -               vmx_setup_uret_msr(vmx, MSR_SYSCALL_MASK);
> > -       }
> > +       load_syscall_msrs = is_long_mode(&vmx->vcpu) &&
> > +                           (vmx->vcpu.arch.efer & EFER_SCE);
> > +
> > +       vmx_setup_uret_msr(vmx, MSR_STAR, load_syscall_msrs);
> > +       vmx_setup_uret_msr(vmx, MSR_LSTAR, load_syscall_msrs);
> > +       vmx_setup_uret_msr(vmx, MSR_SYSCALL_MASK, load_syscall_msrs);
> >  #endif
> > -       if (update_transition_efer(vmx))
> > -               vmx_setup_uret_msr(vmx, MSR_EFER);
> > +       vmx_setup_uret_msr(vmx, MSR_EFER, update_transition_efer(vmx));
> >
> > -       if (guest_cpuid_has(&vmx->vcpu, X86_FEATURE_RDTSCP)  ||
> > -           guest_cpuid_has(&vmx->vcpu, X86_FEATURE_RDPID))
> > -               vmx_setup_uret_msr(vmx, MSR_TSC_AUX);
> > +       vmx_setup_uret_msr(vmx, MSR_TSC_AUX,
> > +                          guest_cpuid_has(&vmx->vcpu, X86_FEATURE_RDTSCP) ||
> > +                          guest_cpuid_has(&vmx->vcpu, X86_FEATURE_RDPID));
> 
> Shouldn't vmx_setup_uret_msr(,MSR_TSC_AUX,) be called to update
> the new flag load_into_hardware for MSR_TSC_AUX when CPUID
> (X86_FEATURE_RDTSCP/X86_FEATURE_RDPID) of the vCPU is updated ?

Yes.  I have a patch in the massive vCPU RESET/INIT series to do exactly that.
I honestly can't remember if there was a dependency that "required" the fix to
be buried in the middle of that series.  I suspect not; I'm guessing I just
didn't think it was worth backporting to stable kernels and so didn't prioritize
hoisting the patch out of that mess.

https://lkml.kernel.org/r/20210424004645.3950558-34-seanjc@google.com