From nobody Wed Apr 24 02:32:32 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; 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=fail(p=none dis=none) header.from=intel.com ARC-Seal: i=1; a=rsa-sha256; t=1592410812; cv=none; d=zohomail.com; s=zohoarc; b=PkoI8m9uVVCGyySPZ/0k/Ojsp6R8WvXFV/OwB3I4/zD60fblhfgo5QEzwMHrsmD+L6V2ramCDbDGRhIHuo/eKIl8WBoNP95FjnOB+AK7/HggiJ3WLvVxpMN0vTE6qwzcvRieg6rQRYOu1mXgYtuHXmK9of1UArLG3iUmn4vlHpA= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1592410812; h=Content-Transfer-Encoding:Cc:Date:From:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:Sender:Subject:To; bh=J+3vZD8sFb1t4vDPiLip8sHQBBA0qSRJVjkyTxRjB3g=; b=hCJtQtz4lp5pGfL2oXzJ4lFVf7dkL7Tzsja1oKn/+pCTngDlzpHVPqe37ZFb8uBEPh+Dj+1oeGKK3CnLM+s3pDCkzWtccEwAPb6OSfR1Fzd0yVYKtP02CFQLtH7OUhGb8SiIhWwBMnDLBP5z/Jhb8mfzenWXcrz9pRkJm1PUKxs= ARC-Authentication-Results: i=1; mx.zohomail.com; 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=fail header.from= (p=none 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 159241081244261.086440729052924; Wed, 17 Jun 2020 09:20:12 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1jlan5-0003zd-Ib; Wed, 17 Jun 2020 16:19:55 +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 1jlan5-0003zX-7u for xen-devel@lists.xenproject.org; Wed, 17 Jun 2020 16:19:55 +0000 Received: from mga02.intel.com (unknown [134.134.136.20]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id 601d0e12-b0b6-11ea-b9fe-12813bfff9fa; Wed, 17 Jun 2020 16:19:53 +0000 (UTC) Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Jun 2020 09:19:52 -0700 Received: from emagureg-mobl.amr.corp.intel.com (HELO ubuntu.localdomain) ([10.212.104.207]) by orsmga004.jf.intel.com with ESMTP; 17 Jun 2020 09:19:51 -0700 X-Inumbo-ID: 601d0e12-b0b6-11ea-b9fe-12813bfff9fa IronPort-SDR: Vz5BfJWgfi17m915PPDvWK3yczsOyPgcVYN6DLWChhEzX3OtlJjBhPZjv4ItZqfc4vr0bvVuR1 +39dA2vUCCZw== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False IronPort-SDR: 4stfDd3SQSjkxnWKfMGK/jTRCLh1RYTXqlkM0QY1yxxu3cNcG+1V/VOB9+E/PvxsMVrXfluH3N 2T+TvKmg31aQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,523,1583222400"; d="scan'208";a="421191345" From: Tamas K Lengyel To: xen-devel@lists.xenproject.org Subject: [PATCH v2 for-4.14] x86/vmx: use P2M_ALLOC in vmx_load_pdptrs instead of P2M_UNSHARE Date: Wed, 17 Jun 2020 09:19:49 -0700 Message-Id: <3555e16baa9e1909dbefaaab04330694135c9021.1592410065.git.tamas.lengyel@intel.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Kevin Tian , Tamas K Lengyel , Jun Nakajima , Wei Liu , Paul Durrant , Andrew Cooper , Jan Beulich , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" Content-Type: text/plain; charset="utf-8" While forking VMs running a small RTOS system (Zephyr) a Xen crash has been observed due to a mm-lock order violation while copying the HVM CPU context from the parent. This issue has been identified to be due to hap_update_paging_modes first getting a lock on the gfn using get_gfn. This call also creates a shared entry in the fork's memory map for the cr3 gfn. = The function later calls hap_update_cr3 while holding the paging_lock, which results in the lock-order violation in vmx_load_pdptrs when it tries to uns= hare the above entry when it grabs the page with the P2M_UNSHARE flag set. Since vmx_load_pdptrs only reads from the page its usage of P2M_UNSHARE was unnecessary to start with. Using P2M_ALLOC is the appropriate flag to ensure the p2m is properly populated and to avoid the lock-order violation we observed. Signed-off-by: Tamas K Lengyel --- v2: This patch was previously sent as "x86/hap: use get_gfn_type in hap_update_paging_modes" --- xen/arch/x86/hvm/vmx/vmx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c index ab19d9424e..cc6d4ece22 100644 --- a/xen/arch/x86/hvm/vmx/vmx.c +++ b/xen/arch/x86/hvm/vmx/vmx.c @@ -1325,7 +1325,7 @@ static void vmx_load_pdptrs(struct vcpu *v) if ( (cr3 & 0x1fUL) && !hvm_pcid_enabled(v) ) goto crash; =20 - page =3D get_page_from_gfn(v->domain, cr3 >> PAGE_SHIFT, &p2mt, P2M_UN= SHARE); + page =3D get_page_from_gfn(v->domain, cr3 >> PAGE_SHIFT, &p2mt, P2M_AL= LOC); if ( !page ) { /* Ideally you don't want to crash but rather go into a wait=20 --=20 2.25.1