From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andi Kleen Subject: Re: [RFC,05/10] x86/speculation: Add basic IBRS support infrastructure Date: Mon, 29 Jan 2018 19:13:40 -0800 Message-ID: <20180130031340.GV26209@tassilo.jf.intel.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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Linus Torvalds , David Woodhouse , Arjan van de Ven , Eduardo Habkost , KarimAllah Ahmed , Linux Kernel Mailing List , 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 Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org > Right now, we are dealing with one workaround, which is tied to > Skylake-era model numbers. Yes, we could report a Skylake model > number, and Linux guests would use IBRS instead of retpoline. But this Nobody is planning to use IBRS and Linus has rejected it. > approach doesn't scale. What happens when someone introduces a > workaround tied to some other model numbers? There are already many of those in the tree for other issues and features. So far you managed to survive without. Likely that will be true in the future too. -Andi