Re: [RFC,05/10] x86/speculation: Add basic IBRS support infrastructure

From: Eduardo Habkost <ehabkost@redhat.com>
To: David Dunn <ddunn@vmware.com>
Cc: "Arjan van de Ven" <arjan@linux.intel.com>,
	"KarimAllah Ahmed" <karahmed@amazon.de>,
	"Wilson, Matt" <msw@amazon.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Andi Kleen" <ak@linux.intel.com>,
	"Andrea Arcangeli" <aarcange@redhat.com>,
	"Andy Lutomirski" <luto@kernel.org>,
	"Ashok Raj" <ashok.raj@intel.com>,
	"Asit Mallick" <asit.k.mallick@intel.com>,
	"Borislav Petkov" <bp@suse.de>,
	"Dan Williams" <dan.j.williams@intel.com>,
	"Dave Hansen" <dave.hansen@intel.com>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"H . Peter Anvin" <hpa@zytor.com>,
	"Ingo Molnar" <mingo@redhat.com>,
	"Janakarajan Natarajan" <Janakarajan.Natarajan@amd.com>,
	"Joerg Roedel" <joro@8bytes.org>,
	"Jun Nakajima" <jun.nakajima@intel.com>,
	"Laura Abbott" <labbott@redhat.com>,
	"Linus Torvalds" <torvalds@linux-foundation.org>,
	"Masami Hiramatsu" <mhiramat@kernel.org>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Radim Krčmář" <rkrcmar@redhat.com>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Tim Chen" <tim.c.chen@linux.intel.com>,
	"Tom Lendacky" <thomas.lendacky@amd.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"x86@kernel.org" <x86@kernel.org>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	"Fred Jacobs" <fjacobs@vmware.com>,
	"Jim Mattson" <jmattson@google.com>,
	"David Woodhouse" <dwmw2@infradead.org>
Subject: Re: [RFC,05/10] x86/speculation: Add basic IBRS support infrastructure
Date: Mon, 29 Jan 2018 23:08:32 -0200	[thread overview]
Message-ID: <20180130010832.GA21702@localhost.localdomain> (raw)
In-Reply-To: <7EB9643C-D2DD-477A-90DE-05DC653D2D4B@vmware.com>

On Mon, Jan 29, 2018 at 10:29:28PM +0000, David Dunn wrote:
> On Mon, 2018-01-29 at 13:45:07 -0800, Eduardo Habkost wrote:
> 
> > Maybe a generic "family/model/stepping/microcode really matches
> > the CPU you are running on" bit would be useful.  The bit could
> > be enabled only on host-passthrough (aka "-cpu host") mode.
> > 
> > If we really want to be able to migrate to host with different
> > CPU models (except Skylake), we could add a more specific "we
> > promise the host CPU is never going to be Skylake" bit.
> > 
> > Now, if the hypervisor is not providing any of those bits, I
> > would advise against trusting family/model/stepping/microcode
> > under a hypervisor.  Using a pre-defined CPU model (that doesn't
> > necessarily match the host) is very common when using KVM VM
> > management stacks.
> > 
> 
> Eduardo,
> 
> I don't see how this is possible in a modern virtualization
> environment.
>  
> Under VMware, a VM will be migrated to SkyLake if one is in the
> cluster and supports the features exposed to the VM.  This can
> occur for suspend/resume as well.
> 
> The migration pool isn't a constant.  Hosts can be added to a
> cluster and VMs can be instructed to move across clusters.  So
> there doesn't need to be a SkyLake around when the VM powers on
> in order for it to eventually end up on a SkyLake.

If this is the case for your deployment, this means the guest
must never assume it won't run on a Skylake host (even if f/m/s
is not Skylake), doesn't it?  Then the hypervisor won't set the
"we promise the host CPU is never going to be Skylake" bit.

> 
> Even if we expose bit to indicate that FMS matches the
> underlying host, when does the guest know to query that?  The
> VM can be moved at any point in time, including after the guest
> asks if FMS matches host.

If the VM can be moved at any point of time to a different model
of host CPU, this means you won't tell the guest it can trust
f/m/s because it doesn't represent the underlying host.  You
won't set the "f/m/s/m really matches the host CPU" bit.

On both scenarios you describe above, it sounds like Linux must
assume it could migrated to a Skylake host at any moment.  This
is exactly why I'm proposing those extra bits.

-- 
Eduardo