On Tue, Jan 10, 2023, Mingwei Zhang wrote:
After the execution of __tilerelease(), AMX component will be in INIT state. Therefore, execution of xsavec saving the AMX state into memory will
s/xsavec/XSAVEC
cause the XSTATE_BV[18] cleared in xheader. However, the XCOMP_BV[18] will remain set. Fix the error in comment.
Cc: Jim Mattson jmattson@google.com Cc: Venkatesh Srinivas venkateshs@google.com Cc: Aaron Lewis aaronlewis@google.com
No need for a blank line.
Signed-off-by: Mingwei Zhang mizhang@google.com
tools/testing/selftests/kvm/x86_64/amx_test.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/kvm/x86_64/amx_test.c b/tools/testing/selftests/kvm/x86_64/amx_test.c index bd72c6eb3b67..16533949a189 100644 --- a/tools/testing/selftests/kvm/x86_64/amx_test.c +++ b/tools/testing/selftests/kvm/x86_64/amx_test.c @@ -204,7 +204,7 @@ static void __attribute__((__flatten__)) guest_code(struct tile_config *amx_cfg, GUEST_SYNC(4); __tilerelease(); GUEST_SYNC(5);
- /* bit 18 not in the XCOMP_BV after xsavec() */
- /* bit 18 not in the XSTATE_BV after xsavec() */
I would rather overhaul the entire comment, e.g.
/* Verify XTILEDATA is not set in XSTATE_BV after XSAVEC */
I had to look at the definition of XFEATURE_XTILEDATA to verify that yes, indeed, bit 18 is XTILEDATA.
As for xsavec() vs. XSAVE, IIUC the clearing of XCOMP_BV[18] is a side effect of XSAVEC the instruction, not something extra done by xsavec() the function.
set_xstatebv(xsave_data, XFEATURE_MASK_XTILEDATA); __xsavec(xsave_data, XFEATURE_MASK_XTILEDATA); GUEST_ASSERT((get_xstatebv(xsave_data) & XFEATURE_MASK_XTILEDATA) == 0); -- 2.39.0.314.g84b9a713c41-goog