From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AH8x224K5UUy2DZkpaKRcLdsr83u6deZ/X5Vl6FvoUZN0jAAlyMY5SYN0e8JZhlCIYPT1YUppL0J ARC-Seal: i=1; a=rsa-sha256; t=1517274662; cv=none; d=google.com; s=arc-20160816; b=k5zrDlmHLgIExlhP8ZvKDozwRT0SuwLFZGI65wmVirKIw88B23h3w7nyg/KlNF3csk TSsGH20czGtLYVwDdSvmzJ/W5IQ0Q0puSIWKUaQULI8KZt2kp3juQB8eKa0TNvUFw2OZ /ZscmZACJg6mWr4u6UwimmeLUimZoNHXb33RTlVMPUGcU2kWnPcCEmXCChVpI66VfhNz I0OGdJiHb9lKW4atNJJno2l5AAs02H0Ej1oJ63SkMCH65NWxNKFHHT6LfmF5yHVgeJRp gPv/OVozbcwWlfkCE6JUe0a7RXIMQ7oQLS2sbqdekQkn6T/LNR3B38gcO02yhVKk+JaZ m+7g== 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=g/ykQ0ukQks5NIk44H5YOYSWaYUJEkAD2/IdskNY44w=; b=bXIltMt+XZXPuikGw1fRln9ShsMlhVifaLql5ChJmoy+7B/W/r4XZ5GW8qdkQjbmdq dLsk9KG93jOslvwxqo+U/0APNb7vKvF9dD6dFnTQjiJ2TPDgO0lIHUNEwimrxx8lAPfg 2V7ZInva5adeM+DfaJrkWBatI/FKdFLXmVWp4MSUE+YMHdMV7K+GV2drHIpUfPXSeuUU nd6NM34Fv+ZysEFt6Ob2NrEF428I+F7nX15enHcy1cAZfg6uwPYSDSWKuPDWs7en9vb+ kPZEC7UnRtNEcOd5UxPAeFuVEhR+zGc+bjNZ4+PPoZRjFu0/B3hrUP8QMZP1GtJjYOxC l10g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of ehabkost@redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=ehabkost@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 ehabkost@redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=ehabkost@redhat.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Date: Mon, 29 Jan 2018 23:10:59 -0200 From: Eduardo Habkost To: Jim Mattson Cc: Andi Kleen , David Dunn , Arjan van de Ven , KarimAllah Ahmed , "Wilson, Matt" , "linux-kernel@vger.kernel.org" , 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 , Linus Torvalds , Masami Hiramatsu , Paolo Bonzini , Peter Zijlstra , Radim =?utf-8?B?S3LEjW3DocWZ?= , Thomas Gleixner , Tim Chen , Tom Lendacky , "kvm@vger.kernel.org" , "x86@kernel.org" , "Dr. David Alan Gilbert" , Fred Jacobs , David Woodhouse Subject: Re: [RFC,05/10] x86/speculation: Add basic IBRS support infrastructure Message-ID: <20180130011059.GB21702@localhost.localdomain> References: <7EB9643C-D2DD-477A-90DE-05DC653D2D4B@vmware.com> <20180129224124.GU26209@tassilo.jf.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Fnord: you can see the fnord 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?1590977796075868946?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On Mon, Jan 29, 2018 at 02:49:51PM -0800, Jim Mattson wrote: > And if we expect to introduce Cascade Lake into the pool in the > future, we use a Cascade Lake model number? > > It sounds like you are suggesting that we set the model number to the > highest model number that will ever be introduced into the pool, at > any time in the future. That approach would also fail the > 'is_skylake_era()' test. (Not to mention that we have no idea what > Intel's highest compatible model number will be.) Exactly, that's why virtualization and live-migration break the model of just checking f/m/s/microcode: the guest doesn't need to work around bugs that are present in the current host, but the set of bugs that could appear on any future host it can run on. > > On Mon, Jan 29, 2018 at 2:41 PM, Andi Kleen wrote: > >> Even if we expose bit to indicate that FMS matches the underlying host, when does the guest know to query that? The VM can be moved at any point in time, including after the guest asks if FMS matches host. > > > > There's no way to enable these mitigations later, so if you always > > have to enable the super set of all the mitigations for all the hosts you > > might be migrating too. > > > > As of currently that means if you want to ever migrate to Skylake you should > > set the Skylake model number and you're good. > > > > -Andi -- Eduardo