* Ingo Molnar <mingo2.kernel....@gmail.com> wrote:
> > XSTATE_BV is the set of states written to the xsave area.
> >
> > XCOMP_BV is essentially always XCR0 (aka pcntxt_mask, aka
> > xfeatures_mask) or'd with bit 63.
>
> So how about this naming:
>
> /*
> * Mask of xstate components currently not in init state,
> * typically written to by XSAVE*.
> */
> u64 xfeat_mask_used; /* SDM: XSTATE_BV */
>
> /*
> * Mask of all state components saved/restored, plus the
> * compaction flag. (Note that the XRSTORS instruction caches
> * this value, and the next SAVES done for this same
> * area expects it to match, before it can perform the 'were
> * these registers modified' hardware optimization.)
> */
> u64 xfeat_mask_all; /* SDM: XCOMP_BV */
>
> (Note that I kept the SDM name easily greppable.)
Hm, so the problem with this naming is that for non-compacted XRSTOR,
XCOMP_BV has to be zero. (This seems nonsensical btw., as there's a
separate 'compaction' flag at bit 63 already.)
So a better name would be:
/*
* Mask of xstate components currently not in init state,
* typically written to by XSAVE*.
*/
u64 xfeat_used_mask; /* SDM: XSTATE_BV */
/*
* This mask is non-zero if the CPU supports state compaction:
* it is the mask of all state components to be saved/restored,
* plus the compaction flag at bit 63.
* (Note that the XRSTORS instruction caches this value, and
* the next SAVES done for this same area expects it to match,
* before it can perform the 'were these registers modified'
* hardware optimization.)
*/
u64 xfeat_comp_mask; /* SDM: XCOMP_BV */
?
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
