(Apologies as I was brought into this thread late, but I believe I have context).
Could a new "feature" be enumerated on Skylake and beyond which specifies that a particular problem exists which requires different mitigation than on previous processors? Perhaps a CPUID bit enumerating this feature (along side IBRS, IBPB and STIBP) could be exposed on only the newer CPUs. System software could then query this to know what form of mitigation is necessary. This could be over-reported in virtualized environments (e.g. a Nehalem CPU could be represented as needing the Skylake mitigation), such that sometimes the heavier Skylake+ mitigation would be applied on older CPUs. This is correct, just slower. I'm just suggesting this rather than keying on Family/Model/Stepping to avoid breaking virtual machine migration, et cetera. Thanks, Fred, sticking his neck out. On Jan 29 2:29PM, 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. > > 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 >
