> Upon reading the rest of the series, I think the above might be based
> on me misunderstanding this bit.
>
> If I understand things correctly then what is new with emerald_rapids
> is support for a second set/type of tests called " Array Scan test"
> and the old test method / test-type is also still supported.
Yes. Emerald Rapids supports the new array scan test *in addition to*
the existing scan test. Future CPUs will support both of these tests
and may add additional tests. Further in the future if some new tests
cover the same functionality as older tests, some of the older tests
may be dropped.
So the INTEGRITY_CAPABILITIES MSR is a bitmap enumerating
which tests are supported on each model.
> And you have chosen to register 2 misc-devices , one per supported
> test type ?
>
> Have I understood that correctly?
Yes.
> May I ask why use 1 misc device per test-type. Why not just add
> a single new sysfs_attr to the existing misc device to trigger
> the new test-type ?
That's an interesting idea. So we'd have:
# echo $cpu > run_test
# cat status
...
# cat details
...
for our first type of test (introduced with Sapphire Rapids). Then
in the same directory add a new file to run the array test (on Emerald
Rapids andother future CPUs that support it)
# echo $cpu > run_array_test
# cat status
...
# cat details
...
But I see a problem with the "current_batch" file (that will show up if a future
test also needs to load some test data ... spoiler ... it will).
We can't do:
# echo 2 > current_batch
... what should this load, don't know until the user types one of
# echo $cpu > run_test
or
# echo $cpu > run_${name}_test
Perhaps also have per test type names to load the test images?
# echo 2 > current_${name}_batch
# echo $cpu > run_${name}_test
I'm not sure this is better than splitting the tests into different directories.
-Tony
