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=-6.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 6289FC433ED for ; Wed, 19 May 2021 23:15:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2EA106139A for ; Wed, 19 May 2021 23:15:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229898AbhESXRF (ORCPT ); Wed, 19 May 2021 19:17:05 -0400 Received: from mail.kernel.org ([198.145.29.99]:42690 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229465AbhESXRE (ORCPT ); Wed, 19 May 2021 19:17:04 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 6B10F61073; Wed, 19 May 2021 23:15:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1621466143; bh=beE4/t2PXKApA1HIKdMVG9OOGAVvsn53W5079fVxQ/0=; h=In-Reply-To:References:Date:From:To:Cc:Subject:From; b=XLozLhVPQv/6woT+UnfzEZrnec0PUe+d6LxgEbl2gcjIkECwfIQsIq2XseOagWUYg n54mHH7QANRtQVpvW+joEulDL3hR0UJcJ1B7KXtaCCFHlHI8pB9jRrUNebaSvE3ReV HDFYG9SRQM6RkdeP1hxJoyv6tNLhxgNrHCe2pcPeg89KEBEyV4fwYxnkAmB+LTuTgo p3BKwJTv5gA3jp4LdK2HzB5M+Ls47btJIFIPw35Xz3rsL23lgmwh383uO1Lg3w98HP Ls8poELkNPu5u6MXKyrLKc3AZGYbuDFAaC/YO/JUHRg3OCwfYjYCRsiulV9Bs0ibaf 8jfFd+AjQkCRQ== Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailauth.nyi.internal (Postfix) with ESMTP id 72A8927C007C; Wed, 19 May 2021 19:15:40 -0400 (EDT) Received: from imap21 ([10.202.2.71]) by compute2.internal (MEProxy); Wed, 19 May 2021 19:15:40 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdejtddgvddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgfgsehtqhertderreejnecuhfhrohhmpedftehn ugihucfnuhhtohhmihhrshhkihdfuceolhhuthhosehkvghrnhgvlhdrohhrgheqnecugg ftrfgrthhtvghrnhepvdelheejjeevhfdutdeggefftdejtdffgeevteehvdfgjeeiveei ueefveeuvdetnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homheprghnugihodhmvghsmhhtphgruhhthhhpvghrshhonhgrlhhithihqdduudeiudek heeifedvqddvieefudeiiedtkedqlhhuthhopeepkhgvrhhnvghlrdhorhhgsehlihhnuh igrdhluhhtohdruhhs X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 2219051C0060; Wed, 19 May 2021 19:15:37 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-448-gae190416c7-fm-20210505.004-gae190416 Mime-Version: 1.0 Message-Id: In-Reply-To: <8e45611c-f6ce-763a-ad17-adada33716d6@intel.com> References: <20210507164456.1033-1-jon@nutanix.com> <5e01d18b-123c-b91f-c7b4-7ec583dd1ec6@redhat.com> <8e45611c-f6ce-763a-ad17-adada33716d6@intel.com> Date: Wed, 19 May 2021 16:15:16 -0700 From: "Andy Lutomirski" To: "Dave Hansen" , "Paolo Bonzini" , "Jon Kohler" , "Sean Christopherson" Cc: "Babu Moger" , "the arch/x86 maintainers" , "H. Peter Anvin" , "Vitaly Kuznetsov" , "Wanpeng Li" , "Jim Mattson" , "Joerg Roedel" , "Fenghua Yu" , "Yu-cheng Yu" , "Tony Luck" , "Uros Bizjak" , "Petteri Aimonen" , "Kan Liang" , "Andrew Morton" , "Mike Rapoport" , "Benjamin Thiel" , "Fan Yang" , "Juergen Gross" , "Dave Jiang" , "Peter Zijlstra (Intel)" , "Ricardo Neri" , "Arvind Sankar" , "Linux Kernel Mailing List" , "kvm list" Subject: =?UTF-8?Q?Re:_[PATCH]_KVM:_x86:_add_hint_to_skip_hidden_rdpkru_under_kvm?= =?UTF-8?Q?=5Fload=5Fhost=5Fxsave=5Fstate?= Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Wed, May 19, 2021, at 3:44 PM, Dave Hansen wrote: > On 5/17/21 12:46 AM, Paolo Bonzini wrote: > > On 14/05/21 07:11, Andy Lutomirski wrote: > >> That's nice, but it fails to restore XINUSE[PKRU].=C2=A0 As far as = I know, > >> that bit is live, and the only way to restore it to 0 is with > >> XRSTOR(S). > >=20 > > The manual says "It is possible for XINUSE[i] to be 1 even when stat= e > > component i is in its initial configuration" so this is architectura= lly > > valid.=C2=A0 Does the XINUSE optimization matter for PKRU which is a= single > > word? >=20 > In Linux with normal userspace, virtually never. >=20 > The hardware defaults PKRU to 0x0 which means "no restrictions on any > keys". Linux defaults PKRU via 'init_pkru_value' to the most > restrictive value. This ensures that new non-zero-pkey-assigned memor= y > is protected by default. >=20 > But, that also means PKRU is virtually never in its init state in Linu= x. > An app would probably need to manipulate PKRU with XRSTOR to get > XINUSE[PKRU]=3D0. >=20 > It would only even *possibly* be useful if running a KVM guest that ha= d > PKRU=3D0x0 (sorry I don't consider things using KVM "normal userspace"= :P ). >=20 There was at least one report from the rr camp of glibc behaving differe= ntly depending on the result of XGETBV(1). It's at least impolite to ch= ange the XINUSE register for a guest behind its back. Admittedly that particular report wasn't about PKRU, and *Linux* guests = won't run with XINUSE[PKRU]=3D0 under normal circumstances, but non-Linu= x guests could certainly do so.