From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752859AbbH1QoU (ORCPT ); Fri, 28 Aug 2015 12:44:20 -0400 Received: from mga11.intel.com ([192.55.52.93]:8510 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751879AbbH1QoT (ORCPT ); Fri, 28 Aug 2015 12:44:19 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.17,425,1437462000"; d="scan'208";a="550388145" From: Andi Kleen To: Dave Hansen Cc: Ingo Molnar , dave.hansen@linux.intel.com, bp@alien8.de, fenghua.yu@intel.com, hpa@zytor.com, x86@kernel.org, tim.c.chen@linux.intel.com, linux-kernel@vger.kernel.org, Linus Torvalds , "Kleen\, Andi" , alexander.shishkin@linux.intel.com, peterz@infradead.org Subject: Re: [PATCH 09/11] x86, fpu: correct and check XSAVE xstate size calculations References: <20150827171102.1BDF27E5@viggo.jf.intel.com> <20150827171110.ADA00471@viggo.jf.intel.com> <20150828045427.GB25556@gmail.com> <55E070D3.1060208@sr71.net> Date: Fri, 28 Aug 2015 09:44:17 -0700 In-Reply-To: <55E070D3.1060208@sr71.net> (Dave Hansen's message of "Fri, 28 Aug 2015 07:31:47 -0700") Message-ID: <87oahr1hy6.fsf@tassilo.jf.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Dave Hansen writes: >> >> That would give us a gentle way to double check our assumptions here. > > Actually, the newest state that you will see in the wild is for > Processor Trace, and it _is_ a supervisor state. However, we don't use > it in Linux for our Processor Trace support, and Andi says we probably > never will. > > So we probably shouldn't warn on it. Yes we shouldn't. It would be unnecessary scary for people with old kernels on newer hardware. Since supervisor state needs generally a driver, it's harmless to ignore if there is none. As to why Processor Trace is not using it: The XSAVE support assumes that there is a single buffer for each thread. But perf generally doesn't work this way, it usually has only a single perf event per CPU per user, and when tracing multiple threads on that CPU it inherits perf event buffers between different threads. So XSAVE per thread cannot handle this inheritance case directly. Using multiple XSAVE areas (another one per perf event) would defeat some of the state caching that the CPUs do. In theory it would be possible to detect when inheritance is not used and only use XSAVE in this case. But it's not clear that is common enough and worth the trouble. For now the manual MSR based switching seems to work well enough, although it's more overhead. -Andi -- ak@linux.intel.com -- Speaking for myself only