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=-7.9 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 86EDEC43461 for ; Thu, 3 Sep 2020 17:59:23 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4890620775 for ; Thu, 3 Sep 2020 17:59:23 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4890620775 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id B416C6B0002; Thu, 3 Sep 2020 13:59:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AC9646B0003; Thu, 3 Sep 2020 13:59:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 96A4C6B0037; Thu, 3 Sep 2020 13:59:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0231.hostedemail.com [216.40.44.231]) by kanga.kvack.org (Postfix) with ESMTP id 7DAFA6B0002 for ; Thu, 3 Sep 2020 13:59:22 -0400 (EDT) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 3D433181AC9CC for ; Thu, 3 Sep 2020 17:59:22 +0000 (UTC) X-FDA: 77222512164.03.comb67_320e764270ab Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin03.hostedemail.com (Postfix) with ESMTP id 12F0028A4E8 for ; Thu, 3 Sep 2020 17:59:22 +0000 (UTC) X-HE-Tag: comb67_320e764270ab X-Filterd-Recvd-Size: 4453 Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by imf30.hostedemail.com (Postfix) with ESMTP for ; Thu, 3 Sep 2020 17:59:19 +0000 (UTC) IronPort-SDR: eTrbAwenKaBB+B+YxNus2h6ODK1lffE7n6ipcqKd5yerOQNxWCqr9scmURcRA40P/V1SKhhCxp M2wQgaBSKY9Q== X-IronPort-AV: E=McAfee;i="6000,8403,9733"; a="175684826" X-IronPort-AV: E=Sophos;i="5.76,387,1592895600"; d="scan'208";a="175684826" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Sep 2020 10:59:16 -0700 IronPort-SDR: X6hOgUBXuT53zGBETVRIl8Y3udPYgeOjMvy4EgfTvR+oR8iOyOvL0gprGjnPMNJMYyxw+50upa fFrRD+sU+TdQ== X-IronPort-AV: E=Sophos;i="5.76,387,1592895600"; d="scan'208";a="334548855" Received: from yyu32-mobl1.amr.corp.intel.com (HELO [10.209.173.133]) ([10.209.173.133]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Sep 2020 10:59:15 -0700 Subject: Re: [PATCH v11 6/9] x86/cet: Add PTRACE interface for CET To: Dave Hansen , Andy Lutomirski Cc: Jann Horn , the arch/x86 maintainers , "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , kernel list , "open list:DOCUMENTATION" , Linux-MM , linux-arch , Linux API , Arnd Bergmann , Balbir Singh , Borislav Petkov , Cyrill Gorcunov , Dave Hansen , Eugene Syromiatnikov , Florian Weimer , "H.J. Lu" , Jonathan Corbet , Kees Cook , Mike Kravetz , Nadav Amit , Oleg Nesterov , Pavel Machek , Peter Zijlstra , Randy Dunlap , "Ravi V. Shankar" , Vedvyas Shanbhogue , Dave Martin , Weijiang Yang References: <46e42e5e-0bca-5f3f-efc9-5ab15827cc0b@intel.com> <40BC093A-F430-4DCC-8DC0-2BA90A6FC3FA@amacapital.net> <88261152-2de1-fe8d-7ab0-acb108e97e04@intel.com> <1b51d89c-c7de-2032-df23-e138d1369ffa@intel.com> <21491d05-6306-0a6f-58a7-8bf29feae8c7@intel.com> <8fcde9bb-284f-f089-96d3-702f501a6258@intel.com> From: "Yu, Yu-cheng" Message-ID: <2a58982b-8a69-1280-86ec-d0b70ede4453@intel.com> Date: Thu, 3 Sep 2020 10:59:14 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <8fcde9bb-284f-f089-96d3-702f501a6258@intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 12F0028A4E8 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam03 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 9/3/2020 9:42 AM, Dave Hansen wrote: > On 9/3/20 9:32 AM, Andy Lutomirski wrote: >>> Taking the config register out of the init state is illogical, as is >>> writing to SSP while the config register is in its init state. >> What's so special about the INIT state? It's optimized by XSAVES, but >> it's just a number, right? So taking the register out of the INIT >> state is kind of like saying "gdb wanted to set xmm0 to (0,0,0,1), but >> it was in the INIT state to begin with", right? > > Yeah, that's a good point. The init state shouldn't be special, as the > hardware is within its right to choose not to use the init optimization > at any time. > Then, I would suggest changing get_xsave_addr() to return non-null for the INIT state case. For the other two cases, it still returns NULL. But this also requires any write to INIT states to set xstate_bv bits properly. This would be a pitfall for any code addition later on. Looking at this another way. Would it be better for the debugger to get an error and then to set the MSR directly first (vs. changing the XSAVES INIT state first)?