Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Mon, 29 Jan 2018 23:22:46 -0200
From:   Eduardo Habkost <ehabkost@redhat.com>
To:     Jim Mattson <jmattson@google.com>
Cc:     David Woodhouse <dwmw2@infradead.org>,
        Arjan van de Ven <arjan@linux.intel.com>,
        KarimAllah Ahmed <karahmed@amazon.de>,
        LKML <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 =?utf-8?B?S3LEjW3DocWZ?= <rkrcmar@redhat.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Tim Chen <tim.c.chen@linux.intel.com>,
        Tom Lendacky <thomas.lendacky@amd.com>,
        kvm list <kvm@vger.kernel.org>,
        the arch/x86 maintainers <x86@kernel.org>,
        "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Subject: Re: [RFC,05/10] x86/speculation: Add basic IBRS support
 infrastructure
Message-ID: <20180130012246.GD21702@localhost.localdomain>
References: <1516476182-5153-6-git-send-email-karahmed@amazon.de>
 <20180129201404.GA1588@localhost.localdomain>
 <1517257022.18619.30.camel@infradead.org>
 <20180129204256.GV25150@localhost.localdomain>
 <31415b7f-9c76-c102-86cd-6bf4e23e3aee@linux.intel.com>
 <1517259759.18619.38.camel@infradead.org>
 <CALMp9eQ9o81TAsb9sBmD5F7EXMsi5WGKO7Q3Yce2xfqRirbUTA@mail.gmail.com>
 <20180129215025.GX25150@localhost.localdomain>
 <CALMp9eQXhWrnmewmifDVH-F3MFN45yoMqTeOXPKgL6Mu-iopfA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CALMp9eQXhWrnmewmifDVH-F3MFN45yoMqTeOXPKgL6Mu-iopfA@mail.gmail.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, Jan 29, 2018 at 02:12:02PM -0800, Jim Mattson wrote:
> On Mon, Jan 29, 2018 at 1:50 PM, Eduardo Habkost <ehabkost@redhat.com> wrote:
> > 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.
> 
> Giving customers this option promises the logistical nightmare of
> provisioning sufficient pre-Skylake-era machines in all pools until
> sufficient post-Skylake-era machines can be deployed to replace them.

If this is not practical, the hypervisor can simply choose to
never make any of those promises to the guest OS.

Never implementing any of those bits is also an option.  But then
guest OSes must be aware that the hypervisor can _not_ promise
that f/m/s matches the host CPU, and can _not_ promise that the
VM will never be migrated to Skylake CPUs.

-- 
Eduardo