Re: [PATCH 09/11] x86, fpu: correct and check XSAVE xstate size calculations

[Andi Kleen]

Dave Hansen <dave@xxxxxxxx> writes:

>> 
>> That would give us a gentle way to double check our assumptions here.
>
> Actually, the newest state that you will see in the wild is for
> Processor Trace, and it _is_ a supervisor state.  However, we don't use
> it in Linux for our Processor Trace support, and Andi says we probably
> never will.
>
> So we probably shouldn't warn on it.

Yes we shouldn't. It would be unnecessary scary for people with old
kernels on newer hardware. Since supervisor state needs generally a
driver, it's harmless to ignore if there is none.

As to why Processor Trace is not using it:

The XSAVE support assumes that there is a single buffer for each
thread. But perf generally doesn't work this way, it usually has
only a single perf event per CPU per user, and when tracing
multiple threads on that CPU it inherits perf event buffers between
different threads. So XSAVE per thread cannot handle this inheritance
case directly.

Using multiple XSAVE areas (another one per perf event) would defeat
some of the state caching that the CPUs do.

In theory it would be possible to detect when inheritance is not used
and only use XSAVE in this case. But it's not clear that is common
enough and worth the trouble.

For now the manual MSR based switching seems to work well enough,
although it's more overhead.

-Andi

-- 
ak@xxxxxxxxxxxxxxx -- Speaking for myself only
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/