linux-kernel - Re: [PATCH v4 14/22] x86/fpu/xstate: Expand the xstate buffer on the first use of dynamic user state

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <6ed9d725-a6cb-4147-9c8a-2fe240e4bb10@linux.intel.com>
Date:   Wed, 24 Mar 2021 11:14:58 +0800
From:   "Liu, Jing2" <jing2.liu@...ux.intel.com>
To:     Len Brown <lenb@...nel.org>, Andy Lutomirski <luto@...nel.org>
Cc:     Thomas Gleixner <tglx@...utronix.de>, Borislav Petkov <bp@...e.de>,
        Ingo Molnar <mingo@...nel.org>, X86 ML <x86@...nel.org>,
        Len Brown <len.brown@...el.com>,
        Dave Hansen <dave.hansen@...el.com>,
        "Liu, Jing2" <jing2.liu@...el.com>,
        "Ravi V. Shankar" <ravi.v.shankar@...el.com>,
        LKML <linux-kernel@...r.kernel.org>,
        "Bae, Chang Seok" <chang.seok.bae@...el.com>
Subject: Re: [PATCH v4 14/22] x86/fpu/xstate: Expand the xstate buffer on the
 first use of dynamic user state



On 3/24/2021 5:01 AM, Len Brown wrote:
>> I have an obnoxious question: do we really want to use the XFD mechanism?
> Obnoxious questions are often the most valuable! :-)
>
> [...]
> cheers,
> Len Brown, Intel Open Source Technology Center
>
> ps. I agree that un-necessary XINUSE=1 is possible.
> Notwithstanding the issues initially deploying AVX512, I am skeptical
> that it is common today.
Sorry, I'm trying to understand from...
> IMO, the problem with AVX512 state
> is that we guaranteed it will be zero for XINUSE=0.
> That means we have to write 0's on saves.
why "we have to write 0's on saves" when XINUSE=0.

Since due to SDM, if XINUSE=0, the XSAVES will *not* save the data and
xstate_bv bit is 0; if use XSAVE, it need save the state but
xstate_bv bit is also 0.
>   It would be better
> to be able to skip the write -- even if we can't save the space
> we can save the data transfer.  (This is what we did for AMX).
With XFD feature that XFD=1, XSAVE command still has to save INIT state
to the area. So it seems with XINUSE=0 and XFD=1, the XSAVE(S) commands
do the same that both can help save the data transfer.

The reason I'm interested in XINUSE denotation is that it might be helpful
for the XFD MSRs context switch cost during vmexit and vmenter.

Thanks,
Jing
>
> pps. your idea of requiring the user to allocate their own signal stack
> is interesting.   It isn't really about allocating the stack, though --
> the stack of the task that uses the feature is generally fine already.
> The opportunity is to allow tasks that do *not* use the new feature to
> get away with minimal data transfer and stack size.  As we don't
> have the 0's guarantee for AMX, we bought the important part
> of that back.