[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230414221017.i4nfrcxrbxlznrxk@desk>
Date: Fri, 14 Apr 2023 15:10:17 -0700
From: Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>
To: Binbin Wu <binbin.wu@...ux.intel.com>
Cc: Chao Gao <chao.gao@...el.com>, kvm@...r.kernel.org,
Jiaan Lu <jiaan.lu@...el.com>,
Alexandre Chartre <alexandre.chartre@...cle.com>,
Arnaldo Carvalho de Melo <acme@...hat.com>,
Babu Moger <babu.moger@....com>,
Borislav Petkov <bp@...en8.de>, Borislav Petkov <bp@...e.de>,
Daniel Sneddon <daniel.sneddon@...ux.intel.com>,
Dave Hansen <dave.hansen@...ux.intel.com>,
David Matlack <dmatlack@...gle.com>,
"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...hat.com>,
Josh Poimboeuf <jpoimboe@...nel.org>,
Kim Phillips <kim.phillips@....com>,
Len Brown <len.brown@...el.com>, linux-kernel@...r.kernel.org,
linux-kselftest@...r.kernel.org,
Nikunj A Dadhania <nikunj@....com>,
Paolo Bonzini <pbonzini@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
Sandipan Das <sandipan.das@....com>,
Sean Christopherson <seanjc@...gle.com>,
Shuah Khan <shuah@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Vitaly Kuznetsov <vkuznets@...hat.com>, x86@...nel.org,
Zhang Chen <chen.zhang@...el.com>
Subject: Re: [RFC PATCH v2 00/11] Intel IA32_SPEC_CTRL Virtualization
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."
Powered by blists - more mailing lists