From patchwork Fri Feb 7 03:07:39 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yan Zhao X-Patchwork-Id: 13964271 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DBAC22030A; Fri, 7 Feb 2025 03:08:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.19 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1738897731; cv=none; b=Aalw9FRkoAS9fPTA0JIWmE8MrGgBTH+Vbp15VI/Kzb/vfiuE1fGwV7ZB5tmyixP6UtuVbNVM79n2AED4vc6b5MHxO12JpuG5OVqaRg/YZv1ditsh/O0uZxQ1yLWiZJJz4VdgnMdU189nKO5Gi8IDA6bv7QlLh2yHxq82mtoougo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1738897731; c=relaxed/simple; bh=Ma0iUnI2I6xNU2wk15KlDXjmVcchazEHZ4Ci9uaRTeA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=PB/AkG3dwn7IjQt2O+gZPeW1VbmlJvDZ7y2wMXshdV9MAH51CHuWvqvMRlqUcnZuV+XpN9rVrrFtHm41jHK0nLbmdj8vZ/cQbB+u+6XbPxu2ZufzBIakB+S0OOHHl0A2TUgjmhETd1w+m10LNnyMSakoOAP8GlyllFvhAWISqsg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=C7SSZFGR; arc=none smtp.client-ip=198.175.65.19 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="C7SSZFGR" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1738897729; x=1770433729; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=Ma0iUnI2I6xNU2wk15KlDXjmVcchazEHZ4Ci9uaRTeA=; b=C7SSZFGRzMg37GZxF34w3xYQwQW0pzIhZWwKSBAboTvSAFsA4XDO1S9c 4/BeenaFJf+7YOMRpNWycUzdZ7PncmrlcB/e4AihClu2/fxZrRr8wsskV x6+D+MyOnZF7Ol0+DEoeYccg5w5PT/xYiTR7KtwcgdbWJwzH47jfvbxOa f86O3kSiXCri5pTfZyywusYG0Yy4LMmyTBsypvqYoYjHwQU1+SI3Qd25H AmroBpX+p752XlkTuD0NuFZTyo/iIStmYmdjKE9oWju3QkTsPIIsp9U/M ImBEuAcQGYoHqffvpdPBpa1upCS3iRTwgRH/GRmwJo3qg/znXWyLdKFxi A==; X-CSE-ConnectionGUID: Y2LETPkoTQG5Gzu98MtkPw== X-CSE-MsgGUID: CWD3qi6EQUOr/Fd0T2uPcQ== X-IronPort-AV: E=McAfee;i="6700,10204,11336"; a="39403733" X-IronPort-AV: E=Sophos;i="6.13,266,1732608000"; d="scan'208";a="39403733" Received: from fmviesa008.fm.intel.com ([10.60.135.148]) by orvoesa111.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Feb 2025 19:08:49 -0800 X-CSE-ConnectionGUID: 3xZpZYe6QF2HCn1nTXXlRA== X-CSE-MsgGUID: SmmRfWEARLSuyRNP3DEEVA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.13,266,1732608000"; d="scan'208";a="111597378" Received: from yzhao56-desk.sh.intel.com ([10.239.159.62]) by fmviesa008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Feb 2025 19:08:46 -0800 From: Yan Zhao To: pbonzini@redhat.com, seanjc@google.com Cc: rick.p.edgecombe@intel.com, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Yan Zhao Subject: [PATCH 1/4] KVM: x86/mmu: Further check old SPTE is leaf for spurious prefetch fault Date: Fri, 7 Feb 2025 11:07:39 +0800 Message-ID: <20250207030739.1649-1-yan.y.zhao@intel.com> X-Mailer: git-send-email 2.43.2 In-Reply-To: <20250207030640.1585-1-yan.y.zhao@intel.com> References: <20250207030640.1585-1-yan.y.zhao@intel.com> Precedence: bulk X-Mailing-List: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Instead of simply treating a prefetch fault as spurious when there's a shadow-present old SPTE, further check if the old SPTE is leaf to determine if a prefetch fault is spurious. It's not reasonable to treat a prefetch fault as spurious when there's a shadow-present non-leaf SPTE while without a shadow-present leaf SPTE. e.g., with below sequence, a prefetch fault should not be regarded as spurious: 1. add a memslot with size 4K 2. prefault GPA A in the memslot 3. delete the memslot (zap all disabled) 4. re-add the memslot with size 2M 5. prefault GPA A again. In step 5, the prefetch fault attempts to install a 2M huge entry. Since step 3 zaps the leaf SPTE for GPA A while keeping the non-leaf SPTE, the leaf entry will remain empty after step 5 if the prefetch fault is regarded as spurious due to a shadow-present non-leaf SPTE found. Signed-off-by: Yan Zhao --- arch/x86/kvm/mmu/mmu.c | 2 +- arch/x86/kvm/mmu/tdp_mmu.c | 3 ++- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c index a45ae60e84ab..3d74e680006f 100644 --- a/arch/x86/kvm/mmu/mmu.c +++ b/arch/x86/kvm/mmu/mmu.c @@ -2846,7 +2846,7 @@ static int mmu_set_spte(struct kvm_vcpu *vcpu, struct kvm_memory_slot *slot, } if (is_shadow_present_pte(*sptep)) { - if (prefetch) + if (prefetch && is_last_spte(*sptep, level)) return RET_PF_SPURIOUS; /* diff --git a/arch/x86/kvm/mmu/tdp_mmu.c b/arch/x86/kvm/mmu/tdp_mmu.c index 046b6ba31197..ab65fd915ef2 100644 --- a/arch/x86/kvm/mmu/tdp_mmu.c +++ b/arch/x86/kvm/mmu/tdp_mmu.c @@ -1137,7 +1137,8 @@ static int tdp_mmu_map_handle_target_level(struct kvm_vcpu *vcpu, if (WARN_ON_ONCE(sp->role.level != fault->goal_level)) return RET_PF_RETRY; - if (fault->prefetch && is_shadow_present_pte(iter->old_spte)) + if (fault->prefetch && is_shadow_present_pte(iter->old_spte) && + is_last_spte(iter->old_spte, iter->level)) return RET_PF_SPURIOUS; if (is_shadow_present_pte(iter->old_spte) && From patchwork Fri Feb 7 03:08:10 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yan Zhao X-Patchwork-Id: 13964272 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0020E1531F0; Fri, 7 Feb 2025 03:09:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.16 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1738897760; cv=none; b=jf8zl7Qj+s9yJa5u1RjDVMYsDeFaZP8a9eF7mkgSdFyTYzEAqdcsNodCsBDaDTH5PegAMU7rT1BK+hyM6mvcztpbryt/+wo9cpE6E3+Q1KvaUOg3o9W1awmOnOMDeCFRsoHhbXiiR3ER1i4DdYPUNA4nPc3lxsw6o56Y3GNv98I= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1738897760; c=relaxed/simple; bh=eBRGEhcdw/cf/u9D7E5Qd78kS3bvzu14Dn7vtFCO7B8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=UA4pXgJ+usMoLuJ+HcG97oQX7kzIoN8rXun8X3y9Y2MRxKPmJ19jfHUvFg+ePLVw8jFwga/4hdlHPhlZ6N29eIm3vHBHW6EYozhRMgQEzKEre/oY8w7iTZOpAS8u8bD+uhAjkBC4j7hshGOpI0Ev6AkYd8/+o0Cxh+iZWgKumEE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=fJcrYHNa; arc=none smtp.client-ip=198.175.65.16 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="fJcrYHNa" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1738897759; x=1770433759; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=eBRGEhcdw/cf/u9D7E5Qd78kS3bvzu14Dn7vtFCO7B8=; b=fJcrYHNazwX/NtJ6Qd1sHvmGM7aHVjYpYCmudHIBmN4QZrvo3eKcT1yr Y1+91vWnaSvExhXMnAgu84e9ynSOZx6yJiXUR87u3tjFrAT4hn+MZtiDJ aA2nkzR9+erG72n2V2jy14T0XmVLka9Wt7S4qTFomyHamD0tq+ZBvpSM8 4uf9DATWopiwkXVe7nv3W0hdVd5ctO7F8w512Az5bpsckEhoo2ZQUpGY2 VOv31eS3sDjDtR+tEVH7ajiVI/SmISmgxZzHIuxMw1mNKialIynpaZ/HB HzDex77Cy2VQGl6ULCmxX+K+O4/ZXDreKSwNGAeXUb4tsDU76hs+Eg60T g==; X-CSE-ConnectionGUID: T6LSMwmMRkidlq1TzNVtrw== X-CSE-MsgGUID: qeCAllo5RxKDvm5Xhfj6OQ== X-IronPort-AV: E=McAfee;i="6700,10204,11336"; a="39661950" X-IronPort-AV: E=Sophos;i="6.13,266,1732608000"; d="scan'208";a="39661950" Received: from fmviesa006.fm.intel.com ([10.60.135.146]) by orvoesa108.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Feb 2025 19:09:17 -0800 X-CSE-ConnectionGUID: bnxXoa18SyClkM7XdNtKMg== X-CSE-MsgGUID: GAyigAiXSuyzI4DurW6PyA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.13,266,1732608000"; d="scan'208";a="111237608" Received: from yzhao56-desk.sh.intel.com ([10.239.159.62]) by fmviesa006-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Feb 2025 19:09:15 -0800 From: Yan Zhao To: pbonzini@redhat.com, seanjc@google.com Cc: rick.p.edgecombe@intel.com, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Yan Zhao Subject: [PATCH 2/4] KVM: x86/tdp_mmu: Merge the prefetch into the is_access_allowed() check Date: Fri, 7 Feb 2025 11:08:10 +0800 Message-ID: <20250207030810.1701-1-yan.y.zhao@intel.com> X-Mailer: git-send-email 2.43.2 In-Reply-To: <20250207030640.1585-1-yan.y.zhao@intel.com> References: <20250207030640.1585-1-yan.y.zhao@intel.com> Precedence: bulk X-Mailing-List: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Merge the prefetch check into the is_access_allowed() check to determine a spurious fault. In the TDP MMU, a spurious prefetch fault should also pass the is_access_allowed() check. Combining these checks to avoid redundancy. Signed-off-by: Yan Zhao --- arch/x86/kvm/mmu/tdp_mmu.c | 4 ---- 1 file changed, 4 deletions(-) diff --git a/arch/x86/kvm/mmu/tdp_mmu.c b/arch/x86/kvm/mmu/tdp_mmu.c index ab65fd915ef2..5f9e7374220e 100644 --- a/arch/x86/kvm/mmu/tdp_mmu.c +++ b/arch/x86/kvm/mmu/tdp_mmu.c @@ -1137,10 +1137,6 @@ static int tdp_mmu_map_handle_target_level(struct kvm_vcpu *vcpu, if (WARN_ON_ONCE(sp->role.level != fault->goal_level)) return RET_PF_RETRY; - if (fault->prefetch && is_shadow_present_pte(iter->old_spte) && - is_last_spte(iter->old_spte, iter->level)) - return RET_PF_SPURIOUS; - if (is_shadow_present_pte(iter->old_spte) && is_access_allowed(fault, iter->old_spte) && is_last_spte(iter->old_spte, iter->level)) From patchwork Fri Feb 7 03:09:00 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yan Zhao X-Patchwork-Id: 13964279 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F10381624C5; Fri, 7 Feb 2025 03:10:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.19 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1738897814; cv=none; b=Am5Ek7BIJNSy9LSy8SEjvovyNd60gW9r8S97vpk6WPvRjDFxl30uGHZ0RL/+/6bKSisHZCTtv2IZGHPozTelug5aIomrzw2qEbW6F4cltJp7VAePmAOLzO0KP5xwYuyazF3UEGtG6YgM4fG150PXv3nzjVCiCRHqT7amEEPlo14= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1738897814; c=relaxed/simple; bh=HEjW7p9mYif0anOP9XOUbSqHykMLvVgQ2FWDqLTVVDU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=cZ9qAbOLM7a/mzA9uLfn9zRDQlh7ne96ga7EiaH/E7EncfhFrYkCeAnPmIT7TCrn9Fg9KTjH9l02+ixBpYcVaanwv4xaiBPqnTyaazZWZbl4q4S71UBd+4Ke1BU8U/Oh92mKjajVTprhQESHwMvU0hoWO03zKplVW7TXRPfDgiU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=Ho0Mvoof; arc=none smtp.client-ip=192.198.163.19 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="Ho0Mvoof" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1738897813; x=1770433813; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=HEjW7p9mYif0anOP9XOUbSqHykMLvVgQ2FWDqLTVVDU=; b=Ho0MvoofxEWygBbtfhBxvsSc2d7qtw8qJwesItMgmoJ+MuD+al62VeDa PFdEg/TyWceJnxFhAW79w0FzVTApmxXv3H176yVwp3wbxctdE3DfIYn9R JDkyFoBPw0vIRWlUJG+4915GJ2R/NIca/wFg8wZ+LLMwW+iJYYv2qRdXg XYdrpsp0SFAAWza45kUudbsPZlzND4+3c43N5rxf2rO36+FZkxrbTrH3R DEV+TSRjblYDB2Fg1D1R71N/V6YPCmNCJTrs7Wa3PDc/VE4Tqg31TIM1/ MK28b4u391/hPH7ZICzYJY182tGlRrIBFdP8LSQr2M8JpsPQuXaAqILdu Q==; X-CSE-ConnectionGUID: d11pezsvQgmEgjpPaOo67g== X-CSE-MsgGUID: oB3Of98kT0C8U/SxtOiUxg== X-IronPort-AV: E=McAfee;i="6700,10204,11336"; a="38731403" X-IronPort-AV: E=Sophos;i="6.13,266,1732608000"; d="scan'208";a="38731403" Received: from orviesa004.jf.intel.com ([10.64.159.144]) by fmvoesa113.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Feb 2025 19:10:12 -0800 X-CSE-ConnectionGUID: DxVbil/NQYGzhRcuQ80jXA== X-CSE-MsgGUID: Uy2YKcudSs65ART/GtG7IQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.13,266,1732608000"; d="scan'208";a="116412063" Received: from yzhao56-desk.sh.intel.com ([10.239.159.62]) by orviesa004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Feb 2025 19:10:08 -0800 From: Yan Zhao To: pbonzini@redhat.com, seanjc@google.com Cc: rick.p.edgecombe@intel.com, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Yan Zhao Subject: [PATCH 3/4] KVM: x86/mmu: Make sure pfn is not changed for spurious fault Date: Fri, 7 Feb 2025 11:09:00 +0800 Message-ID: <20250207030900.1808-1-yan.y.zhao@intel.com> X-Mailer: git-send-email 2.43.2 In-Reply-To: <20250207030640.1585-1-yan.y.zhao@intel.com> References: <20250207030640.1585-1-yan.y.zhao@intel.com> Precedence: bulk X-Mailing-List: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Make sure pfn is not changed for a spurious fault by warning in the TDP MMU. For shadow path, only treat a prefetch fault as spurious when pfn is not changed, since the rmap removal and add are required when pfn is changed. Cc: Sean Christopherson Signed-off-by: Yan Zhao --- arch/x86/kvm/mmu/mmu.c | 3 ++- arch/x86/kvm/mmu/tdp_mmu.c | 3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c index 3d74e680006f..47fd3712afe6 100644 --- a/arch/x86/kvm/mmu/mmu.c +++ b/arch/x86/kvm/mmu/mmu.c @@ -2846,7 +2846,8 @@ static int mmu_set_spte(struct kvm_vcpu *vcpu, struct kvm_memory_slot *slot, } if (is_shadow_present_pte(*sptep)) { - if (prefetch && is_last_spte(*sptep, level)) + if (prefetch && is_last_spte(*sptep, level) && + pfn == spte_to_pfn(*sptep)) return RET_PF_SPURIOUS; /* diff --git a/arch/x86/kvm/mmu/tdp_mmu.c b/arch/x86/kvm/mmu/tdp_mmu.c index 5f9e7374220e..8b37e4f542f3 100644 --- a/arch/x86/kvm/mmu/tdp_mmu.c +++ b/arch/x86/kvm/mmu/tdp_mmu.c @@ -1139,7 +1139,8 @@ static int tdp_mmu_map_handle_target_level(struct kvm_vcpu *vcpu, if (is_shadow_present_pte(iter->old_spte) && is_access_allowed(fault, iter->old_spte) && - is_last_spte(iter->old_spte, iter->level)) + is_last_spte(iter->old_spte, iter->level) && + !WARN_ON_ONCE(fault->pfn != spte_to_pfn(iter->old_spte))) return RET_PF_SPURIOUS; if (unlikely(!fault->slot)) From patchwork Fri Feb 7 03:09:31 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yan Zhao X-Patchwork-Id: 13964280 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 997F215B99E; Fri, 7 Feb 2025 03:10:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.19 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1738897839; cv=none; b=aseIYIySadc4zYNtN0jP2KywkLiXT++qlnQ7a9+mHlmuxoPq6IU+iWWywa48yHC0ML7SVmxHMm3xiLKSz7OaJz5S0SCXqMGUzbrq0GWtMAaa7nBWty8sx3bLIySzMHyirsbe/S/LeiAS3RoZfnBCAqQkBcGAQgCOci317mO/hGQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1738897839; c=relaxed/simple; bh=i49YZ8XKMLB6OSNTyXAHmqR6isI1HtHi4zigGDW2RSI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=pjPkJz4wOxtxxZxm5rBqLrW+/OvbDIUvQ7N9TS1zSjsN7g83ZAvYPL/wphV2LvuSzgBiX3x7IinlVksVb3semozcK7aypMXSq4BpL91THxGLSoC2S7/16HjpfTuhw46a39Gfh5mrYXqKCnuFoV0yy7mE14cDiYNOslWHWR9L5Lw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=V2WdRQOn; arc=none smtp.client-ip=192.198.163.19 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="V2WdRQOn" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1738897838; x=1770433838; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=i49YZ8XKMLB6OSNTyXAHmqR6isI1HtHi4zigGDW2RSI=; b=V2WdRQOnD5DRfiy6/wZvIF+O3vU+RIroRmgj8F+Pqe8SictxVdSvWBMe 5VlYFuotcAKr9HDjuX0hlZ7Xpaku1l6m7o+nNkO2+jP4DdBdbuLDaVl22 V39eIqAHt3v2TDU7rU6mUxs3SUA7qwCu4eYApuLKFTatc90hKOyed88nn HKNPWC4BZjew8sjvnTchby4813CmDMfReXCaM81qZ6S9vpDu3cM1VAo1a hb/8+Fr6CZv1GHk85e8XiV28/V/EZA1gxGYl/bG/+zSEy+FtK62g/ZheN SuSE5MPfb/kkvci0/R+GZsvj8iBrTPRZx9N8VekaR/NqMbmPYYeBxZNm6 A==; X-CSE-ConnectionGUID: klctfO7FRL24rSdDao2OkA== X-CSE-MsgGUID: 4xoeqIqbTFmis43cyUFouw== X-IronPort-AV: E=McAfee;i="6700,10204,11336"; a="38731418" X-IronPort-AV: E=Sophos;i="6.13,266,1732608000"; d="scan'208";a="38731418" Received: from orviesa004.jf.intel.com ([10.64.159.144]) by fmvoesa113.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Feb 2025 19:10:37 -0800 X-CSE-ConnectionGUID: +bzVq0biSbi6FMaMSsL5Nw== X-CSE-MsgGUID: wz3Y71LDSfyyNDplkIr/ow== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.13,266,1732608000"; d="scan'208";a="116412270" Received: from yzhao56-desk.sh.intel.com ([10.239.159.62]) by orviesa004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Feb 2025 19:10:35 -0800 From: Yan Zhao To: pbonzini@redhat.com, seanjc@google.com Cc: rick.p.edgecombe@intel.com, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Yan Zhao Subject: [PATCH 4/4] KVM: x86/mmu: Free obsolete roots when pre-faulting SPTEs Date: Fri, 7 Feb 2025 11:09:31 +0800 Message-ID: <20250207030931.1902-1-yan.y.zhao@intel.com> X-Mailer: git-send-email 2.43.2 In-Reply-To: <20250207030640.1585-1-yan.y.zhao@intel.com> References: <20250207030640.1585-1-yan.y.zhao@intel.com> Precedence: bulk X-Mailing-List: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Always free obsolete roots when pre-faulting SPTEs in case it's called after a root is invalidated (e.g., by memslot removal) but before any vcpu_enter_guest() processing of KVM_REQ_MMU_FREE_OBSOLETE_ROOTS. Lack of kvm_mmu_free_obsolete_roots() in this scenario can lead to kvm_mmu_reload() failing to load a new root if the current root hpa is an obsolete root (which is not INVALID_PAGE). Consequently, kvm_arch_vcpu_pre_fault_memory() will retry infinitely due to the checking of is_page_fault_stale(). It's safe to call kvm_mmu_free_obsolete_roots() even if there are no obsolete roots or if it's called a second time when vcpu_enter_guest() later processes KVM_REQ_MMU_FREE_OBSOLETE_ROOTS. This is because kvm_mmu_free_obsolete_roots() sets an obsolete root to INVALID_PAGE and will do nothing to an INVALID_PAGE. Signed-off-by: Yan Zhao --- arch/x86/kvm/mmu/mmu.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c index 47fd3712afe6..72f68458049a 100644 --- a/arch/x86/kvm/mmu/mmu.c +++ b/arch/x86/kvm/mmu/mmu.c @@ -4740,7 +4740,12 @@ long kvm_arch_vcpu_pre_fault_memory(struct kvm_vcpu *vcpu, /* * reload is efficient when called repeatedly, so we can do it on * every iteration. + * Before reload, free obsolete roots in case the prefault is called + * after a root is invalidated (e.g., by memslot removal) but + * before any vcpu_enter_guest() processing of + * KVM_REQ_MMU_FREE_OBSOLETE_ROOTS. */ + kvm_mmu_free_obsolete_roots(vcpu); r = kvm_mmu_reload(vcpu); if (r) return r;