Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 14 Apr 2023 15:10:17 -0700
From:   Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
To:     Binbin Wu <binbin.wu@linux.intel.com>
Cc:     Chao Gao <chao.gao@intel.com>, kvm@vger.kernel.org,
        Jiaan Lu <jiaan.lu@intel.com>,
        Alexandre Chartre <alexandre.chartre@oracle.com>,
        Arnaldo Carvalho de Melo <acme@redhat.com>,
        Babu Moger <babu.moger@amd.com>,
        Borislav Petkov <bp@alien8.de>, Borislav Petkov <bp@suse.de>,
        Daniel Sneddon <daniel.sneddon@linux.intel.com>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        David Matlack <dmatlack@google.com>,
        "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
        Josh Poimboeuf <jpoimboe@kernel.org>,
        Kim Phillips <kim.phillips@amd.com>,
        Len Brown <len.brown@intel.com>, linux-kernel@vger.kernel.org,
        linux-kselftest@vger.kernel.org,
        Nikunj A Dadhania <nikunj@amd.com>,
        Paolo Bonzini <pbonzini@redhat.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Sandipan Das <sandipan.das@amd.com>,
        Sean Christopherson <seanjc@google.com>,
        Shuah Khan <shuah@kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Vitaly Kuznetsov <vkuznets@redhat.com>, x86@kernel.org,
        Zhang Chen <chen.zhang@intel.com>
Subject: Re: [RFC PATCH v2 00/11] Intel IA32_SPEC_CTRL Virtualization
Message-ID: <20230414221017.i4nfrcxrbxlznrxk@desk>
References: <20230414062545.270178-1-chao.gao@intel.com>
 <e956f4b9-34a1-de7b-2157-0101b586ab46@linux.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <e956f4b9-34a1-de7b-2157-0101b586ab46@linux.intel.com>
Precedence: bulk

On Fri, Apr 14, 2023 at 05:51:43PM +0800, Binbin Wu wrote:
> 
> On 4/14/2023 2:25 PM, Chao Gao wrote:
> > Changes since RFC v1:
> >   * add two kselftests (patch 10-11)
> >   * set virtual MSRs also on APs [Pawan]
> >   * enable "virtualize IA32_SPEC_CTRL" for L2 to prevent L2 from changing
> >     some bits of IA32_SPEC_CTRL (patch 4)
> >   * other misc cleanup and cosmetic changes
> > 
> > RFC v1: https://lore.kernel.org/lkml/20221210160046.2608762-1-chen.zhang@intel.com/
> > 
> > 
> > This series introduces "virtualize IA32_SPEC_CTRL" support. Here are
> > introduction and use cases of this new feature.
> > 
> > ### Virtualize IA32_SPEC_CTRL
> > 
> > "Virtualize IA32_SPEC_CTRL" [1] is a new VMX feature on Intel CPUs. This feature
> > allows VMM to lock some bits of IA32_SPEC_CTRL MSR even when the MSR is
> > pass-thru'd to a guest.
> > 
> > 
> > ### Use cases of "virtualize IA32_SPEC_CTRL" [2]
> > 
> > Software mitigations like Retpoline and software BHB-clearing sequence depend on
> > CPU microarchitectures. And guest cannot know exactly the underlying
> > microarchitecture. When a guest is migrated between processors of different
> > microarchitectures, software mitigations which work perfectly on previous
> > microachitecture may be not effective on the new one. To fix the problem, some
> > hardware mitigations should be used in conjunction with software mitigations.
> 
> So even the hardware mitigations are enabled, the software mitigations are
> still needed, right?

Retpoline mitigation is not fully effective when RET can take prediction
from an alternate predictor. Newer hardware provides a way to disable
this behavior (using RRSBA_DIS_S bit in MSR SPEC_CTRL).

eIBRS is the preferred way to mitigate BTI, but for some reason when a
guest has deployed retpoline, VMM can make it more effective by
deploying the relevant hardware control. That is why the above text
says:

  "... hardware mitigations should be used in conjunction with software
  mitigations."