On Tue 10-Jan-2017 2:20 PM, Corey Richardson wrote:
On 01/09/2017 12:37 AM, Adrian.Danis@data61.csiro.au wrote:
Hi Corey,

The original intention of the 'aggressive' check was to somewhat prevent
your case where the user has set the size higher than required and may
be inadvertently be wasting memory by having the TCBBits end up larger
than needed. I agree that it can be a little inconvenient, so will
change it allow sizes that are larger, but emit a warning.

Sounds great, thanks!

Comparing against ebx instead of ecx is quite deliberate as this way we
only measure the size required for the features that the user actually
wanted to use as defined in CONFIG_XSAVE_FEATURE_SET. This is why we do
this check just after performing 'write_xcr0' with said desired features.

Hm, this isn't consistent with my observations of the actual behavior,
although I'm not seeing why at this point.

On my Ivy Bridge Xeon CPU (supports AVX) with
CONFIG_XSAVE_FEATURE_SET=3, using Qemu/KVM with -cpu host and the linked
kernel config (and a small patch to always print out ebx/ecx), I get 576
for ebx and 832 for ecx.
This makes sens to me. You have set feature mask to 3, which means support for SSE and FPU. The size for those two features, which is all the the kernel will enable, is 576 bytes.
The 832 is if you were to also turn on AVX (which is bit 2). Now if you set feature mask to 7, so that the SSE, FPU and AVX features are enabled then you should get ebx also reporting 832.

Of course, if you're able to perform AVX instructions on AVX state with the feature mask set to 3 without getting a fault, then something is going very wrong.

Kernel config: http://ix.io/1PCY

My only patch from 4.0.0: http://ix.io/1PCZ

Kernel log: http://ix.io/1PD3

Qemu invocation:

qemu-system-x86_64  -cpu host,+avx -enable-kvm -nographic -kernel ~/proj/robigalia/sel4/stage/kernel-x86_64-pc99  -initrd ~/proj/robigalia/hello-world/target/x86_64-sel4-robigalia/release/hello-world
Maybe there's another issue at play here?