Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp872714pxj; Tue, 18 May 2021 16:29:18 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwZ4EasTAQkS+VrDaeFHUShUhTDyQ48GdeOkG4wDbWcmmkAdnEG7h8t2uZCxpNLAwX9wErq X-Received: by 2002:a05:6e02:1be8:: with SMTP id y8mr6955500ilv.52.1621380557861; Tue, 18 May 2021 16:29:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1621380557; cv=none; d=google.com; s=arc-20160816; b=KTPk2i68nDU8/gZ8c/7boRv9TWC2UoKkfTQoyocKhaeZZow4DhADODQ0VC9+C/zQ7H dlCAktmTLzeXK/N3AO4905ZOQ2Bv5rvfOxw3CFGiN0kpsG9LdLA2QWFlnh6Q8wCXxaGi MUWteMdEZTaH6BYjfc4i30hmg9D6K2iiG5ZIbbmfYn4FlAFqhpdhOgGfsHCW4Ff628I7 +dx7vpLQPtmMqLr9NtfU1PzXNcDrzaYtvcZySbtPXC0kMfS0k5ZKIhm4k8G04J/IeSNM NoJR6OADPCiRptKfBu55yHw4MGsIH6eJZzTL3aLCbaoE/BVysEPOSaLn0f2rwZJLkhml GWhw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=NsGr4mQGD2hjDVdRYUkjKAO890pGgLZTF6RGBYaeOA0=; b=ViytVk8wCG7dBL5fVdT8lIaWZwzRDc+lTQqb3vwEdKldPlwy1CgOIgLKbA1G0ruXVV BU4ZqvOEYthBTJ8/iMvnM55E4ORSCGmHwN8HGFUXkojVSXNQXgR1uZdKbefvfiM3vedV j1neddo/b75okraGUCvxAzYZjOuX0m/fJXydUtXEQLXz6VJymyi9Y2g9IjhAtCVwHJcJ V00KqL0+o0wIh3FK+3U8m6aE8nk8GuRSljxLYmPTIlcickW+MuQ8Flrek3NZZRjiuCBM GrcEGqdxuGDRgFgVo7h1RM5mHhnQMthu7sqP3g7pDUCr22rQzOK0CEjR5UFQc3X6wn9P ppPw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=VJ7RSqvQ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i17si2124641iog.70.2021.05.18.16.29.00; Tue, 18 May 2021 16:29:17 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=VJ7RSqvQ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238462AbhEQSQk (ORCPT + 99 others); Mon, 17 May 2021 14:16:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35354 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244069AbhEQSQg (ORCPT ); Mon, 17 May 2021 14:16:36 -0400 Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ECC72C061756 for ; Mon, 17 May 2021 11:15:19 -0700 (PDT) Received: by mail-ot1-x32b.google.com with SMTP id n32-20020a9d1ea30000b02902a53d6ad4bdso6371521otn.3 for ; Mon, 17 May 2021 11:15:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NsGr4mQGD2hjDVdRYUkjKAO890pGgLZTF6RGBYaeOA0=; b=VJ7RSqvQgDgYhQxXP4qtehv91Fl7mVi7hp3Yd1uGO1XsIDC8/vgE28mMLpq4MUSQFO Y/qMv00VsAx1d16W3GjxMLhWR9EWeZwd974xma/LV19e/7+0pd2xNMrl/GMB389OlNU9 eJySKBA1kR/z1EG/qS7wRfcNgFPKSFVD1ifGje/P6fDbud9dlxwVvCGH5gzbmfWMUfAk moIjILaG/qheIKOkY8CBLGBp1Lz/lRDo1m/obYxij44KvHJjHgCQ8Mda3BUwjTt9h22G gSU0Zj76BYXkyflnGbtYYr7hfFi7xDwyUSPtYpjTD4Rlnn0v4IAm5nyn6IV9oAlCaBA/ 8UKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NsGr4mQGD2hjDVdRYUkjKAO890pGgLZTF6RGBYaeOA0=; b=mwcCyigeMr7ttEraMU0zCtpxrce45dI62Wc1I3m+laHtKw+0+4GIEYoUVCj2HeQeKe /uLlq4X4MVdtJXkdCJ0Ue/LFtpeFQDoOPeT924DWAH0tWfuYn1QIBB47bJ4xow9zCDxO 7O6S+zojrhQBojCdyAlI+es6UwEUDOGUzMfaKtvc0Fz7eeq4Ck5LLQkhJlCKLVxv0hW6 K/hOt1xZnxxkdrwS8UWvNSOIcnH4O4h5alSKqaQrcaJC76jeZqsC8Hr8g7/hVWlcv67r IseF69X+6cflIcHvwM4jrchRi1vLkMWACQ2DxgVBzcEY/KXpvK9qQgDMDjf0VnXeP3PW DljQ== X-Gm-Message-State: AOAM530ReHOcVwwPhSdi5p7PKrADpJbdMRMsG8wVGiSiFwKjtT2zJPL9 yWrpFaCpg/4o3YILEUyqNg4DJ4tnrEMC5iHgW7xWmQ== X-Received: by 2002:a9d:131:: with SMTP id 46mr699009otu.241.1621275319019; Mon, 17 May 2021 11:15:19 -0700 (PDT) MIME-Version: 1.0 References: <20210507164456.1033-1-jon@nutanix.com> <5e01d18b-123c-b91f-c7b4-7ec583dd1ec6@redhat.com> <4e6f7056-6b66-46b9-9eac-922ae1c7b526@www.fastmail.com> <342a8ba9-037e-b841-f9b1-cb62e46c0db8@intel.com> In-Reply-To: From: Jim Mattson Date: Mon, 17 May 2021 11:15:07 -0700 Message-ID: Subject: Re: [PATCH] KVM: x86: add hint to skip hidden rdpkru under kvm_load_host_xsave_state To: Sean Christopherson Cc: Dave Hansen , Andy Lutomirski , Paolo Bonzini , Jon Kohler , Babu Moger , Thomas Gleixner , Ingo Molnar , "the arch/x86 maintainers" , "H. Peter Anvin" , Vitaly Kuznetsov , Wanpeng Li , 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 Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 17, 2021 at 11:05 AM Sean Christopherson wrote: > > On Mon, May 17, 2021, Dave Hansen wrote: > > On 5/17/21 10:49 AM, Andy Lutomirski wrote: > > >> The least awful solution would be to have the NMI handler restore > > >> the host's PKRU. The NMI handler would need to save/restore the > > >> register, a la CR2, but the whole thing could be optimized to run > > >> if and only if the NMI lands in the window where the guest's PKRU > > >> is loaded. > > > > > > Or set a flag causing nmi_uaccess_ok() to return false. > > > > Oh, that doesn't sound too bad. The VMENTER/EXIT paths are also > > essentially a context switch. > > I like that idea, too. > > The flag might also be useful to fix the issue where the NMI handler activates > PEBS after KVM disables it. Jim? The issue is actually that the NMI handler *clears* IA32_PEBS_ENABLE bits after giving out the host value of the MSR to KVM. If we were to block the NMI handler from modifying IA32_PEBS_ENABLE until after the next VM-exit, that could solve this issue. I don't know if it makes sense to piggyback on nmi_uaccess(), though. > > Will widening the window where nmi_uaccess_okay()==false anger any of > > the perf folks? It looks like perf knows how to handle it nicely.