From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AH8x2263erBfTzRF1oRuhvxLKzdjFO43LTDeq0T78D/apB334+TBTFPkNIsXRw/UlNXbWhzmSYV2 ARC-Seal: i=1; a=rsa-sha256; t=1517411296; cv=none; d=google.com; s=arc-20160816; b=Vtp/4k6LCsbln4qXlT6ZDvf/B97XACKR858HBjuF2prrDGh0qiOwBf+eiqO5SQEMb5 zrTclI45ys4FKT/II4kCcUP7aa2HYpBipSwI3rJ3EZyC036XrKE9hEn5gjKGPt82i+Yc 0WwnL2tJsavzaYTkFuY4wO3BvUzmTVlmmJt6nQUEwhRumrQLTeaeLY2vBSVE3NDpr8/J zNfkemMB0JFYlt/ECe91ERYyM/Xb1nUNmxNzXcqFUdQqNO6xJs75aPy/8atVLpXFZJyu GknWALFdO4K+2KdSrtIGqnkTZXKGWRhAvrZoh8AIiwna6gQSc1RfaSL2yQ9B8aSbX0Te 5QTA== 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=IAN3KM/J4BVoYwCHKkVPD2O9BABDp/QtEfT4T8gf2Bg=; b=vW/viBWf1EDYyRK3BgwvUYsRFSB0vBjJH2hiB1Nt0Zg+nULd0O+ig9TVfLTKC9/xW6 N3DY3UUxwGh2CgOp++5YkGy2ErXTVyC6xuTPL6e/D1a37lOanj1SoHdsrwtpCanMwfJ9 6U2hRG2YltNkmcF8htsXtWr1nBypPtCAZeT/K5wOjS/+ei3vlLFaZcCiVckWKIx6bgTK UGs2VB38wtUlC0d0fLPd/rJ+z7zdq0tqT9UB1HoBuTL2YszYE29jaJyPhTBwP1PhCQV5 ONTxAi0KlidqyjkWR8a9ErKxpXt9zXzYHuYHufDcUSmxFocbe5B9Yget84Ja2GEH68yI odmQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of dgilbert@redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=dgilbert@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 dgilbert@redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=dgilbert@redhat.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com 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-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1590140581449802182?= X-GMAIL-MSGID: =?utf-8?q?1591121067546174560?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: * 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