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,URIBL_BLOCKED,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 0F9AEC2B9F4 for ; Mon, 28 Jun 2021 10:11:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E672261982 for ; Mon, 28 Jun 2021 10:11:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232699AbhF1KOX (ORCPT ); Mon, 28 Jun 2021 06:14:23 -0400 Received: from mga01.intel.com ([192.55.52.88]:21428 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232735AbhF1KOJ (ORCPT ); Mon, 28 Jun 2021 06:14:09 -0400 X-IronPort-AV: E=McAfee;i="6200,9189,10028"; a="229541755" X-IronPort-AV: E=Sophos;i="5.83,305,1616482800"; d="scan'208";a="229541755" Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Jun 2021 03:11:43 -0700 X-IronPort-AV: E=Sophos;i="5.83,305,1616482800"; d="scan'208";a="419115990" Received: from unknown (HELO [10.238.130.181]) ([10.238.130.181]) by fmsmga007-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Jun 2021 03:11:40 -0700 Subject: Re: [PATCH v5 14/28] x86/fpu/xstate: Prevent unauthorised use of dynamic user state To: Dave Hansen , "Bae, Chang Seok" Cc: Andy Lutomirski , Borislav Petkov , Thomas Gleixner , Ingo Molnar , X86 ML , "Brown, Len" , "Liu, Jing2" , "Shankar, Ravi V" , LKML References: <20210523193259.26200-1-chang.seok.bae@intel.com> <20210523193259.26200-15-chang.seok.bae@intel.com> <872cb0a2-3659-2e6c-52a8-33f1a2f0a2cd@kernel.org> <36D0486A-D955-4C32-941A-A2A4985A450C@intel.com> <48e86785-838d-f5d4-c93c-3232b8ffd915@intel.com> <16681A30-59EA-4E35-8A51-CCD403026C92@intel.com> <6cdba263-889f-ce98-b7da-4a1380cedc65@intel.com> From: "Liu, Jing2" Message-ID: <4411de99-e827-6119-394b-b994131d6554@linux.intel.com> Date: Mon, 28 Jun 2021 18:11:38 +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: <6cdba263-889f-ce98-b7da-4a1380cedc65@intel.com> 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 On 6/17/2021 3:28 AM, Dave Hansen wrote: > On 6/16/21 12:23 PM, Bae, Chang Seok wrote: >> On Jun 16, 2021, at 12:01, Hansen, Dave wrote: >>> On 6/16/21 11:47 AM, Bae, Chang Seok wrote: >>>> Reading XINUSE via XGETBV is cheap but not free. I don't know spending a >>>> hundred cycles for this WARN is big deal but this is one of the most >>>> performance-critical paths. >>> Is XGETBV(1) really a hundred cycles? That seems absurdly high for a >>> non-serializing register read. >> This was checked to convince the benefit intended by PATCH25 -- >> https://lore.kernel.org/lkml/20210523193259.26200-26-chang.seok.bae@intel.com/ > That's odd. How is it possible that the performance of XGETBV(1) > informed the design of that patch without there being any mention of > XGETBV in the comments or changelog? Hi Chang, I noticed the XGETBV(1) cycles you ran, however I calculated only ~16 cycles in the corresponding machine. BRs, Jing