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

Groups > linux.kernel > #1667384

Re: xgetbv nondeterminism

Show all headers | View raw

On Thu, Jun 15, 2017 at 4:37 PM, Dave Hansen <dave.hansen@intel.com> wrote:
> On 06/15/2017 03:18 PM, Andy Lutomirski wrote:
>>> As you pointed out, if you are using XSAVEC's compaction features by
>>> leaving bits unset in the requested feature bitmap registers, you have
>>> no idea how much data XSAVEC will write, unless you read XINUSE with
>>> XGETBV.  But, you can get around *that* by just presizing the XSAVE
>>> buffer to be big.
>> I imagine that, if you're going to save, do something quick, and
>> restore, you'd be better off allocating a big buffer rather than
>> trying to find the smallest buffer you can get away with by reading
>> XINUSE.  Also, what happens if XINUSE nondeterministically changes out
>> from under you before you do XSAVEC?  I assume you can avoid this
>> becoming a problem by using RFBM carefully.
>
> That's a good point.  HJ, does your XGETBV1 code disable signals, btw?
> A signal could theoretically change XINUSE if the handler modified the
> on-stack XSAVE state before sigreturn.

We are preserving the first 8 vector registers used by caller to pass
function parameters.  As long as signal doesn't change XINUSE from
yes to no, we are OK.

> Also, your glibc patch talks a lot about the upper parts of the register
> being zeroed, but that isn't precisely what XGETBV1 does, right?  It
> tells you whether the upper portion of the registers are in the init
> state.  But, the high parts of the registers could be zero, and not in
> the init state, rights?

We are preserving the first 8 vector registers used by caller to pass
function parameters.   We only care the vector bits used to pass
function parameters.   If caller doesn't use the upper bits, we will
always zero the upper bits upon exit.

> I'm missing something, though...  Is the stuff in question here called
> *every* time one of these AVX-using functions is called, or called only
> the first time when the binding is done?

Only the first time.  If you pass "-z now" to linker and set LD_BIND_NOW=1,
_dl_runtime_resolve won't be used.

> It's also bonkers that software has to go to this trouble.  This is
> precisely what XSAVEOPT is supposed to do for us.


-- 
H.J.

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

Thread

xgetbv nondeterminism Andy Lutomirski <luto@kernel.org> - 2017-06-15 07:20 +0200
  Re: xgetbv nondeterminism Dave Hansen <dave.hansen@intel.com> - 2017-06-15 16:40 +0200
    Re: xgetbv nondeterminism Andy Lutomirski <luto@kernel.org> - 2017-06-16 00:20 +0200
      Re: xgetbv nondeterminism "H.J. Lu" <hjl.tools@gmail.com> - 2017-06-16 00:50 +0200
        Re: xgetbv nondeterminism Andy Lutomirski <luto@kernel.org> - 2017-06-16 00:50 +0200
          Re: xgetbv nondeterminism "H.J. Lu" <hjl.tools@gmail.com> - 2017-06-16 01:20 +0200
            Re: xgetbv nondeterminism Andy Lutomirski <luto@kernel.org> - 2017-06-16 01:30 +0200
              Re: xgetbv nondeterminism "H.J. Lu" <hjl.tools@gmail.com> - 2017-06-16 04:20 +0200
                Re: xgetbv nondeterminism Andy Lutomirski <luto@kernel.org> - 2017-06-16 05:10 +0200
                Re: xgetbv nondeterminism "H.J. Lu" <hjl.tools@gmail.com> - 2017-06-16 06:40 +0200
                Re: xgetbv nondeterminism Andy Lutomirski <luto@kernel.org> - 2017-06-16 18:10 +0200
                Re: xgetbv nondeterminism "H.J. Lu" <hjl.tools@gmail.com> - 2017-06-16 18:20 +0200
                Re: xgetbv nondeterminism Andy Lutomirski <luto@kernel.org> - 2017-06-16 18:40 +0200
                Re: xgetbv nondeterminism "H.J. Lu" <hjl.tools@gmail.com> - 2017-06-16 19:50 +0200
                Re: xgetbv nondeterminism Andy Lutomirski <luto@kernel.org> - 2017-06-16 20:00 +0200
                Re: xgetbv nondeterminism "H.J. Lu" <hjl.tools@gmail.com> - 2017-06-16 20:10 +0200
                Re: xgetbv nondeterminism Andy Lutomirski <luto@kernel.org> - 2017-06-17 08:30 +0200
                Re: xgetbv nondeterminism "H.J. Lu" <hjl.tools@gmail.com> - 2017-06-17 15:00 +0200
                Re: xgetbv nondeterminism Andy Lutomirski <luto@kernel.org> - 2017-06-17 18:40 +0200
                Re: xgetbv nondeterminism "H.J. Lu" <hjl.tools@gmail.com> - 2017-06-17 21:50 +0200
      Re: xgetbv nondeterminism Dave Hansen <dave.hansen@intel.com> - 2017-06-16 01:40 +0200
        Re: xgetbv nondeterminism "H.J. Lu" <hjl.tools@gmail.com> - 2017-06-16 04:30 +0200

csiph-web