From patchwork Tue Jul 25 15:00:13 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Cooper X-Patchwork-Id: 9862185 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 0BAE5601A1 for ; Tue, 25 Jul 2017 15:02:31 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id F2746286BB for ; Tue, 25 Jul 2017 15:02:30 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id E7451286C2; Tue, 25 Jul 2017 15:02:30 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 51E78286CC for ; Tue, 25 Jul 2017 15:02:30 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1da1Js-00030L-2w; Tue, 25 Jul 2017 15:00:20 +0000 Received: from mail6.bemta6.messagelabs.com ([193.109.254.103]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1da1Jq-00030F-Tn for xen-devel@lists.xen.org; Tue, 25 Jul 2017 15:00:19 +0000 Received: from [85.158.143.35] by server-8.bemta-6.messagelabs.com id CB/85-09901-20D57795; Tue, 25 Jul 2017 15:00:18 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRWlGSWpSXmKPExsXitHRDpC5jbHm kwa2nBhZLPi5mcWD0OLr7N1MAYxRrZl5SfkUCa8a1Sf0sBZP4K8483c3UwDiFp4uRg0NCwF/i ZHNZFyMnB5uAvsTuF5+YQGwRAXWJ0x0XWbsYuTiYBbYxShx7PJMVJCEskCRxrLWRGcRmEVCV+ L5rPlicV8BD4uf6uSwgtoSAnMT54z/BaoQE1CSu9V9ih6gRlDg58wlYDbOAhMTBFy+YJzByz0 KSmoUktYCRaRWjRnFqUVlqka6xgV5SUWZ6RkluYmaOrqGBmV5uanFxYnpqTmJSsV5yfu4mRmA wMADBDsa/awMPMUpyMCmJ8n7TLY8U4kvKT6nMSCzOiC8qzUktPsQow8GhJMG7ORooJ1iUmp5a kZaZAwxLmLQEB4+SCK9TDFCat7ggMbc4Mx0idYpRl+PVhP/fmIRY8vLzUqXEef+DzBAAKcooz YMbAYuRS4yyUsK8jEBHCfEUpBblZpagyr9iFOdgVBLmnQUyhSczrwRu0yugI5iAjpgzoxTkiJ JEhJRUA6N2fG5ef//SBRNLI75+Xd7PfezMjJM3dWr6Mhs0b8iHxvEXl/t4r3pRuEqkrDffX/f C18M/vnL3yvVn31qfPbEwO15s2+NUm0mKX3xDU9pPCPDtYJEOuHOv+bPJxNxVVlWbnx9J+TL/ QCHLPQnRyRbc3NF7+znLjZZwL1JtSjtUK+ctWSmSqsRSnJFoqMVcVJwIAMniLaKMAgAA X-Env-Sender: prvs=3721034a5=Andrew.Cooper3@citrix.com X-Msg-Ref: server-8.tower-21.messagelabs.com!1500994816!74763313!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 9.4.25; banners=-,-,- X-VirusChecked: Checked Received: (qmail 41283 invoked from network); 25 Jul 2017 15:00:17 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-8.tower-21.messagelabs.com with RC4-SHA encrypted SMTP; 25 Jul 2017 15:00:17 -0000 X-IronPort-AV: E=Sophos;i="5.40,411,1496102400"; d="scan'208";a="432884800" From: Andrew Cooper To: Xen-devel Date: Tue, 25 Jul 2017 16:00:13 +0100 Message-ID: <1500994813-8407-1-git-send-email-andrew.cooper3@citrix.com> X-Mailer: git-send-email 2.1.4 MIME-Version: 1.0 Cc: George Dunlap , Andrew Cooper , Tim Deegan , Wei Liu , Jan Beulich Subject: [Xen-devel] [PATCH] x86/pagewalk: Remove opt_allow_superpage check from guest_can_use_l2_superpages() X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" X-Virus-Scanned: ClamAV using ClamSMTP The purpose of guest_walk_tables() is to match the behaviour of real hardware. A PV guest can have 2M superpages in its pagetables, via the M2P and the initial initrd mapping, even if it isn't permitted to create arbitrary 2M superpage mappings. guest_can_use_l2_superpages() checking opt_allow_superpage is a piece of PV guest policy enforcement, rather than its intended purpose of meaning "would hardware tolerate finding an L2 superpage with these control settings?" Signed-off-by: Andrew Cooper Reviewed-by: Tim Deegan Reviewed-by: Wei Liu --- CC: Jan Beulich CC: Tim Deegan CC: George Dunlap CC: Wei Liu --- xen/include/asm-x86/guest_pt.h | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/xen/include/asm-x86/guest_pt.h b/xen/include/asm-x86/guest_pt.h index 72126d5..08031c8 100644 --- a/xen/include/asm-x86/guest_pt.h +++ b/xen/include/asm-x86/guest_pt.h @@ -205,15 +205,17 @@ static inline guest_l4e_t guest_l4e_from_gfn(gfn_t gfn, u32 flags) static inline bool guest_can_use_l2_superpages(const struct vcpu *v) { /* + * PV guests use Xen's paging settings. Being 4-level, 2M + * superpages are unconditionally supported. + * * The L2 _PAGE_PSE bit must be honoured in HVM guests, whenever * CR4.PSE is set or the guest is in PAE or long mode. * It's also used in the dummy PT for vcpus with CR0.PG cleared. */ - return (is_pv_vcpu(v) - ? opt_allow_superpage - : (GUEST_PAGING_LEVELS != 2 - || !hvm_paging_enabled(v) - || (v->arch.hvm_vcpu.guest_cr[4] & X86_CR4_PSE))); + return (is_pv_vcpu(v) || + GUEST_PAGING_LEVELS != 2 || + !hvm_paging_enabled(v) || + (v->arch.hvm_vcpu.guest_cr[4] & X86_CR4_PSE)); } static inline bool guest_can_use_l3_superpages(const struct domain *d)