From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AH8x226NmkgG/Hy1xsH8fgSJ85m24z8wDhiEslRThMEakB8hz9eOKq9e/RE9NthVVmTBoG9XMyol ARC-Seal: i=1; a=rsa-sha256; t=1517262264; cv=none; d=google.com; s=arc-20160816; b=O9mQfmGPTTUAKqevTkb+Or//UbKtWAgy8/wgcbqLYkjmIIJoVmm/NMQ1dtCm1MEIIu nuaWoBYYVNFxetRNLRTcM5eZS67I92/3FVj6m+jjaDx7UjPg1anJFiITl0kZ8Q9PUg8q gJAy+XE6bCqPV/Gbv1uHRt0ax7WQKRl1v4zJ/ju+kQwtxisO1f6XyiP2trnaDLLJKSvq k0a0rcmS9RMTcWBrjEtxKJew0VVWP4n2225zbfezNzufaDy9M8DdgiRXiIUUo+dPAcAU TXC1kGrIQvDbqkpe01+llQ7s1qayIzgzXI6qEfvNgBmpAiL0ZATJJrimjzhvPhLlBVRX UhsA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=mThJML5ckjovtTUnLkphEBwujqHWb3xxx+BmqaAuTuQ=; b=AMCu78BjpV0HleAR8r9W4e8LDiYCzUnFcYaFSerVvTcukG7CMOzPLW3QBgF6KbeImI w9X2lYZbN69qbyql5gR1NzYrgtZWD0I9YUgKdW67+5fuN1ddLosCMVIOYXOFK3C9xola I0rH8dqp7pw0/zpl9vnJR4+RhMVPhbdSAxLqdZ16V74YOYCJx0gUkmusxwYmlbda9q65 5EhaBYgekt5GdALE6YYLIOJQCz2uv6zW+qXujteSyx0WUgPxC2iAnHu2l4DOaPudk6Gv G2juA5WvIktsMuv9J5712e3KCF/Te5qqPrDL33buXmphuqo8by3CJ0TJlynxUiK0EwOM Li9g== 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 19:44:21 -0200 From: Eduardo Habkost To: David Woodhouse Cc: Arjan van de Ven , KarimAllah Ahmed , linux-kernel@vger.kernel.org, Andi Kleen , 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" Subject: Re: [RFC,05/10] x86/speculation: Add basic IBRS support infrastructure Message-ID: <20180129214421.GW25150@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> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1517259759.18619.38.camel@infradead.org> 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?1590964796793010713?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On Mon, Jan 29, 2018 at 09:02:39PM +0000, David Woodhouse wrote: > > > On Mon, 2018-01-29 at 12:44 -0800, Arjan van de Ven wrote: > > On 1/29/2018 12:42 PM, Eduardo Habkost wrote: > > > > > > The question is how the hypervisor could tell that to the guest. > > > If Intel doesn't give us a CPUID bit that can be used to tell > > > that retpolines are enough, maybe we should use a hypervisor > > > CPUID bit for that? > > > > the objective is to have retpoline be safe everywhere and never use IBRS > > (Linus was also pretty clear about that) so I'm confused by your question > > The question is about all the additional RSB-frobbing and call depth > counting and other bits that don't really even exist for Skylake yet in > a coherent form. > > If a guest doesn't have those, because it's running some future kernel > where they *are* implemented but not enabled because at *boot* time it > discovered it wasn't on Skylake, the question is what happens if that > guest is subsequently migrated to a Skylake-class machine. > > To which the answer is obviously "oops, sucks to be you". So yes, > *maybe* we want a way to advertise "you might be migrated to Skylake" > if you're booted on a pre-SKL box in a migration pool where such is > possible.  > > That question is a reasonable one, and the answer possibly the same, > regardless of whether the plan for Skylake is to use IBRS, or all the > hypothetical other extra stuff. Maybe a generic "family/model/stepping/microcode really matches the CPU you are running on" bit would be useful. The bit could be enabled only on host-passthrough (aka "-cpu host") mode. If we really want to be able to migrate to host with different CPU models (except Skylake), we could add a more specific "we promise the host CPU is never going to be Skylake" bit. Now, if the hypervisor is not providing any of those bits, I would advise against trusting family/model/stepping/microcode under a hypervisor. Using a pre-defined CPU model (that doesn't necessarily match the host) is very common when using KVM VM management stacks. -- Eduardo