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;
Date:   Tue, 30 Jan 2018 10:04:09 -0200
From:   Eduardo Habkost <ehabkost@redhat.com>
To:     Linus Torvalds <torvalds@linux-foundation.org>
Cc:     Arjan van de Ven <arjan@linux.intel.com>,
        David Woodhouse <dwmw2@infradead.org>,
        KarimAllah Ahmed <karahmed@amazon.de>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Andi Kleen <ak@linux.intel.com>,
        Andrea Arcangeli <aarcange@redhat.com>,
        Andy Lutomirski <luto@kernel.org>,
        Ashok Raj <ashok.raj@intel.com>,
        Asit Mallick <asit.k.mallick@intel.com>,
        Borislav Petkov <bp@suse.de>,
        Dan Williams <dan.j.williams@intel.com>,
        Dave Hansen <dave.hansen@intel.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        "H . Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
        Janakarajan Natarajan <Janakarajan.Natarajan@amd.com>,
        Joerg Roedel <joro@8bytes.org>,
        Jun Nakajima <jun.nakajima@intel.com>,
        Laura Abbott <labbott@redhat.com>,
        Masami Hiramatsu <mhiramat@kernel.org>,
        Paolo Bonzini <pbonzini@redhat.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Radim =?utf-8?B?S3LEjW3DocWZ?= <rkrcmar@redhat.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Tim Chen <tim.c.chen@linux.intel.com>,
        Tom Lendacky <thomas.lendacky@amd.com>,
        KVM list <kvm@vger.kernel.org>,
        the arch/x86 maintainers <x86@kernel.org>,
        "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Subject: Re: [RFC,05/10] x86/speculation: Add basic IBRS support
 infrastructure
Message-ID: <20180130120409.GA26425@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>
 <CA+55aFxBh3LvsQq9wy313NQCn3iu+yuAmsi0zNVxWmGDUUds-A@mail.gmail.com>
 <6c024f95-b12c-9c66-91d7-208ed2c380ff@linux.intel.com>
 <CA+55aFyrKudn2QKe4D==BZCCQDqqfDzQZ6i8PR8-AfAufTtGFQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CA+55aFyrKudn2QKe4D==BZCCQDqqfDzQZ6i8PR8-AfAufTtGFQ@mail.gmail.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, Jan 29, 2018 at 07:32:06PM -0800, Linus Torvalds wrote:
> On Mon, Jan 29, 2018 at 5:32 PM, Arjan van de Ven <arjan@linux.intel.com> wrote:
> >
> > the most simple solution is that we set the internal feature bit in Linux
> > to turn on the "stuff the RSB" workaround is we're on a SKL *or* as a guest
> > in a VM.
> 
> That sounds reasonable.
> 
> However, wouldn't it be even better to extend on the current cpuid
> model, and actually have some real architectural bits in there.

If Intel could do that, it would be great.


> 
> Maybe it could be a bit in that IA32_ARCH_CAPABILITIES MSR. Say, add a
> bit #2 that says "ret falls back on BTB".
> 
> Then that bit basically becomes the "Skylake bit". Hmm?

Yes.  But note that the OS needs to be able to differentiate "old
Skylake that doesn't support the new bit" from "newer Skylake
that doesn't fall back om BTB".  That's why I suggest a
"non-Skylake bit" instead of a "Skylake bit".

-- 
Eduardo