From nobody Thu Apr 18 10:33:38 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=reject dis=none) header.from=citrix.com ARC-Seal: i=1; a=rsa-sha256; t=1619734404; cv=none; d=zohomail.com; s=zohoarc; b=J4CMnl7oG7bLLPggM0Dl7G5ylzGC7fEq/TGvC7divUWx0k31NqdaF+dDP0g2E9ZnGyQNVXiVq+doySVwQHCIlM4cS0GqbwHh8qWQiXJ1vN7bej+tTD/487PFnmDCD0Vw8W7TED2ZTORqonFguFT1icQ9R0BoKOpslVeoi/1Q6LY= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1619734404; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:Sender:Subject:To; bh=4ZYkcS4yTe6LoDfg0fo5IG86fel1rcsyhYqVFXRdndM=; b=GCx4iXqpdrZo7rRdx1mAGnvUZmAsr7AnU6CIqm9iPuJ+LIyEu7cnZmR2ttiTgWS5gZaB+GDABBGb12ZVIdjZRSS9xfBvF/YzJwOpJCMFKG5BvmmvJnnM/mUWxh6Jqn3GZO26IYB4UjAij4NFw66JE4gWIaV/w9AAT9PCxjr5aLA= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=reject dis=none) header.from= Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1619734404850873.8814679250876; Thu, 29 Apr 2021 15:13:24 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.120233.227386 (Exim 4.92) (envelope-from ) id 1lcEtv-000050-NB; Thu, 29 Apr 2021 22:12:51 +0000 Received: by outflank-mailman (output) from mailman id 120233.227386; Thu, 29 Apr 2021 22:12:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lcEtv-0008WV-Iv; Thu, 29 Apr 2021 22:12:51 +0000 Received: by outflank-mailman (input) for mailman id 120233; Thu, 29 Apr 2021 22:12:50 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lcEtu-0008WQ-4o for xen-devel@lists.xenproject.org; Thu, 29 Apr 2021 22:12:50 +0000 Received: from esa1.hc3370-68.iphmx.com (unknown [216.71.145.142]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id caae0817-419e-4722-b369-0ded4c7450b7; Thu, 29 Apr 2021 22:12:49 +0000 (UTC) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: caae0817-419e-4722-b369-0ded4c7450b7 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=citrix.com; s=securemail; t=1619734368; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=6LIVk1pu2pVsc+iERPoTgLfY8nG1QD9FVQ87ifPWYHo=; b=RxuM4n2OiI1FMye5NOmhKXCTV23hbyIHfVnzmGv1K1greOSP9lt7fC2b VfoNYmDiPcFVvkxwP+ayty2GqBLMHHeIP8bZG+rPEwvROHSEKgLoT285b RR2tCL5+uzYoCghMhGLEJxpDADgLQV4ahCllXduXPPJ59UkwtnNium1uV 4=; Authentication-Results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none IronPort-SDR: IFIfkzFNoIJ4cTvJ7RzIFSG6EjLriEUUXmHXlgAXR6ew1XlhUEDfeW/6/nfMGXLpxd4NhX4/zQ pxgeMfqzOFRK/EDQAaNuNYF1EdDkJC+RcRfsRJypW/FSS/pOTGGk72KWiT4hGJ2OFs/gGUYWh6 NcAzb4LF4T4WQ6EDExDVuVQ4QCmtC4K/UJDyGV9FAMpeyTqmLQ2jG8e6pZU3SEsPMz9iMi5v/n Jt8c1d5KYipsV8ZA0DJ2gmJkOpjV1Cj795a1MS+oCUXrbuEMBEgr++AeCPw5yKwVE94/Hji9ES jVo= X-SBRS: 5.1 X-MesageID: 43139989 X-Ironport-Server: esa1.hc3370-68.iphmx.com X-Remote-IP: 162.221.158.21 X-Policy: $RELAYED IronPort-HdrOrdr: A9a23:ECStNqt6bsNDIAdzSLcGyZl+7skDktV00zAX/kB9WHVpW+az/v rBoN0w0xjohDENHEw6kdebN6WaBV/a/5h54Y4eVI3SOzXOkm2uMY1k8M/e0yTtcheOktJ1+K 98f8FFaOHYIkN9ia/BjDWQN/YF7J25/LuzheHYpk0dKD1CT6179Q92BkK6PyRNNWp7LKE0Hp ad+cZLzgDIER98A/iTPXUZQ/PF4+TCiZOOW29hOzcc9AKMgTm0gYSaLzGk2H4lPA9n8PMH+W jBnxeR3NTAj82G X-IronPort-AV: E=Sophos;i="5.82,260,1613451600"; d="scan'208";a="43139989" From: Andrew Cooper To: Xen-devel CC: Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Wei Liu Subject: [PATCH] x86: Always have CR4.PKE set in HVM context Date: Thu, 29 Apr 2021 23:12:23 +0100 Message-ID: <20210429221223.28348-1-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.11.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @citrix.com) The sole user of read_pkru() is the emulated pagewalk, and guarded behind guest_pku_enabled() which restricts the path to HVM (hap, even) context onl= y. The commentary in read_pkru() concerning _PAGE_GNTTAB overlapping with _PAGE_PKEY_BITS is only applicable to PV guests. The context switch path, via write_ptbase() unconditionally writes CR4 on a= ny context switch. Therefore, we can guarantee to separate CR4.PKE between PV and HVM context = at no extra cost. Set PKE in mmu_cr4_features on boot, so it becomes set in H= VM context, and clear it in pv_make_cr4(). Rename read_pkru() to rdpkru() now that it is a simple wrapper around the instruction. This saves two CR4 writes on every pagewalk, which typically occur more than one per emulation. Signed-off-by: Andrew Cooper Reviewed-by: Jan Beulich --- CC: Jan Beulich CC: Roger Pau Monn=C3=A9 CC: Wei Liu It also occurs to me that for HVM/Idle =3D> HVM/Idle context switches, we n= ever need to change CR4. I think this is substantially clearer following XSA-29= 3 / c/s b2dd00574a4f ("x86/pv: Rewrite guest %cr4 handling from scratch") which introduced pv_make_cr4(). Therefore, it is probably work having a hvm fastpath path in write_ptbase() which only touches CR3. --- xen/arch/x86/mm/guest_walk.c | 2 +- xen/arch/x86/pv/domain.c | 16 +++++++++++++++- xen/arch/x86/setup.c | 3 +++ xen/include/asm-x86/processor.h | 10 +--------- 4 files changed, 20 insertions(+), 11 deletions(-) diff --git a/xen/arch/x86/mm/guest_walk.c b/xen/arch/x86/mm/guest_walk.c index 1c601314f3..30d83cf1e0 100644 --- a/xen/arch/x86/mm/guest_walk.c +++ b/xen/arch/x86/mm/guest_walk.c @@ -416,7 +416,7 @@ guest_walk_tables(const struct vcpu *v, struct p2m_doma= in *p2m, guest_pku_enabled(v) ) { unsigned int pkey =3D guest_l1e_get_pkey(gw->l1e); - unsigned int pkru =3D read_pkru(); + unsigned int pkru =3D rdpkru(); =20 if ( read_pkru_ad(pkru, pkey) || ((walk & PFEC_write_access) && read_pkru_wd(pkru, pkey) && diff --git a/xen/arch/x86/pv/domain.c b/xen/arch/x86/pv/domain.c index f1cb92585e..731a262a2b 100644 --- a/xen/arch/x86/pv/domain.c +++ b/xen/arch/x86/pv/domain.c @@ -182,7 +182,21 @@ unsigned long pv_make_cr4(const struct vcpu *v) { const struct domain *d =3D v->domain; unsigned long cr4 =3D mmu_cr4_features & - ~(X86_CR4_PCIDE | X86_CR4_PGE | X86_CR4_TSD); + ~(X86_CR4_PCIDE | X86_CR4_PGE | X86_CR4_TSD | X86_CR4_PKE); + + /* + * We want CR4.PKE set in HVM context when avaialble, but don't suppor= t it + * in PV context at all. + * + * _PAGE_PKEY_BITS where previously software available PTE bits. In + * principle, we could let an aware PV guest enable PKE. + * + * However, Xen uses _PAGE_GNTTAB in debug builds which overlaps with + * _PAGE_PKEY_BITS, and the ownership of (and eligibility to move) + * software PTE bits is not considered in the PV ABI at all. For now, + * punt the problem to whichever unluckly person finds a compelling + * usecase for PKRU in PV guests. + */ =20 /* * PCIDE or PGE depends on the PCID/XPTI settings, but must not both be diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c index f2dff2ae6a..8105dc36bb 100644 --- a/xen/arch/x86/setup.c +++ b/xen/arch/x86/setup.c @@ -1790,6 +1790,9 @@ void __init noreturn __start_xen(unsigned long mbi_p) if ( boot_cpu_has(X86_FEATURE_FSGSBASE) ) set_in_cr4(X86_CR4_FSGSBASE); =20 + if ( boot_cpu_has(X86_FEATURE_PKU) ) + set_in_cr4(X86_CR4_PKE); + if ( opt_invpcid && cpu_has_invpcid ) use_invpcid =3D true; =20 diff --git a/xen/include/asm-x86/processor.h b/xen/include/asm-x86/processo= r.h index d5f467d245..d8d0dc8034 100644 --- a/xen/include/asm-x86/processor.h +++ b/xen/include/asm-x86/processor.h @@ -367,20 +367,12 @@ static always_inline void set_in_cr4 (unsigned long m= ask) write_cr4(read_cr4() | mask); } =20 -static inline unsigned int read_pkru(void) +static inline unsigned int rdpkru(void) { unsigned int pkru; - unsigned long cr4 =3D read_cr4(); =20 - /* - * _PAGE_PKEY_BITS have a conflict with _PAGE_GNTTAB used by PV guests, - * so that X86_CR4_PKE is disabled on hypervisor. To use RDPKRU, CR4.= PKE - * gets temporarily enabled. - */ - write_cr4(cr4 | X86_CR4_PKE); asm volatile (".byte 0x0f,0x01,0xee" : "=3Da" (pkru) : "c" (0) : "dx"); - write_cr4(cr4); =20 return pkru; } --=20 2.11.0