From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: AH8x2274GqWxgYsY8xG0m9O/0g6YXgnJGhDdR0CDaLGeokP4l19kX7umH00OdAQPWEAhUdwF0Jo2 ARC-Seal: i=1; a=rsa-sha256; t=1517274522; cv=none; d=google.com; s=arc-20160816; b=G8/XB9D4N0h/WVYF75WlnkRT65iLlpx8c28yrJ0KBnfvOLF/0NR65R5BvlH3o/oz/K EljHcXvdwzGU8ZmMsJ5hd2lJynykWNRhdnanuOkF0dyiCf1EY9JhCs8RIgqGB4LpmNkI m5BOwb2NDcb55IdxRDgBsqXBBxCEwulft6DPV76iUaQecy/Tbw7uPvVrcRBo4FjXYwVs rPEJ6z/O5GXtgc0uqKY1bGqKzZjWyhjptroxJwvLC/yu2IFdoBW/RiaOa6+Dkm7TEzQT p3u01I277uVjK6KQRsheHIz8w3ljRBDiUvtkzgxPTacRpJ35+lnzUD51mGDT6rbUM4ro adrQ== 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=8L9hoJPxLFfmpvaa12NkrnM8vVU3iv2Atc/vJaII2aw=; b=jd9uV5lpvaxhH+GDC7ETa+fat25jsGKvmzyXec/JqEAWZ69xrdN2+deFVv/qQgKwol rLqXIQHRZGnn9ZUd+AOLEBSRWyRFG88BPmQlage+vpIiGPz5o3KUvySq8yB7sI1hbuFN hMeZDzCemqk1rvy/WiUu3aMs6lZa49I8zRxGFWIeqjrDR63Mg9ZNRC6XS/Ds5ion4BLV RswMQ9UJEU/g1/5L7nXkEeh+yWFTjIQKyfJZXMpxL5aQIQmalmoJ3npnOmSp9QYKL3Za 6ON3o6pcYx/6AuL5pmVtBWl3fwiO9SiOuTEibuZpY/VwpMI2H4YfOPCaaxNHR87zCRf9 byZA== 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:08:32 -0200 From: Eduardo Habkost To: David Dunn Cc: Arjan van de Ven , KarimAllah Ahmed , "Wilson, Matt" , "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" , Fred Jacobs , Jim Mattson , David Woodhouse Subject: Re: [RFC,05/10] x86/speculation: Add basic IBRS support infrastructure Message-ID: <20180130010832.GA21702@localhost.localdomain> References: <7EB9643C-D2DD-477A-90DE-05DC653D2D4B@vmware.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7EB9643C-D2DD-477A-90DE-05DC653D2D4B@vmware.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?1590977649584258362?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On Mon, Jan 29, 2018 at 10:29:28PM +0000, David Dunn wrote: > On Mon, 2018-01-29 at 13:45:07 -0800, Eduardo Habkost wrote: > > > 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, > > I don't see how this is possible in a modern virtualization > environment. > > Under VMware, a VM will be migrated to SkyLake if one is in the > cluster and supports the features exposed to the VM. This can > occur for suspend/resume as well. > > The migration pool isn't a constant. Hosts can be added to a > cluster and VMs can be instructed to move across clusters. So > there doesn't need to be a SkyLake around when the VM powers on > in order for it to eventually end up on a SkyLake. If this is the case for your deployment, this means the guest must never assume it won't run on a Skylake host (even if f/m/s is not Skylake), doesn't it? Then the hypervisor won't set the "we promise the host CPU is never going to be Skylake" bit. > > 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. If the VM can be moved at any point of time to a different model of host CPU, this means you won't tell the guest it can trust f/m/s because it doesn't represent the underlying host. You won't set the "f/m/s/m really matches the host CPU" bit. On both scenarios you describe above, it sounds like Linux must assume it could migrated to a Skylake host at any moment. This is exactly why I'm proposing those extra bits. -- Eduardo