On Wed, May 04, 2016 at 03:41:49PM -0700, Dave Hansen wrote:
> 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 compac
On 05/04/2016 03:41 PM, Dave Hansen wrote:
> 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 (p
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 aro
On Wed, May 04, 2016 at 03:15:38PM -0700, Dave Hansen wrote:
> On 05/02/2016 09:11 AM, Yu-cheng Yu wrote:
> > On Fri, Apr 29, 2016 at 05:40:44PM -0700, Dave Hansen wrote:
> >> That's better than what we had before, but it relies entirely on testing
> >> coverage and runtime checks.
> >>
> >> Is it
On 05/02/2016 09:11 AM, Yu-cheng Yu wrote:
> On Fri, Apr 29, 2016 at 05:40:44PM -0700, Dave Hansen wrote:
>> That's better than what we had before, but it relies entirely on testing
>> coverage and runtime checks.
>>
>> Is it too much to ask that you also take a look and audit all the places
>> the
On Fri, Apr 29, 2016 at 05:40:44PM -0700, Dave Hansen wrote:
> That's better than what we had before, but it relies entirely on testing
> coverage and runtime checks.
>
> Is it too much to ask that you also take a look and audit all the places
> the XSAVE buffer is accessed in the kernel and ensur
On 04/29/2016 04:12 PM, Yu-cheng Yu wrote:
> On Fri, Apr 29, 2016 at 01:32:15PM -0700, Dave Hansen wrote:
>> The reason I haven't acked this patch is that I want to be _sure_ that
>> we've audited all of the call paths that access the XSAVE buffer to
>> ensure that they can all either handle the XS
On Fri, Apr 29, 2016 at 01:32:15PM -0700, Dave Hansen wrote:
> The reason I haven't acked this patch is that I want to be _sure_ that
> we've audited all of the call paths that access the XSAVE buffer to
> ensure that they can all either handle the XSAVES format *or* don't care
> for whatever reaso
On 03/04/2016 10:12 AM, Yu-cheng Yu wrote:
> We did not handle XSAVES* instructions correctly. There were issues in
> converting between standard and compacted format when interfacing with
> user-space. These issues have been corrected.
>
> Add a WARN_ONCE() to make it clear that XSAVES supervisor
We did not handle XSAVES* instructions correctly. There were issues in
converting between standard and compacted format when interfacing with
user-space. These issues have been corrected.
Add a WARN_ONCE() to make it clear that XSAVES supervisor states are not
yet implemented.
Signed-off-by: Yu-c
10 matches
Mail list logo
