From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A0CE4C433E3 for ; Thu, 25 Mar 2021 07:27:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6B5B961A24 for ; Thu, 25 Mar 2021 07:27:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229919AbhCYH0f (ORCPT ); Thu, 25 Mar 2021 03:26:35 -0400 Received: from mga11.intel.com ([192.55.52.93]:6371 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229547AbhCYH0P (ORCPT ); Thu, 25 Mar 2021 03:26:15 -0400 IronPort-SDR: M+pd+nCG5c7YBvlqyOv7H32KokVtfkeJ4uTscnzMRMJ54OgEf+dBtHkCuGxD4RJOK6QQ3mXYMs aulZPyJQ1q3w== X-IronPort-AV: E=McAfee;i="6000,8403,9933"; a="187570299" X-IronPort-AV: E=Sophos;i="5.81,277,1610438400"; d="scan'208";a="187570299" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Mar 2021 00:26:14 -0700 IronPort-SDR: 5YUFgyEOmHp/+MWrN7JiWpc6CggC+fZhcCS9g7MCs9puzXcGvQ41vXaUw9ODLfEgKGWFXk1e8n qEK6gUaHOmZg== X-IronPort-AV: E=Sophos;i="5.81,277,1610438400"; d="scan'208";a="415870120" Received: from unknown (HELO [10.238.130.187]) ([10.238.130.187]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Mar 2021 00:26:10 -0700 Subject: Re: [PATCH v4 14/22] x86/fpu/xstate: Expand the xstate buffer on the first use of dynamic user state To: "Bae, Chang Seok" Cc: Len Brown , Andy Lutomirski , Thomas Gleixner , Borislav Petkov , Ingo Molnar , X86 ML , "Brown, Len" , "Hansen, Dave" , "Liu, Jing2" , "Shankar, Ravi V" , LKML References: <20210221185637.19281-1-chang.seok.bae@intel.com> <20210221185637.19281-15-chang.seok.bae@intel.com> <87o8fda2ye.fsf@nanos.tec.linutronix.de> <6ed9d725-a6cb-4147-9c8a-2fe240e4bb10@linux.intel.com> <87fb254f-a904-303e-daee-c9a3e9bf13b7@linux.intel.com> From: "Liu, Jing2" Message-ID: <84047b4a-48e3-6efc-643a-06cfcc0630cc@linux.intel.com> Date: Thu, 25 Mar 2021 15:26:08 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org >>> For AMX, we must still reserve the space, but we are not going to write zeros >>> for clean state. We so this in software by checking XINUSE=0, and clearing >>> the xstate_bf for the XSAVE. As a result, for XINUSE=0, we can skip >>> writing the zeros, even though we can't compress the space. >> So my understanding is that clearing xstate_bv will not help prevent saving >> zeros, but only not masking EDX:EAX, since the following logic. Not sure if >> this is just what you mean. :) > FWIW, PATCH21 [1] uses the instruction mask to skip writing zeros on sigframe. > Then, XSAVE will clear the xstate_bv for the xtile data state bit. > > [1] https://lore.kernel.org/lkml/20210221185637.19281-22-chang.seok.bae@intel.com/ Yes, no mask in EDX:EAX works in such case. Thanks for pointing out the patch. BRs, Jing > > Thanks, > Chang