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

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Mon, Jun 04, 2018 at 06:15:09PM -0300, Eduardo Habkost wrote:
> 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).

The "" in the comment section makes sure to hide it. That is only
CPU features without the "" are exposed in /proc/cpuinfo

You got me worried there for a minute :-)
> 
> [1] https://patchwork.kernel.org/patch/10443689/
> 
> -- 
> Eduardo