From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751303AbbEGO64 (ORCPT ); Thu, 7 May 2015 10:58:56 -0400 Received: from mga14.intel.com ([192.55.52.115]:25462 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751127AbbEGO6y (ORCPT ); Thu, 7 May 2015 10:58:54 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,384,1427785200"; d="scan'208";a="725366942" Message-ID: <554B7DAA.3040606@linux.intel.com> Date: Thu, 07 May 2015 07:58:50 -0700 From: Dave Hansen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Ingo Molnar CC: Ingo Molnar , linux-kernel@vger.kernel.org, Andy Lutomirski , Borislav Petkov , Fenghua Yu , "H. Peter Anvin" , Linus Torvalds , Oleg Nesterov , Thomas Gleixner Subject: Re: [PATCH 084/208] x86/fpu: Rename xsave.header::xstate_bv to 'xfeatures' References: <1430848300-27877-1-git-send-email-mingo@kernel.org> <1430848300-27877-6-git-send-email-mingo@kernel.org> <554904A6.8040503@linux.intel.com> <20150505181613.GA28562@gmail.com> <55490B1F.3080409@linux.intel.com> <20150506061603.GA13720@gmail.com> <554A5D23.2030405@linux.intel.com> <20150507122209.GB15656@gmail.com> In-Reply-To: <20150507122209.GB15656@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/07/2015 05:22 AM, Ingo Molnar wrote: > I.e. are there any plans beyond using it strictly for full state > save/restore. None that I know of, but having two (relatively) tiny features (protection keys and MPX) might change things. > Btw., regarding XCR0.PKRU: that enables 'Protection Keys' in the PTE > format. What's the main purpose of these keys? They seem to duplicate > the read/write bits in the PTE, with the exception that they don't > impact instruction fetches. So is this used to allow user-space to > execute but otherwise not read instructions? > > Or some other purpose I missed? You can change the permissions of a given key with writes to the register without changing the PTE. No TLB shootdown, plus the permission changes are local to the CPU thread. I have patches today if you're interested. > In any case, these holes are really minor at the moment, and the > question is, what is the performance difference between a 'compactede' > XSAVE*/XRSTOR* pair, versus a standard format one? Yeah, that would be interesting to know. >>> 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. > > Why? I don't think that's necessary. "If RFBM[i] = 0, XSTATE_BV[i] is written as 0." We need to pull XSTATE_BV in to the instruction mask when doing an XSAVE* if our RFBM has bits unset that *are* set in XSTATE_BV. Otherwise, we'll destroy the bits at XSAVE* time. It's not a problem today because the instruction mask is always -1, so it always has every bit set that *MIGHT* be set in XSTATE_BV. As for the whole bit 63 thing... It's possible and valid to have a XCOMP_BV[62:0]=0 because the instruction mask only contained bits that were unset in XCR0|IA32_XSS. You need bit 63 to tell you which format you are using.