Received: by 10.223.176.5 with SMTP id f5csp3406679wra; Mon, 29 Jan 2018 12:43:38 -0800 (PST) X-Google-Smtp-Source: AH8x227W0ktTa9TucGXxdR9d5a/oJyJPBG2wSjPwWQmogKmEcFlzdAxS2CyjV1wU/TgdUn6uEiGE X-Received: by 10.98.212.26 with SMTP id a26mr28076103pfh.38.1517258618282; Mon, 29 Jan 2018 12:43:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517258618; cv=none; d=google.com; s=arc-20160816; b=WYS+eII7y3GXLSn6CGhBvQVSdXicCrZkNiFQmBUYa16junU9VeX8xrAyjwWekG3R1i m+CAD4H1KSdgiUd3aKCzT5B4FwsH7rmt90mt+d7uTbxKjipAIXvFB12mXF1z2n7VdQMf Ky1df6NYBsHHM4Tdg6dLZ9p3efb5cM2twyXvsADkOv0NCAF9dS82z/cbUEVPsClHQBHo SSJPhJzBPZhqF78JOXxAChmYhbqpqHLFb/f7qlMZQOxCLWJK4sDe2wcxUIWwamR2NOtm 2J8CsMARVRwOzptHnlYPkz2a/snxpVabQYSIzO6wgm3ecRledPENgKXlyrPzhU7WxSh6 NhwA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date :arc-authentication-results; bh=chkV2+9j7BFeffIouz/9oWwnBRGacAVfbQKi+w0NDFs=; b=oX7PCpY0RzfNRFA4plqaH0A4ZA3pP9BFn1qAR6exec9R97X7r0TUUPdPJuV+i2wmLA TWWwkpteosq5cdwMFYuisAqQ6NQwx298D/IU3ubb80GMFS86WaXNL0BVqAv3uV1pI9OI lqhgqHmDYqOOq/TpuXobKY7Um1TRSypil3CwN+X4G4F38jS1QQI7Rolhl9b8EK+sa1/Y 5SvmMR88r/xzwI14UQwuKu3M6Y7ogG9Ks2dTUTG4h6hcJRZ6hXWCBQmJGRBJR0xP/KpN LAoxn6zooRkiNef1Lgq6qa00PTsYNDeZJYPcNJMd23pWVKpS25QlM4WSsdJKgKvZnZHo l68Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z8si73380pgc.83.2018.01.29.12.43.23; Mon, 29 Jan 2018 12:43:38 -0800 (PST) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754027AbeA2UnC (ORCPT + 99 others); Mon, 29 Jan 2018 15:43:02 -0500 Received: from mx1.redhat.com ([209.132.183.28]:39668 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753547AbeA2Um7 (ORCPT ); Mon, 29 Jan 2018 15:42:59 -0500 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id EDA8A4900E; Mon, 29 Jan 2018 20:42:58 +0000 (UTC) Received: from localhost (ovpn-116-57.gru2.redhat.com [10.97.116.57]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3DCB518811; Mon, 29 Jan 2018 20:42:58 +0000 (UTC) Date: Mon, 29 Jan 2018 18:42:56 -0200 From: Eduardo Habkost To: David Woodhouse Cc: KarimAllah Ahmed , linux-kernel@vger.kernel.org, Andi Kleen , Andrea Arcangeli , Andy Lutomirski , Arjan van de Ven , Ashok Raj , Asit Mallick , Borislav Petkov , Dan Williams , Dave Hansen , Greg Kroah-Hartman , "H . Peter Anvin" , Ingo Molnar , Janakarajan Natarajan , Joerg Roedel , Jun Nakajima , Laura Abbott , Linus Torvalds , Masami Hiramatsu , Paolo Bonzini , Peter Zijlstra , Radim =?utf-8?B?S3LEjW3DocWZ?= , Thomas Gleixner , Tim Chen , Tom Lendacky , kvm@vger.kernel.org, x86@kernel.org, "Dr. David Alan Gilbert" Subject: Re: [RFC,05/10] x86/speculation: Add basic IBRS support infrastructure Message-ID: <20180129204256.GV25150@localhost.localdomain> References: <1516476182-5153-6-git-send-email-karahmed@amazon.de> <20180129201404.GA1588@localhost.localdomain> <1517257022.18619.30.camel@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1517257022.18619.30.camel@infradead.org> X-Fnord: you can see the fnord User-Agent: Mutt/1.9.1 (2017-09-22) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Mon, 29 Jan 2018 20:42:59 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 29, 2018 at 08:17:02PM +0000, David Woodhouse wrote: > On Mon, 2018-01-29 at 18:14 -0200, Eduardo Habkost wrote: > > > > Sorry for being confused here, as probably the answer is buried > > on a LKML thread somewhere.? The comment explains what the code > > does, but not why.? Why exactly IBRS is preferred on Skylake? > > > > I'm asking this because I would like to understand the risks > > involved when running under a hypervisor exposing CPUID data that > > don't match the host CPU.? e.g.: what happens if a VM is migrated > > from a Broadwell host to a Skylake host? > > https://lkml.org/lkml/2018/1/22/598?should cover most of that, I think. Thanks, it does answer some of my questions. So, it sounds like live-migration of a VM from a non-Skylake to a Skylake host will make the guest unsafe, unless the guest was explicitly configured to use IBRS. In a perfect world, Linux would never look at CPU family/model/stepping/microcode if running under a hypervisor, to take any decision. If Linux knows it's running under a hypervisor, it would be safer to assume retpolines aren't enough, unless the hypervisor is telling us otherwise. The question is how the hypervisor could tell that to the guest. If Intel doesn't give us a CPUID bit that can be used to tell that retpolines are enough, maybe we should use a hypervisor CPUID bit for that? -- Eduardo