From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AH8x227RsPhU0z1qG+julphz39gLanRggncCZo3LFFgmaJlemxsBbww/2UUDTQyKqU0pZ1iv66wi ARC-Seal: i=1; a=rsa-sha256; t=1517263849; cv=none; d=google.com; s=arc-20160816; b=XFRahEVrlPDkkPhBWz+o3vWZnlOL1LvUfvx5+GGyYvJZ3pcppQb6virkJVarr23mWi /tSq9D4oZkZeXKkgtF77vMDfgb6IhJsNQBfgNOxG54KYHcmsQyjZqxvxzIs5hRPmVLkn Y2KCtGVTgh97PiGpgjcwViTTSFxVCSlFZ6+V6oBndazpVXtw0Jw57JjVxhaf/Rppb3z+ tE6a4jkktktiLyfnNeJ0Ei9VyXHPcoAmp10dTgdEK00yj7Xtf4HnlZyyjKAmv8iuYnJI F+OBqZ0QgA3U7auSCICWmmt8H51nezoYi+2RhOJVM5fvNMeqNWW1cAo++Gb3hqWPm9sX nrzQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=Sun6m4jzn5lNQgpq8bLkbYBHzHrH2U5zhFTHVpYXdvk=; b=vfjTaAyOpWftEqBtSyndlbbrn4HKyiFaYlqMPNDmTZk4o1YHjNpNoC/P/VjaohDfb2 HztzReZX+B8WgCMCBwC6B1+6ut10muEmiSy6cY56kmqH2p9cZpY/J8pZUswQkIEDDHqd AL2lqeElqs3C2sHlMsLtaHt3/5LYH7fNIDU6g5EOXl7gI8lTbcHrjXPcyvWF/KppB8HE tNFNtd7KthtkFlVYMVHPS1hYCLWYu9/BG6noBr3t6WlLhg4g3j9BmLUrq0Qks3s4JyE0 5xOnf41J3ENMX1wkxaTBbHt2dEhjoPw9/M+MZJJ91bJmeQQrpyImjI6hJPMedE56g5z4 7rWA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=eK+J3p3X; spf=pass (google.com: domain of konrad.wilk@oracle.com designates 141.146.126.78 as permitted sender) smtp.mailfrom=konrad.wilk@oracle.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Authentication-Results: mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=eK+J3p3X; spf=pass (google.com: domain of konrad.wilk@oracle.com designates 141.146.126.78 as permitted sender) smtp.mailfrom=konrad.wilk@oracle.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Date: Mon, 29 Jan 2018 17:10:11 -0500 From: Konrad Rzeszutek Wilk To: Eduardo Habkost Cc: David Woodhouse , Arjan van de Ven , KarimAllah Ahmed , linux-kernel@vger.kernel.org, Andi Kleen , Andrea Arcangeli , Andy Lutomirski , 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: <20180129221011.GW22045@char.us.oracle.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> <20180129214421.GW25150@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20180129214421.GW25150@localhost.localdomain> User-Agent: Mutt/1.8.3 (2017-05-23) Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8789 signatures=668655 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=735 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801290282 X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1590140581449802182?= X-GMAIL-MSGID: =?utf-8?q?1590966458130566258?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On Mon, Jan 29, 2018 at 07:44:21PM -0200, Eduardo Habkost wrote: > On Mon, Jan 29, 2018 at 09:02:39PM +0000, David Woodhouse wrote: > >=20 > >=20 > > On Mon, 2018-01-29 at 12:44 -0800, Arjan van de Ven wrote: > > > On 1/29/2018 12:42 PM, Eduardo Habkost wrote: > > > >=20 > > > > 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? > > > > > > the objective is to have retpoline be safe everywhere and never use= IBRS > > > (Linus was also pretty clear about that) so I'm confused by your qu= estion > >=20 > > The question is about all the additional RSB-frobbing and call depth > > counting and other bits that don't really even exist for Skylake yet = in > > a coherent form. > >=20 > > If a guest doesn't have those, because it's running some future kerne= l > > where they *are* implemented but not enabled because at *boot* time i= t > > discovered it wasn't on Skylake, the question is what happens if that > > guest is subsequently migrated to a Skylake-class machine. > >=20 > > To which the answer is obviously "oops, sucks to be you". So yes, > > *maybe* we want a way to advertise "you might be migrated to Skylake" > > if you're booted on a pre-SKL box in a migration pool where such is > > possible.=A0 > >=20 > > That question is a reasonable one, and the answer possibly the same, > > regardless of whether the plan for Skylake is to use IBRS, or all the > > hypothetical other extra stuff. >=20 > 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. >=20 > 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. >=20 > 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 The migration code could be 'tickled' (when arrived at the destination) to recheck the CPUID and do the alternative logic to turn the proper bits on. And this tickling could be as simple as an ACPI DSDT/AML code specific to KVM PnP devices (say the CPUs?) to tell the guest to resample its environment? > necessarily match the host) is very common when using KVM VM > management stacks. >=20 > --=20 > Eduardo