Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1394764

Re: [PATCH v4 10/10] x86/xsaves: Re-enable XSAVES

From Dave Hansen <dave.hansen@linux.intel.com>
Newsgroups linux.kernel
Subject Re: [PATCH v4 10/10] x86/xsaves: Re-enable XSAVES
Date 2016-05-05 00:50 +0200
Message-ID <rvdMe-4aR-5@gated-at.bofh.it> (permalink)
References <r92ut-2hO-1@gated-at.bofh.it> <r92uv-2hO-29@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


It's my fault, but you also need to go update
	
	fpu__xfeature_set_state()
and
	__raw_xsave_addr()

The theoretical problem is that you might ask for a __raw_xsave_addr()
of a component which has been compacted out of an XSAVES buffer and thus
has no address.  We could work around this by doing a memmove() and
moving the components "up" after the one we are trying to set in order
to make space.

But, since we *always* call XSAVES with an instruction mask of -1 and
end up with a requested feature bitmap (RFBM) equal to XCR0, I think we
can do a shortcut because we'll practically *always* have an
xcomp_bv==RFBM==XCR0, which means that all (present) components will
always have an address.

So, the alternative to doing the memmove() is to add some WARN_ON_FPU()
checks to enforce xcomp_bv==RFBM==XCR0 in places where we call
XSAVES/XRSTORS and __raw_xsave_addr(), maybe more.

Back to linux.kernel | Previous | NextNext in thread | Find similar | Unroll thread


Thread

Re: [PATCH v4 10/10] x86/xsaves: Re-enable XSAVES Dave Hansen <dave.hansen@linux.intel.com> - 2016-05-05 00:50 +0200
  Re: [PATCH v4 10/10] x86/xsaves: Re-enable XSAVES Yu-cheng Yu <yu-cheng.yu@intel.com> - 2016-05-05 01:00 +0200

csiph-web