From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754795AbbHFHPw (ORCPT ); Thu, 6 Aug 2015 03:15:52 -0400 Received: from mail-wi0-f180.google.com ([209.85.212.180]:33938 "EHLO mail-wi0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753059AbbHFHPu (ORCPT ); Thu, 6 Aug 2015 03:15:50 -0400 Date: Thu, 6 Aug 2015 09:15:45 +0200 From: Ingo Molnar To: Dave Hansen Cc: dave.hansen@linux.intel.com, linux-kernel@vger.kernel.org, bp@alien8.de, fenghua.yu@intel.com, hpa@zytor.com, x86@kernel.org, Thomas Gleixner , Peter Zijlstra , Linus Torvalds , Andy Lutomirski , Denys Vlasenko Subject: Re: [PATCH] x86, fpu: correct XSAVE xstate size calculation Message-ID: <20150806071545.GB2194@gmail.com> References: <20150728172143.6DDFECA7@viggo.jf.intel.com> <20150805103227.GA3233@gmail.com> <55C21EFC.3060802@sr71.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55C21EFC.3060802@sr71.net> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Dave Hansen wrote: > > I realize that the calculation and what CPUID gives us should match, but it's > > not really good for the kernel to not know the precise layout of a critical > > task context data structure ... > > There is no architectural guarantee that the sum of xstate sizes will be the > same as what comes out of that CPUID leaf. It would be nice, but it's not > architectural and I've run in to platforms where that assumption does not hold. WHY? What sense does it make to have a blob we don't know the exact layout of? How will debuggers or user-space in general be able to print (and change) the register values if they don't know the layout? If 'compacted' format means "binary blob only the CPU can decode, not the kernel" then our answer is "uhm, no, thank you, we'll use standard format instead" ... And no, "it's not Intel architectural" is a stupid and somewhat circular argument IMHO: the kernel always knew how to decompose CPU context dumps and you'll have to come up with a damn better reason to break that than pointing at some text in an Intel document. > > So can we turn this into 'double check the CPUID size and print a warning on > > mismatch' kind of boot time sanity check? Preferably for all XSAVE* data > > formats we can run into. I'd be fine with applying such a patch ahead of > > enabling compaction again. > > I don't think that is sufficient. > > There are 4 reasons to apply this patch that I can think of: > 1. There is no architectural guarantee that the calculation (sum of > xstate sizes) will match what CPUID gives us as the size of the > buffer. I've seen this in practice. So the context layout and structure on such CPUs has to be mapped and properly taken into account in the size calculation. How can GDB or any other (kernel) debugger display (and change) individual fields reliably if the layout is not known? > 2. The alignment bit indicates that there is space used in the buffer > which is not part of a state component. The current code does not > take that in to account. Then it has to be taken it into account - just like user-space has to take it into account if it wants to display (and change) individual fields... > 3. The code is currently asking for the size of an XSAVE-produced > buffer. The code will be wrong the moment we switch to XSAVES > because XSAVES saves more things than XSAVE and uses more space. This will have to be fixed before we move to compacted format. > 4. It makes the code smaller and simpler, especially if you consider > what would happen if we added "real" alignment support. What would happen? Thanks, Ingo