lkml.org 
[lkml]   [2018]   [Jan]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [RFC,05/10] x86/speculation: Add basic IBRS support infrastructure
Date
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.

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.

My apologies for posting onto the mailing list out of the blue. Someone asked my opinion on this suggestion. I'm definitely interested in figuring out whether Linux can fully mitigate the SkyLake RSB problem in virtual environments, but it's not clear how best to achieve that.

Thanks,

David Dunn

\
 
 \ /
  Last update: 2018-01-29 23:29    [W:0.079 / U:0.780 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site