linux-kernel - Re: [PATCH 084/208] x86/fpu: Rename xsave.header::xstate

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: <554A5D23.2030405@linux.intel.com>
Date:	Wed, 06 May 2015 11:27:47 -0700
From:	Dave Hansen <dave.hansen@...ux.intel.com>
To:	Ingo Molnar <mingo2.kernel.org@...il.com>
CC:	linux-kernel@...r.kernel.org,
	Andy Lutomirski <luto@...capital.net>,
	Borislav Petkov <bp@...en8.de>,
	Fenghua Yu <fenghua.yu@...el.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Oleg Nesterov <oleg@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 084/208] x86/fpu: Rename xsave.header::xstate_bv to 'xfeatures'

On 05/05/2015 11:16 PM, Ingo Molnar wrote:
> Btw., does Intel have any special plans with xstate compaction?
> 
> AFAICS in Linux we just want to enable xfeat_mask_all to the max, 
> including compaction, and never really modify it (in the task's 
> lifetime).

Special plans?

If we do an XRSTORS on it before we do an XSAVES, then we need to worry.
 But, if we do an XSAVES, the CPU will set it up for us.

> I'm also wondering whether there will be any real 'holes' in the 
> xfeatures capability masks of future CPUs: right now xfeatures tend to 
> be already 'compacted' (because new CPUs tend to support all 
> xfeatures), so compaction mostly appears to be an academic feature. Or 
> is there already hardware out there where it matter?

There is a hole in the SDM today.  See section 2.6 in the currently
released 054 version.  I also know of actual hardware platforms with
holes.  *PLUS*, someone can always shot down CPUID bits in their
hypervisor or with kernel command-line options.

> Maybe once we get AVX512 in addition to MPX we can use compaction 
> materially: as there will be lots of tasks without MPX state but with 
> AVX512 state - in fact I suspect that will be the common case.

Right.

But we'd need to get to a point where we are calling 'xsaves' with a
Requested Feature BitMask (aka RFBM[]) that had holes in it.  As it
stands today, we always call it with RFBM=-1 and so we always have
XCOMP_BV = XCR0.

We'd need to determine which fields are in the init state before we do
an xsaves.

> OTOH MPX state is relatively small compared to AVX and AVX512 state, 
> so skipping the hole won't buy us much, and the question is, how 
> expensive is compaction, will save/restore be slower with compaction 
> enabled? Has to be measured I suspect.

Yep.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/