Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
IronPort-SDR: Q1U9A7tQGF1N+lR9ALjX5JkEPaRDjvR2MquL2aiVTWyo3fURltIJjKEw9zu1q1uNwygTchwPPa
 E1iMd7XTcqbA==
IronPort-SDR: kM/Uxkv49O/dILkhXiz80obM4+H2nP/jtopgdty5up7kuJa0xO/c3tOskB6OGTdiys+7nfLb9r
 TPU5ZIz/q/VA==
From:   "Bae, Chang Seok" <chang.seok.bae@intel.com>
To:     "Liu, Jing2" <jing2.liu@linux.intel.com>
CC:     Len Brown <lenb@kernel.org>, Andy Lutomirski <luto@kernel.org>,
        "Thomas Gleixner" <tglx@linutronix.de>,
        Borislav Petkov <bp@suse.de>, Ingo Molnar <mingo@kernel.org>,
        X86 ML <x86@kernel.org>, "Brown, Len" <len.brown@intel.com>,
        "Hansen, Dave" <dave.hansen@intel.com>,
        "Liu, Jing2" <jing2.liu@intel.com>,
        "Shankar, Ravi V" <ravi.v.shankar@intel.com>,
        LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4 14/22] x86/fpu/xstate: Expand the xstate buffer on the
 first use of dynamic user state
Thread-Topic: [PATCH v4 14/22] x86/fpu/xstate: Expand the xstate buffer on the
 first use of dynamic user state
Thread-Index: AQHXCIQDYHRUMzQ+BU6HvOsZgq/N2KqNm3qAgAACNwCABKDNAIAAaDcAgAEsK4CAAIcXgIAAHeYA
Date:   Thu, 25 Mar 2021 06:59:51 +0000
Message-ID: <A2F31E33-4F15-431B-8407-438750186895@intel.com>
References: <20210221185637.19281-1-chang.seok.bae@intel.com>
 <20210221185637.19281-15-chang.seok.bae@intel.com>
 <87o8fda2ye.fsf@nanos.tec.linutronix.de>
 <CALCETrVaCmG4jzLCSuy7WYP2K7r-MVZntfugWa8HiVxQ7LpF_A@mail.gmail.com>
 <CAJvTdKmz7aePcpi4i+d3vnqLuNAJEuJCjpGDv5WTYcSUfuxoDg@mail.gmail.com>
 <6ed9d725-a6cb-4147-9c8a-2fe240e4bb10@linux.intel.com>
 <CAJvTdKm_uP-RqoprWWatg725WZOm3T-BHZU8S08dpWe2=1apGw@mail.gmail.com>
 <87fb254f-a904-303e-daee-c9a3e9bf13b7@linux.intel.com>
In-Reply-To: <87fb254f-a904-303e-daee-c9a3e9bf13b7@linux.intel.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-ID: <9A841A4D801D4049859EDFBA47ADB0D9@namprd11.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 1a4de15d-7c9d-49db-bc15-08d8ef5b96a2
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2021 06:59:51.9711
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ldQsScqcf6ODxv1XFThhgz5kDRNN464IvLYuq8H9t8l74F2j/Uro6YCmI7m9RFApGHI4vhCmFcSjE+XEYQi60zhT4/+sakVw/OtXjG/ZZBs=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR11MB4818
X-OriginatorOrg: intel.com
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Mar 24, 2021, at 22:12, Liu, Jing2 <jing2.liu@linux.intel.com> wrote:
> On 3/25/2021 5:09 AM, Len Brown wrote:
>>=20
>> 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=3D0, and cle=
aring
>> the xstate_bf for the XSAVE.  As a result, for XINUSE=3D0, 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 savi=
ng
> 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 sigfra=
me.
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@int=
el.com/

Thanks,
Chang=