x86: Add routines for querying XSAVE feature information

[bnovkov]

Summary

This patch adds several routines that track and expose information about various XSAVE-related features.
More specifically, it adds the ability to check whether a given XFEATURE is supported and which XSAVE extensions are supported.
Furthermore, it adds several routines for calculating the size and offsets within a save area given a XSAVE feature bitmap.

Test Plan

Tested by converting D46397 to use the newly added interfaces.
No issues were encountered while tracing.

[bnovkov]

A quick remark regarding code placement - I couldn't decide where this code should reside so I ultimately placed it in cpu_machdep.c, but I'm not too happy about it.
I'd certainly like to hear your thoughts on where this should reside.

[kib]

amd64/amd64/fpu.c seems to be the natural place for the new functions.
Despite named 'fpu', the file deals with the whole non-GPR part of the CPU state.

sys/x86/include/specialreg.h

381

Commit this chunk already

sys/x86/x86/cpu_machdep.c

1811

Does it ever make sense to call these functions if XSAVE(S) are not supported?
Would it be better to convert the checks into KASSERTs?

1817

'else' is not needed

[bnovkov]

Address @kib 's comments:

• split specialreg.h definitions into separate commit
• move xstate routines to amd64/fpu.c

[bnovkov]

sys/x86/x86/cpu_machdep.c

1811

hm, calling these routines without xsave support does not make sense indeed, but I wonder what's the best way to handle this.
I guess we could convert these into KASSERTs and document that the caller must check for XSAVE support before calling these routines, maybe even add cpu_xsave_supported into fpu.h. What do you think?

[kib]

sys/amd64/amd64/fpu.c

1309 ↗

(On Diff #146995)

Why cannot you check for use_xsave instead?

sys/x86/x86/cpu_machdep.c

1811

Typically the low level functions are only called by the higher-level when the hw has required features because high-level simply refuses to work if features are absent. This makes the re-check of the features in the low-level redundant.

But asserts are useful at least as a form of the documentation for assumptions.

[bnovkov]

Address @kib 's comments:

• Move checks to assertions
• Check for use_xsave

[bnovkov]

sys/amd64/amd64/fpu.c

1309 ↗

(On Diff #146995)

I was not aware of use_xsave, thanks!

[kib]

sys/amd64/amd64/fpu.c

1302 ↗

(On Diff #147327)

We already have xsave_area_desc.
Can we extend it instead of introducing a parallel structure?

Also look how we malloc large enough xsave_area_desc instead of hardcoding the max known extension.

[bnovkov]

Address @kib 's comments:

• Move XFEATURE component metadata into xsave_area_desc

[bnovkov]

sys/amd64/amd64/fpu.c

1302 ↗

(On Diff #147327)

Same as with`use_xsave`, I managed to miss xsave_area_desc.
I've extended the struct with a flag field, but I had to keep an additional variable for tracking XSAVE extensions.

[kib]

sys/amd64/amd64/fpu.c

1305 ↗

(On Diff #147494)

Still I want to get rid of the max xfeature number hardcoded.

1332 ↗

(On Diff #147494)

Is this ilog2()?

1333 ↗

(On Diff #147494)

1345 ↗

(On Diff #147494)

1371 ↗

(On Diff #147494)

1374 ↗

(On Diff #147494)

1392 ↗

(On Diff #147494)

ilog2()?

1394 ↗

(On Diff #147494)

[bnovkov]

Address @kib 's comments.