From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jim Mattson <jmattson@google.com>
Subject: Re: [RFC,05/10] x86/speculation: Add basic IBRS support infrastructure
Date: Mon, 29 Jan 2018 14:12:02 -0800
Message-ID: <CALMp9eQXhWrnmewmifDVH-F3MFN45yoMqTeOXPKgL6Mu-iopfA@mail.gmail.com>
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>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
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@lin
To: Eduardo Habkost <ehabkost@redhat.com>
Return-path: <linux-kernel-owner@vger.kernel.org>
In-Reply-To: <20180129215025.GX25150@localhost.localdomain>
Sender: linux-kernel-owner@vger.kernel.org
List-Id: kvm.vger.kernel.org

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.

>> 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