On Thu, Jul 23, 2020 at 11:41:55AM -0700, Dave Hansen wrote:

On 7/23/20 9:56 AM, Sean Christopherson wrote:

quoted

On Thu, Jul 23, 2020 at 09:41:37AM -0700, Dave Hansen wrote:

quoted

On 7/23/20 9:25 AM, Sean Christopherson wrote:

quoted

How would people feel about taking the above two patches (02 and 03 in the
series) through the KVM tree to enable KVM virtualization of CET before the
kernel itself gains CET support?  I.e. add the MSR and feature bits, along
with the XSAVES context switching.  The feature definitons could use "" to
suppress displaying them in /proc/cpuinfo to avoid falsely advertising CET
to userspace.

AIUI, there are ABI issues that need to be sorted out, and that is likely
going to drag on for some time. 

Is this a "hell no" sort of idea, or something that would be feasible if we
can show that there are no negative impacts to the kernel?

Negative impacts like bloating every task->fpu with XSAVE state that
will never get used? ;)

Gah, should have qualified that with "meaningful or measurable negative
impacts".  E.g. the extra 40 bytes for CET XSAVE state seems like it would
be acceptable overhead, but noticeably increasing the latency of XSAVES
and/or XRSTORS would not be acceptable.

It's 40 bytes, but it's 40 bytes of just pure, unadulterated waste.  It
would have no *chance* of being used.  It's also quite precisely

Well, technically the guest would be using that space :-).

measurable on a given system:

	cat /proc/slabinfo | grep task_struct | awk '{print $3 * 40}'

I don't expect it would do *much* to XSAVE/XRSTOR.  There's probably an
extra conditional and jump in the ucode, but that's probably in the
noise.  I assume that all the CET state has functioning init and
modified trackers and we don't do anything to spoil their state.  It
would be good to check that in practice, though it probably isn't the
end of the world either way.  We've had some bugs in the past where we
accidentally took things out of their init state.

It will make signal entry/return slower since we use a plain XSAVE
without the init optimization.  But, that's just a single cacheline on
average and some 0's to write.  Probably not noticeable, including the
40 bytes of extra userspace signal stack space.

I think that puts me in the "mildly annoyed" camp more than "hell no",
but "mildly annoyed" is pretty much my resting state, so it doesn't
really move the needle. :)

Why the urgency, though?

	https://windows-internals.com/cet-on-windows/

?

No urgency, it'd simply be one less KVM feature for us to be carrying and
refreshing.  And as a sort of general question, I was curious if folks
would be open to merging KVM support before kernel.