[lkml]   [2018]   [Jan]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC,05/10] x86/speculation: Add basic IBRS support infrastructure
For GCE, "you might be migrated to Skylake" is pretty much a
certainty. Even if you're in a zone that doesn't currently have
Skylake machines, chances are pretty good that it will have Skylake
machines some day in the not-too-distant future.

In general, making these kinds of decisions based on F/M/S is probably
unwise when running in a VM.

On Mon, Jan 29, 2018 at 1:02 PM, 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.

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