From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752434AbdFOXhM (ORCPT ); Thu, 15 Jun 2017 19:37:12 -0400 Received: from mga04.intel.com ([192.55.52.120]:6214 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751590AbdFOXhL (ORCPT ); Thu, 15 Jun 2017 19:37:11 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.39,345,1493708400"; d="scan'208";a="100053416" Subject: Re: xgetbv nondeterminism To: Andy Lutomirski , "H. J. Lu" References: <1eb55c22-6c90-e1b3-19d4-cb7b2c6fc0dc@intel.com> Cc: "Robert O'Callahan" , "linux-kernel@vger.kernel.org" , X86 ML From: Dave Hansen Message-ID: Date: Thu, 15 Jun 2017 16:37:09 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/15/2017 03:18 PM, Andy Lutomirski wrote: >> As you pointed out, if you are using XSAVEC's compaction features by >> leaving bits unset in the requested feature bitmap registers, you have >> no idea how much data XSAVEC will write, unless you read XINUSE with >> XGETBV. But, you can get around *that* by just presizing the XSAVE >> buffer to be big. > I imagine that, if you're going to save, do something quick, and > restore, you'd be better off allocating a big buffer rather than > trying to find the smallest buffer you can get away with by reading > XINUSE. Also, what happens if XINUSE nondeterministically changes out > from under you before you do XSAVEC? I assume you can avoid this > becoming a problem by using RFBM carefully. That's a good point. HJ, does your XGETBV1 code disable signals, btw? A signal could theoretically change XINUSE if the handler modified the on-stack XSAVE state before sigreturn. Also, your glibc patch talks a lot about the upper parts of the register being zeroed, but that isn't precisely what XGETBV1 does, right? It tells you whether the upper portion of the registers are in the init state. But, the high parts of the registers could be zero, and not in the init state, rights? I'm missing something, though... Is the stuff in question here called *every* time one of these AVX-using functions is called, or called only the first time when the binding is done? It's also bonkers that software has to go to this trouble. This is precisely what XSAVEOPT is supposed to do for us.