Received: by 10.223.176.5 with SMTP id f5csp1485041wra; Wed, 31 Jan 2018 07:08:59 -0800 (PST) X-Google-Smtp-Source: AH8x227YXBPOQrk9yZUijZgdMg/9ecfLA2i+iIJtMpAuovGh/BjHDvDgU/C6F0Yf7fRfBOAinq3j X-Received: by 10.98.89.71 with SMTP id n68mr18823685pfb.121.1517411338902; Wed, 31 Jan 2018 07:08:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517411338; cv=none; d=google.com; s=arc-20160816; b=FHLswTpExWBkf/ONVaXywGzDjvKPrrXhnOSJBYxajeEHtM2W3uroKhJOUIfE1WAJb+ zcsZh6R6vvixC3cCsf6/XkgOJ0F5VDTbfYw7yFupk6S5QUsDumjUKUvXDRKo4prLpV4M Omx9lBmMJ/uxmhbu9uCaN3suXkh17CMdUxHSbTIFc46InOk6TCUEIeFPG6mjXWqXlw7+ 0Ru4sDYX2sUnXWIWk556Y0L8l6TH6edm42ZzVB9nidP1vqlKPgYck94K7oo+2lzvuM3f KguFz1Ot9kHLOofCUbL0YqfhtsQqCJgN04VVXbvdm37acG/07f8lVataoosuXv7I/oLk Bomg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=IAN3KM/J4BVoYwCHKkVPD2O9BABDp/QtEfT4T8gf2Bg=; b=WKs/Aj1W3OAZj7EIiCQMsycgGHDWEHhEcEzza6mpU/zlCTijsVbYK18Af8bFfFZjic 61vMaxOtvsJZjDr6gTqVRlUDM08Z9AFWs1uwxbTP+Iqvp9hpmeR8SHZJAmfEauMAdGCQ dlhANyHF8ycVEjI/YT6HLZtd3V0Mvwgyjm9fvx40DzFqYw3jBCTXybshaP/aU3KH/Ozn jNJEO7o7+44FqSm5DOqc1yoBqwDpJDKenOT0c7FQhHJi5Sy42fKlgh8aoj99/xbDIJ6l LSBWhJdjCaoazHweWHZq7Ouq+HCA7Y0ZjnyPQEf+GHejAZnpYUSbUGHQFqnK0MtM7Bnm p9QQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l7-v6si4958708plk.510.2018.01.31.07.08.44; Wed, 31 Jan 2018 07:08:58 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752988AbeAaPIR (ORCPT + 99 others); Wed, 31 Jan 2018 10:08:17 -0500 Received: from mx1.redhat.com ([209.132.183.28]:35252 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751788AbeAaPIP (ORCPT ); Wed, 31 Jan 2018 10:08:15 -0500 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A4BFF2DB708; Wed, 31 Jan 2018 15:08:15 +0000 (UTC) Received: from work-vm (ovpn-116-205.ams2.redhat.com [10.36.116.205]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 060FA620C7; Wed, 31 Jan 2018 15:07:53 +0000 (UTC) Date: Wed, 31 Jan 2018 15:07:48 +0000 From: "Dr. David Alan Gilbert" To: Paolo Bonzini Cc: Andi Kleen , Jim Mattson , 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 , Radim =?utf-8?B?S3LEjW3DocWZ?= , Thomas Gleixner , Tim Chen , Tom Lendacky , KVM list , the arch/x86 maintainers Subject: Re: [RFC,05/10] x86/speculation: Add basic IBRS support infrastructure Message-ID: <20180131150747.GG2521@work-vm> 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> <68a15b64-1031-ddf1-e209-e38ac1280c59@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <68a15b64-1031-ddf1-e209-e38ac1280c59@redhat.com> User-Agent: Mutt/1.9.1 (2017-09-22) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Wed, 31 Jan 2018 15:08:15 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Paolo Bonzini (pbonzini@redhat.com) wrote: > 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. In some ways we've been luckiest on x86; my understanding is ARM have a similar set of architecture-specific errata and aren't really sure how to expose this to guests either. Dave > Paolo -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK