Re: [PATCH 1/2] i386: define the AMD 'amd-ssbd' CPUID feature bit

[Eduardo Habkost <ehabkost@redhat.com>]

On Mon, Jun 04, 2018 at 04:22:05PM -0400, Konrad Rzeszutek Wilk wrote:
> On Mon, Jun 04, 2018 at 05:07:01PM -0300, Eduardo Habkost wrote:
> > On Fri, Jun 01, 2018 at 11:38:08AM -0400, Konrad Rzeszutek Wilk wrote:
> > > AMD future CPUs expose _two_ ways to utilize the Intel equivalant
> > > of the Speculative Store Bypass Disable. The first is via
> > > the virtualized VIRT_SPEC CTRL MSR (0xC001_011f) and the second
> > > is via the SPEC_CTRL MSR (0x48). The document titled:
> > > 124441_AMD64_SpeculativeStoreBypassDisable_Whitepaper_final.pdf
> > > 
> > > gives priority of SPEC CTRL MSR over the VIRT SPEC CTRL MSR.
> > > 
> > > A copy of this document is available at
> > >       https://bugzilla.kernel.org/show_bug.cgi?id=199889
> > > 
> > > Anyhow, this means that on future AMD CPUs there will be  _two_ ways to
> > > deal with SSBD.
> > 
> > Does anybody know if there are AMD CPUs where virt-ssbd won't
> > work and would require amd-ssbd to mitigate vulnerabilities?
> > 
> > Also, do we have kernel arch/x86/kvm/cpuid.c patches, already?
> 
> Not yet. They are being discussed right now. I figured I would send
> these patches out as a 'Hey, coming at you!', but failed to change
> the title to be 'RFC'.

OK.  I was queueing them on x86-next, but I'm going drop them by
now.


> 
> > I prefer to add new CPUID flag names only after the flag name is
> > already agreed upon on the kernel side.
> 
> Of course. I will respin once that discussion has calmed down.

Thanks!

BTW, it looks like the patch on LKML[1] will make bit 26 appear
on /proc/cpuinfo as "amd_ssb_no", is that correct?  If that's the
case, I'd prefer to make the QEMU flag to match the name used by
Linux, and be called "amd-ssb-no" (which sounds weird to me, but
at least it will be consistent with /proc/cpuinfo).

[1] https://patchwork.kernel.org/patch/10443689/

-- 
Eduardo