[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180129215025.GX25150@localhost.localdomain>
Date: Mon, 29 Jan 2018 19:50:25 -0200
From: Eduardo Habkost <ehabkost@...hat.com>
To: Jim Mattson <jmattson@...gle.com>
Cc: David Woodhouse <dwmw2@...radead.org>,
Arjan van de Ven <arjan@...ux.intel.com>,
KarimAllah Ahmed <karahmed@...zon.de>,
LKML <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 list <kvm@...r.kernel.org>,
the arch/x86 maintainers <x86@...nel.org>,
"Dr. David Alan Gilbert" <dgilbert@...hat.com>
Subject: Re: [RFC,05/10] x86/speculation: Add basic IBRS support
infrastructure
On Mon, Jan 29, 2018 at 01:37:05PM -0800, Jim Mattson wrote:
> For GCE, "you might be migrated to Skylake" is pretty much a
> certainty. Even if you're in a zone that doesn't currently have
> Skylake machines, chances are pretty good that it will have Skylake
> machines some day in the not-too-distant future.
This kind of scenario is why I suggest a "we promise you're not
going to be migrated to Skylake" bit instead a "you may be
migrated to Skylake" bit. The hypervisor could prevent migration
to Skylake hosts if management software chose to enable this bit,
and guests would choose the safest option (i.e. assume the worst)
if running on older hypervisors that don't set the bit.
>
> In general, making these kinds of decisions based on F/M/S is probably
> unwise when running in a VM.
Certainly. That's why I suggest not trusting f/m/s unless the
hypervisor is explicitly saying it's accurate.
--
Eduardo
Powered by blists - more mailing lists