From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AH8x224GLhAv3vKY/qD3f2vnaGgamZz/RgEqFAP1Q5nUyyU4GeuEu04e3Wpabbx+yJ+Bh4AaQTxs ARC-Seal: i=1; a=rsa-sha256; t=1517275369; cv=none; d=google.com; s=arc-20160816; b=XVtd8gCYqmHbsSKeNt3wgkofjcxbxYsQK241t6OvHT4HT1mXXBzClF7uGsoI2TZQie TxC0ysS5dAYYqcKsn0DC0c04nXJkicQu/uHRw1SYpwjnfgjZciFb0EbZEGdFpO+0XdE+ CtUcOULSSGB3Zz62/cH9+wZujf4/5qyhQaPTo/n7jOUhi5gsGRgDsVINOKRxP/xk5wYa AyNqzT+d4WbFflMqXTQhRRR0XFAHnKwG4LCcERh7wswzPEJrUOyMpytzrEO0e6aFDTTh uH8F+WB6ZE+haJM6K3RUkJvLqCOaHMsj/58FiDNHg8reZfLzgAXQuOgaAwE4Yq0nsOWa TgHg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:arc-authentication-results; bh=KBUTwWcEKi70z8/2G4byljHy+a7LHteKAk8bgq6FMM8=; b=qUjNS5QV0AeTGPHBpzDtA1W/ka4HxvOPQ7sp0hEuisYJ8qZqK4yr2la3szIxpdLRwj 4Mhnot0BwgH8j+MiYPjHzF3HBijK3GwPVV4WSSKrQnVe+lmbmqWCaE3c31JqVsmEuJR/ xMP8ckcXTY8ry5eYX6a4Lb7h36jC7pOyQ4w84WE/kVYVd3om9HM3Pxbm60o4T+D8xMln tuAMhkZxAh8AiW48DSSj3mw+kSKo7SF/tw900fm+zJF0eNZ4peLFCn/2uklO043BErLJ WLyEf9461DS5V6kyDmjQbnVjY+YJCavGNyuPSVlRdOXAsc0SdzzAC4UhODdM3vEzDVtV DtBA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of ehabkost@redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=ehabkost@redhat.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Authentication-Results: mx.google.com; spf=pass (google.com: domain of ehabkost@redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=ehabkost@redhat.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Date: Mon, 29 Jan 2018 23:22:46 -0200 From: Eduardo Habkost To: Jim Mattson Cc: David Woodhouse , Arjan van de Ven , 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 , Radim =?utf-8?B?S3LEjW3DocWZ?= , Thomas Gleixner , Tim Chen , Tom Lendacky , kvm list , the arch/x86 maintainers , "Dr. David Alan Gilbert" Subject: Re: [RFC,05/10] x86/speculation: Add basic IBRS support infrastructure Message-ID: <20180130012246.GD21702@localhost.localdomain> 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> <20180129215025.GX25150@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Fnord: you can see the fnord User-Agent: Mutt/1.9.1 (2017-09-22) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1590140581449802182?= X-GMAIL-MSGID: =?utf-8?q?1590978538035706478?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On Mon, Jan 29, 2018 at 02:12:02PM -0800, Jim Mattson wrote: > On Mon, Jan 29, 2018 at 1:50 PM, Eduardo Habkost 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. If this is not practical, the hypervisor can simply choose to never make any of those promises to the guest OS. Never implementing any of those bits is also an option. But then guest OSes must be aware that the hypervisor can _not_ promise that f/m/s matches the host CPU, and can _not_ promise that the VM will never be migrated to Skylake CPUs. -- Eduardo