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 15:51:58 -0800
From:   Fred Jacobs <fjacobs@vmware.com>
To:     David Dunn <ddunn@vmware.com>
Cc:     Eduardo Habkost <ehabkost@redhat.com>,
        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>,
        Jim Mattson <jmattson@google.com>,
        David Woodhouse <dwmw2@infradead.org>
Subject: Re: [RFC,05/10] x86/speculation: Add basic IBRS support
 infrastructure
Message-ID: <20180129235158.GA145231@vmware.com>
References: <7EB9643C-D2DD-477A-90DE-05DC653D2D4B@vmware.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <7EB9643C-D2DD-477A-90DE-05DC653D2D4B@vmware.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Received-SPF: None (protection.outlook.com: vmware.com does not designate
 permitted sender hosts)
SpamDiagnosticOutput: 1:22
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jan 2018 23:52:28.3231 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: f4b623be-0f32-417d-2817-08d567735e87
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB1776
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

(Apologies as I was brought into this thread late, but I believe I have
context).

Could a new "feature" be enumerated on Skylake and beyond which specifies that
a particular problem exists which requires different mitigation than on
previous processors?  Perhaps a CPUID bit enumerating this feature (along side
IBRS, IBPB and STIBP) could be exposed on only the newer CPUs.  System software
could then query this to know what form of mitigation is necessary.

This could be over-reported in virtualized environments (e.g. a Nehalem CPU
could be represented as needing the Skylake mitigation), such that sometimes
the heavier Skylake+ mitigation would be applied on older CPUs.  This is
correct, just slower.

I'm just suggesting this rather than keying on Family/Model/Stepping to avoid
breaking virtual machine migration, et cetera.

Thanks,

Fred, sticking his neck out.

On Jan 29  2:29PM, 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.
> 
> 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.
> 
> My apologies for posting onto the mailing list out of the blue.  Someone asked my opinion on this suggestion.  I'm definitely interested in figuring out whether Linux can fully mitigate the SkyLake RSB problem in virtual environments, but it's not clear how best to achieve that.
> 
> Thanks,
> 
> David Dunn
>