[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180130010832.GA21702@localhost.localdomain>
Date: Mon, 29 Jan 2018 23:08:32 -0200
From: Eduardo Habkost <ehabkost@...hat.com>
To: David Dunn <ddunn@...are.com>
Cc: Arjan van de Ven <arjan@...ux.intel.com>,
KarimAllah Ahmed <karahmed@...zon.de>,
"Wilson, Matt" <msw@...zon.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Andi Kleen <ak@...ux.intel.com>,
Andrea Arcangeli <aarcange@...hat.com>,
Andy Lutomirski <luto@...nel.org>,
Ashok Raj <ashok.raj@...el.com>,
Asit Mallick <asit.k.mallick@...el.com>,
Borislav Petkov <bp@...e.de>,
Dan Williams <dan.j.williams@...el.com>,
Dave Hansen <dave.hansen@...el.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"H . Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...hat.com>,
Janakarajan Natarajan <Janakarajan.Natarajan@....com>,
Joerg Roedel <joro@...tes.org>,
Jun Nakajima <jun.nakajima@...el.com>,
Laura Abbott <labbott@...hat.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Masami Hiramatsu <mhiramat@...nel.org>,
Paolo Bonzini <pbonzini@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
Radim Krčmář <rkrcmar@...hat.com>,
Thomas Gleixner <tglx@...utronix.de>,
Tim Chen <tim.c.chen@...ux.intel.com>,
Tom Lendacky <thomas.lendacky@....com>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"x86@...nel.org" <x86@...nel.org>,
"Dr. David Alan Gilbert" <dgilbert@...hat.com>,
Fred Jacobs <fjacobs@...are.com>,
Jim Mattson <jmattson@...gle.com>,
David Woodhouse <dwmw2@...radead.org>
Subject: Re: [RFC,05/10] x86/speculation: Add basic IBRS support
infrastructure
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
Powered by blists - more mailing lists