* 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/