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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 223A2C433F5 for ; Fri, 3 Dec 2021 01:14:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 84B266B0072; Thu, 2 Dec 2021 20:13:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7D5186B0074; Thu, 2 Dec 2021 20:13:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 675336B0075; Thu, 2 Dec 2021 20:13:52 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0038.hostedemail.com [216.40.44.38]) by kanga.kvack.org (Postfix) with ESMTP id 59E176B0072 for ; Thu, 2 Dec 2021 20:13:52 -0500 (EST) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 1F6E68A3C4 for ; Fri, 3 Dec 2021 01:13:42 +0000 (UTC) X-FDA: 78874710684.26.6EC3A9C Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf04.hostedemail.com (Postfix) with ESMTP id A9CAB40005 for ; Fri, 3 Dec 2021 01:13:41 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 8A5EEB823BC; Fri, 3 Dec 2021 01:13:40 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A1478C00446; Fri, 3 Dec 2021 01:13:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1638494019; bh=n57k6U7BW8VgLU48lSFDh1oK3CtoLW1LIqJES3Ic1Qg=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=rWxP8RrXU1aUJtsDSV7yB6O9Nbxn0EzwuegKXWK1eBR8dQPcHgNSkF2SWozC+Ko77 HjdsAYV6epgBvjHwk2ij/W0yLTUvcsHXLfakmR27+D1zNMR0/H2ospYKkP/VdQI6X/ 9jbfNank/a+UMNDie59tUgrrLXxYVqAFgqKXw4/9zkAMjMYeKNqEJucGk2NiLYeoT0 XuKpNF7QZy2sskjTf04gxbRDHpi3gFIgJ29H/aygFHH+KpDZzzmdi90vTyIa8+KjZi GjZKz4stzfy0SP+u4AC+5ZYwJAWosoh3zZABovEjZP1rBbNWDcsbp+1MQLTWKROXlC RGn02P4chgrGQ== Message-ID: <0a4a1ad5-5143-bd51-c8db-194f7fa443b7@kernel.org> Date: Thu, 2 Dec 2021 17:13:37 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Subject: Re: [PATCH V7 08/18] x86/entry: Preserve PKRS MSR across exceptions Content-Language: en-US To: Ira Weiny , Dave Hansen , Dan Williams , "H. Peter Anvin" Cc: Peter Zijlstra , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Fenghua Yu , Rick Edgecombe , x86@kernel.org, linux-kernel@vger.kernel.org, nvdimm@lists.linux.dev, linux-mm@kvack.org References: <20210804043231.2655537-1-ira.weiny@intel.com> <20210804043231.2655537-9-ira.weiny@intel.com> <20211113005051.GN3538886@iweiny-DESK2.sc.intel.com> From: Andy Lutomirski In-Reply-To: <20211113005051.GN3538886@iweiny-DESK2.sc.intel.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: A9CAB40005 X-Stat-Signature: 4ddud3bsb6tfbbqzjeb3fczkzsnsfbbw Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=rWxP8RrX; spf=pass (imf04.hostedemail.com: domain of luto@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=luto@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-HE-Tag: 1638494021-352924 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 11/12/21 16:50, Ira Weiny wrote: > On Tue, Aug 03, 2021 at 09:32:21PM -0700, 'Ira Weiny' wrote: >> From: Ira Weiny >> >> The PKRS MSR is not managed by XSAVE. It is preserved through a context >> switch but this support leaves exception handling code open to memory >> accesses during exceptions. >> >> 2 possible places for preserving this state were considered, >> irqentry_state_t or pt_regs.[1] pt_regs was much more complicated and >> was potentially fraught with unintended consequences.[2] However, Andy >> came up with a way to hide additional values on the stack which could be >> accessed as "extended_pt_regs".[3] > > Andy, > > I'm preparing to send V8 of this PKS work. But I have not seen any feed back > since I originally implemented this in V4[1]. > > Does this meets your expectations? Are there any issues you can see with this > code? I think I'm generally okay with the approach to allocating space. All of Thomas' comments still apply, though. (Sorry, I'm horribly behind.)