Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1394764
| 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 |
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 | Next — Next in thread | Find similar | Unroll 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