On 3/24/2021 5:01 AM, Len Brown wrote:
I have an obnoxious question: do we really want to use the XFD mechanism?
Obnoxious questions are often the most valuable! :-)
[...]
cheers,
Len Brown, Intel Open Source Technology Center
ps. I agree that un-necessary XINUSE=1 is possible.
Notwithstanding the issues initially deploying AVX512, I am skeptical
that it is common today.
Sorry, I'm trying to understand from...
IMO, the problem with AVX512 state
is that we guaranteed it will be zero for XINUSE=0.
That means we have to write 0's on saves.
why "we have to write 0's on saves" when XINUSE=0.
Since due to SDM, if XINUSE=0, the XSAVES will *not* save the data and
xstate_bv bit is 0; if use XSAVE, it need save the state but
xstate_bv bit is also 0.
It would be better
to be able to skip the write -- even if we can't save the space
we can save the data transfer. (This is what we did for AMX).
With XFD feature that XFD=1, XSAVE command still has to save INIT state
to the area. So it seems with XINUSE=0 and XFD=1, the XSAVE(S) commands
do the same that both can help save the data transfer.
The reason I'm interested in XINUSE denotation is that it might be helpful
for the XFD MSRs context switch cost during vmexit and vmenter.
Thanks,
Jing
pps. your idea of requiring the user to allocate their own signal stack
is interesting. It isn't really about allocating the stack, though --
the stack of the task that uses the feature is generally fine already.
The opportunity is to allow tasks that do *not* use the new feature to
get away with minimal data transfer and stack size. As we don't
have the 0's guarantee for AMX, we bought the important part
of that back.
