From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AH8x225Fir25oXKhsStHaKS1q8QFbQP45bKkrG/LodSnLfxIKKY7ci/g9PG3nc/eYpQNnjswV54/ ARC-Seal: i=1; a=rsa-sha256; t=1517393760; cv=none; d=google.com; s=arc-20160816; b=RlQW6A2Sc0wCSOZwVe6sUP+hiQSjKtRO74zmL0T9VKxbEmnpSS4vg1uP74PJ+Lfyg1 O0W/8vxUjBF3aHf5F4hp7+f7CIlpIzjpiF8ImjGIRMBndzA0wEK0zz35DLjrFy2T/xIo mi0A2lxThEZyubEWgIKfNjuoGc1A6J4ODfoSefTSbwfVWIF1IWq+fOBeZBImHlMlwOIP G90GSrdrWeymjuP4bwo/ieXM6JUKL22uBvy29qTTkxuDH0rKr+nqFvROeWxGDqwxY9vd bdRueWoiFDreOuQw6CV7bV0Mo72KeXi6bubwW8as2vwWLyr/OJ8KNPQ8Ud1WBxcXExOQ dLqA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=mime-version:user-agent:references:message-id:in-reply-to:subject :cc:to:from:date:arc-authentication-results; bh=0HL7c7021s51M+7JtpHjZ6uJ4f2RwSxy0Y2eHahPjgM=; b=Qns2APz5P9UacIUg5kF1WjOGU4zAIM+0e1hWAr6hm3yaQzKsVKjDZgeKiaiytLcZcI zkyJ3nBpLUG3q4E4pyVhti1OqomRUV59lER2sFxOcjaU+uw/EkEdufQL3ihugP1yo7yA aWjwmd0AasDHQ601GrB/XCejm1OO43KQnM4HjcuOqkvyZdTXst31inSSkPaCBBKd455H jDMi+qBsH1oToUd87aJRrnvgchvsNSoIwq1wxUAUDCFbKNsUkrp3HBWFImp3OVcjUdCn Ajr+3a/Yo7YZSu/B5QPrZUTM6kPUChIPo/rOx3j+P5075hPXnec/2EjS/1JixLjgZx0E wh8Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of tglx@linutronix.de designates 146.0.238.70 as permitted sender) smtp.mailfrom=tglx@linutronix.de Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of tglx@linutronix.de designates 146.0.238.70 as permitted sender) smtp.mailfrom=tglx@linutronix.de Date: Wed, 31 Jan 2018 11:15:50 +0100 (CET) From: Thomas Gleixner To: Christophe de Dinechin cc: Alan Cox , Linus Torvalds , David Woodhouse , Arjan van de Ven , Eduardo Habkost , KarimAllah Ahmed , Linux Kernel Mailing List , 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 , Masami Hiramatsu , Paolo Bonzini , Peter Zijlstra , =?ISO-8859-2?Q?Radim_Kr=E8m=E1=F8?= , 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 In-Reply-To: <200C59E8-80F3-4FEC-BA3B-E6A56FA12C74@dinechin.org> Message-ID: 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> <20180130204623.583b1a7a@alans-desktop> <200C59E8-80F3-4FEC-BA3B-E6A56FA12C74@dinechin.org> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="8323329-714891976-1517393750=:2293" X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1590140581449802182?= X-GMAIL-MSGID: =?utf-8?q?1591102680049028346?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-714891976-1517393750=:2293 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT On Wed, 31 Jan 2018, Christophe de Dinechin wrote: > > On 30 Jan 2018, at 21:46, Alan Cox wrote: > > > >> If you are ever going to migrate to Skylake, I think you should just > >> always tell the guests that you're running on Skylake. That way the > >> guests will always assume the worst case situation wrt Specte. > > > > Unfortunately if you do that then guest may also decide to use other > > Skylake hardware features and pop its clogs when it finds out its actually > > running on Westmere or SandyBridge. > > > > So you need to be able to both lie to the OS and user space via cpuid and > > also have a second 'but do skylake protections' that only mitigation > > aware software knows about. > > Yes. The most desirable lie is different depending on whether you want to > allow virtualization features such as migration (where you’d gravitate > towards a CPU with less features) or whether you want to allow mitigation > (where you’d rather present the most fragile CPUID, probably Skylake). > > Looking at some recent patches, I’m concerned that the code being added > often assumes that the CPUID is the correct way to get that info. > I do not think this is correct. You really want specific information about > the host CPUID, not whatever KVM CPUID emulation makes up. That wont cut it. If you have a heterogenous farm of systems, then you need: - All CPUs have to support IBRS/IBPB or at least hte hypervisor has to pretend they do by providing fake MRS for that - Have a 'force IBRS/IBPB' mechanism so the guests don't discard it due to missing CPU feature bits. Though this gets worse. You have to make sure that the guest keeps _ALL_ sorts of mitigation mechanisms enabled and does not decide to disable retpolines because IBRS/IBPB are "available". Good luck with making all that work. Thanks, tglx --8323329-714891976-1517393750=:2293--