From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: ARC-Seal: i=1; a=rsa-sha256; t=1517261826; cv=none; d=google.com; s=arc-20160816; b=l6MsLB8/at06d9ol2nkzrdVwCc/Mm9a+BtP0Pfs5Txqe6nYCxDPfEy8j50V/rI9f03 84KmKlFZFjKOvL5AO0teGOGq+mnN2HYZWGY7Efv0T8Di6iU+QCZm7nZ0g5y6R7uH3Xsh ZQgi/Sjd4pRrcOlECXnbp6XHzjFaHTX8ijsSG09wW4cODT9TtJAupvzrKINa7uz3joPf FlVYvSr94b6eUpz+inc+v5f63rXigbABk0f6p1xbnEdMd7Bapk4aFfPn79CCxIn0Qymu qG14bboO2tf9HJ1NQ+De00itY2p3TpApCproRcP9gQAlaCKVfxjXn8342i9msrSRyd7x adcg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:dkim-signature:arc-authentication-results; bh=jQl1fiYscUjuo4a5cLeLQdOjm7X6DSJPnyMTbWfgNro=; b=hYRC0D36Sv6mH17xdAAbWbX0Hy4QC1j2Jnp6JmWwVnhLc0b0SjzAdtM7/hnik3Uzg2 siZ/ZhSVoCozneef1RFvQGLqr2c6aBGwA7RZc/dwE1kLIoiojVlLziYAmOHD6LIrHE6b flnsBJM3wjXRPFMgtDUXPP+TAb6ksx5E3ppsJKWPsRMBLj77gtM9Hj6EmTKprAcWjLFe 23LmM31GiBhoAXDF4yHaxe5r1XDcjAoc/fGYMC2hbuRQSYeGKtfIKnxD+Fb/n1gkdpUt 2zv4sthqelT6PHtglqvNcURt5mrKmQjeAvESJLe5uw4kkSOEiMseFlxWHGRXt3OpJBf6 gvfw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=qhERd8Yq; spf=pass (google.com: domain of jmattson@google.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=jmattson@google.com; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=qhERd8Yq; spf=pass (google.com: domain of jmattson@google.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=jmattson@google.com; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com X-Google-Smtp-Source: AH8x227RMVfNsyC4hz378VvDDehPZZZPHwOjM+9HiGJXuSgDUEZKDX+fruvXVXbKXftPSxXx9spcZxH9MOx/kDDPEWU= MIME-Version: 1.0 In-Reply-To: <1517259759.18619.38.camel@infradead.org> 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> From: Jim Mattson Date: Mon, 29 Jan 2018 13:37:05 -0800 Message-ID: Subject: Re: [RFC,05/10] x86/speculation: Add basic IBRS support infrastructure To: David Woodhouse Cc: Arjan van de Ven , Eduardo Habkost , KarimAllah Ahmed , LKML , 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 , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , Thomas Gleixner , Tim Chen , Tom Lendacky , kvm list , "the arch/x86 maintainers" , "Dr. David Alan Gilbert" Content-Type: text/plain; charset="UTF-8" X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1590140581449802182?= X-GMAIL-MSGID: =?utf-8?q?1590964336855588918?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: 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. In general, making these kinds of decisions based on F/M/S is probably unwise when running in a VM. On Mon, Jan 29, 2018 at 1:02 PM, David Woodhouse wrote: > > > On Mon, 2018-01-29 at 12:44 -0800, Arjan van de Ven wrote: >> On 1/29/2018 12:42 PM, Eduardo Habkost wrote: >> > >> > 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 question > > 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. > > If a guest doesn't have those, because it's running some future kernel > where they *are* implemented but not enabled because at *boot* time it > discovered it wasn't on Skylake, the question is what happens if that > guest is subsequently migrated to a Skylake-class machine. > > 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. > > 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.