From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AH8x2248TYBRo9FfKmEJmj0Hfpb9Mo9vM6ZULTXsVodq9SJkaYSvUZWQVOGIKCg0LOTFjOU7TjRT ARC-Seal: i=1; a=rsa-sha256; t=1517276268; cv=none; d=google.com; s=arc-20160816; b=NkCD4cR1PdHXM45pqnA5ptCkpGAHn3gUzOaJ2tDjv6WYALmXE1zD1cye4oc6SG3GJ4 R+9fJmfs5J0B43y+m3+HQiVtPC7kV89I52nwV0HbapEGrPrSPgO9bWZyoGzB30WYZkYe EEED9D5wV+TmF4gf4L3mefZI9AqfM6Aa0VpyOpT54uIleNQzwgkDhpxtm/UT7B/ip0Qq DGYpK9TDp3UAF7FUT8wjt2kEdIhUKtqyQQgXeGpg9CCDH4SGRXwkzrDX2SXvn9Ht/8Uk f+glb9o6PSxQXGwLMkBETTHRy8mNqCkSrXxXA+AbY2afuU7vzlG+sBSuc5n+xIXSTNfJ +r7g== 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=ucJLcSEetWtecZj3/Gkjtp7eRLwmHlBKI891jLvDeA4=; b=v5jneo3MhKPrzL8VUq9XRmzjIzXru2eqCMl9qju6ZAZaKDZ1kGA72mnMPHWfLdzfKE mrci3XOLiB4K8bnWdNAgGE2nZswnkpINp2hRp1b+utlzt7/cjYSHNEviAqVqp8YEb/vf lzjTa1hwD5om4RB8DFIiYdRWdr6wVO4r+i4TvFXVa8x8viB1/n+zOGwsmpuk5zXPjoom 3NNqq+dslplWXfMCgL/IrB70RbJL/pYQxlBub33yd5reeUm9cZdnsYwwbDS/qWP3kLtZ 4YwxsZDtiWuCdwNBHWzdAr2ihnzGA2hXnmRcOemSc2yA3isoyloFMhO1NPnHWHFP+USq pqhg== 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:37:45 -0200 From: Eduardo Habkost To: Andi Kleen Cc: Jim Mattson , David Woodhouse , Arjan van de Ven , KarimAllah Ahmed , LKML , 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 list , the arch/x86 maintainers , "Dr. David Alan Gilbert" Subject: Re: [RFC,05/10] x86/speculation: Add basic IBRS support infrastructure Message-ID: <20180130013745.GF21702@localhost.localdomain> 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> <20180129215025.GX25150@localhost.localdomain> <20180129222512.GT26209@tassilo.jf.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180129222512.GT26209@tassilo.jf.intel.com> 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?1590979480698479047?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On Mon, Jan 29, 2018 at 02:25:12PM -0800, Andi Kleen wrote: > > I agree with your point that the common hypervisor practice to fake > old model numbers will break some of the workarounds. Hypervisors > may need to revisit their practice. > > > > In general, making these kinds of decisions based on F/M/S is probably > > > unwise when running in a VM. > > > > Certainly. That's why I suggest not trusting f/m/s unless the > > hypervisor is explicitly saying it's accurate. > > This would be only useful if there's an useful result of this > non trust. > > But there isn't. Except for panic there's nothing you could do. > And I don't think panic would be reasonable. Why it isn't an useful result to enable the Skylake workaround if unsure about the host CPU? > > The "Skylake bit " or "not skylake bit" doesn't make any sense > to me. If a hypervisor wants to enable Skylake workarounds > they need to provide the Skylake model number. If they don't > think they need them because the VM can never be migrated > to Skylake, then they don't need to set that model > number. > > So there isn't any need for inventing any new bits, it's > all already possible. It's already possible, until we find another bug in another CPU model that also needs to be worked around. We can't represent "please work around bugs in both Skylake and Westmere" in f/m/s. -- Eduardo