From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AH8x224yhkp4WgAqnMxgZmKl7SwcQ96BOuurI32DqsxjnVYgEFTrHK2aJYuE3idELmduvuX68kSB ARC-Seal: i=1; a=rsa-sha256; t=1517411056; cv=none; d=google.com; s=arc-20160816; b=F0ig9Twcota5c8Nvf36cYpHksUSSfdTvE0ifLmOUoq7HxHyugfGQZELT8kD1l/5P1Z kERp5MVchEaItQy5bTTSjNGY+Sr080Os3fJWaPG971g98CEc+5wg6FiAC/ApNVq9y7k7 3VW//eFPdRuQUJlAm4o3IjpP7R/BWlv3If9GBXbw8h6vUozX22a2hh1BYbbzaSAs2cQo 7r69zpwfJTa0xIZnzL91qMGg1JK1E4GNzi+j5wrzYyDpqz/+EsnHEy0fP9g163O/rpzn Bzvkdja83eGdU/Q2H9u2O7HWGNN0ZyBsR+5jETZgAkwR0djoa5PkgTR6Z4ptt4rgyJwM Z08g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:cc:to:subject :arc-authentication-results; bh=hU2zzqaLRxKLB/AkCJhx7a86ySXwHD8w8KZUFWz2hUU=; b=Chsl372FU2njURQuLufL+YbnTJFhhe3HwwkP7Xi4FHIvafnShPa1gYlHe2tDhCc6W2 rTsaTI9V193bdT3IY6nY+o84TlLlBPwfgSC8YdJeS3zfmeZppT+rbw569jOxkZNIpJqk E9I8dEoPkX7WOttDfYMbcZPskBguwAy5d5nLfkmwHQ7roEh7ssMOomnb7c/1nC03FtgF QQk5XqnFWxQy7wdMr6miP8PlF7sznA2gCSJasUCWWfArDBHEzTr82ttOaJxsJrn/BfPw 4ZA5YywFV9L8Cqy3XN4ODO0gSa0g+3Oc/JB+ETlZof5oIR4J+Q/1qGmAcSZX3qDqFJOu yVyQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of pbonzini@redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=pbonzini@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 pbonzini@redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=pbonzini@redhat.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Subject: Re: [RFC,05/10] x86/speculation: Add basic IBRS support infrastructure To: Andi Kleen , Jim Mattson 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 , Laura Abbott , Masami Hiramatsu , Peter Zijlstra , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= , Thomas Gleixner , Tim Chen , Tom Lendacky , KVM list , the arch/x86 maintainers , "Dr. David Alan Gilbert" 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> <20180130031340.GV26209@tassilo.jf.intel.com> From: Paolo Bonzini Message-ID: <68a15b64-1031-ddf1-e209-e38ac1280c59@redhat.com> Date: Wed, 31 Jan 2018 10:03:51 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <20180130031340.GV26209@tassilo.jf.intel.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1590140581449802182?= X-GMAIL-MSGID: =?utf-8?q?1591120816046350008?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On 29/01/2018 22:13, Andi Kleen wrote: >> 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. "Guests have to live with processor fuckups" is actually a much better answer than "Hypervisors may need to revisit their practice", since at least it's clear where the blame lies. Because really it's just plain luck. It just happens that most errata are for functionality that is not available to a virtual machine (e.g. perfmon and monitor workarounds or buggy TSC deadline timer that hypervisors emulate anyway), that only needs a chicken bit to be set in the host, or the bugs are there only for old hardware that doesn't have virtualization (X86_BUG_F00F, X86_BUGS_SWAPGS_FENCE). CPUID flags are guaranteed to never change---never come, never go away. For anything that doesn't map nicely to a CPUID flag, you cannot really express it. Also if something is not architectural, you can pretty much assume that you cannot know it under virtualization. f/m/s is not architectural; family, model and stepping mean absolutely nothing when running in virtualization, because the host CPU model can change under your feet at any time. We force guest vendor == host vendor just because otherwise too much stuff breaks, but that's it. Paolo