From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.12]) (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 673713019AB; Fri, 14 Nov 2025 09:14:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.12 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763111654; cv=none; b=HypBJDdBV/Pg051M295XHQP85ERW5lPvwsCxyuDQ6XL75XjE3ma7OvLv686FvPE+5nVggp3ydnK92POPSjYUyk7Cz1z2DhboGhYvmoMQeE0eWvf0iK0ktZvmw6LejnX9G8K3MHeK9O6pFDmG6e9Ds3IktK0x6CezfZ8BAoaiaj4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763111654; c=relaxed/simple; bh=7cbUTy8lrEsWe5MpAWrFPwUzRXOUxrth7itvq6u3B08=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=X+a4Zfs0Tnmuw9hiYVH3+0dRQtMu5g2XN/F4zxBotMd++fcaUuEYiKo1HcGDJWTmlYQGkxPYXr4RMMiTuOFx/TvMWBN63JbE+oTlgfR4CU45ssXy1qm/bjAScy3zjmF+ZzXxnzM/3150HwDjS4cFTFc1fVAyjk11rp3IvqZzEM8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=oDUFCbRq; arc=none smtp.client-ip=198.175.65.12 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="oDUFCbRq" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1763111652; x=1794647652; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=7cbUTy8lrEsWe5MpAWrFPwUzRXOUxrth7itvq6u3B08=; b=oDUFCbRqumMZLYplYXdyAxWcdMKaiH6+v4HgOLhhKytaGO+dZvW5uM+i xMC3uYkv+2i0FCglpRhWB61OIwaO96DjnoJCcbCCQYYLTaqJJcchN+S0/ 3cawVuuLxKnkO5G+QAQbDR4Yq41MEyG44d/COg1A6z4JzH+DvYTObXhOK u8Cv3MTcy3S4lxtk71D5GKp4v1jWEiuxwA1wE20yEHMMm3YlQiTn7HyGO gluUW/jPrers3sOGNtnLE70wx6IAGOaaQ29gfi7nwMeN/0FSr3MYERNSG S8VB6tEhCbkX6RPTDGoQjc4Gb4yQgJUp+bAQFBh1Tbbx0drRgzcCFpAfH g==; X-CSE-ConnectionGUID: es7X5tZ1QoqcplhLmaLK4g== X-CSE-MsgGUID: YSBsW/WgQlijowzABLhTRw== X-IronPort-AV: E=McAfee;i="6800,10657,11612"; a="76664657" X-IronPort-AV: E=Sophos;i="6.19,304,1754982000"; d="scan'208";a="76664657" Received: from orviesa002.jf.intel.com ([10.64.159.142]) by orvoesa104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Nov 2025 01:14:12 -0800 X-CSE-ConnectionGUID: w78KuXluTuOddILF5kGKkg== X-CSE-MsgGUID: PYVACaR/QJG6hYnJ1ajaIQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.19,304,1754982000"; d="scan'208";a="220387082" Received: from binbinwu-mobl.ccr.corp.intel.com (HELO [10.124.241.55]) ([10.124.241.55]) by orviesa002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Nov 2025 01:14:06 -0800 Message-ID: <9bcd2857-e688-49e7-b3c9-7fa4bbf0b3e7@linux.intel.com> Date: Fri, 14 Nov 2025 17:14:03 +0800 Precedence: bulk X-Mailing-List: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH v2 02/23] x86/virt/tdx: Add SEAMCALL wrapper tdh_mem_page_demote() To: Yan Zhao , "Huang, Kai" Cc: "quic_eberman@quicinc.com" , "kvm@vger.kernel.org" , "Li, Xiaoyao" , "Du, Fan" , "Hansen, Dave" , "david@redhat.com" , "thomas.lendacky@amd.com" , "vbabka@suse.cz" , "tabba@google.com" , "michael.roth@amd.com" , "seanjc@google.com" , "Weiny, Ira" , "pbonzini@redhat.com" , "Peng, Chao P" , "ackerleytng@google.com" , "kas@kernel.org" , "Yamahata, Isaku" , "linux-kernel@vger.kernel.org" , "Annapurve, Vishal" , "Edgecombe, Rick P" , "Miao, Jun" , "zhiquan1.li@intel.com" , "x86@kernel.org" , "pgonda@google.com" References: <20250807093950.4395-1-yan.y.zhao@intel.com> <20250807094149.4467-1-yan.y.zhao@intel.com> <281ae89b-9fc3-4a9b-87f6-26d2a96cde49@linux.intel.com> Content-Language: en-US From: Binbin Wu In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 11/12/2025 4:06 PM, Yan Zhao wrote: > On Tue, Nov 11, 2025 at 05:15:22PM +0800, Huang, Kai wrote: >> On Mon, 2025-09-01 at 17:08 +0800, Yan Zhao wrote: >>>>> Do not handle TDX_INTERRUPTED_RESTARTABLE because SEAMCALL >>>>> TDH_MEM_PAGE_DEMOTE does not check interrupts (including NMIs) for basic >>>>> TDX (with or without Dynamic PAMT). >>>> The cover letter mentions that there is a new TDX module in planning, which >>>> disables the interrupt checking. I guess TDX module would need to have a >>>> interface to report the change, KVM then decides to enable huge page support or >>>> not for TDs? >>> Yes. But I guess detecting TDX module version or if it supports certain feature >>> is a generic problem. e.g., certain versions of TDX module have bugs in >>> zero-step mitigation and may block vCPU entering. >>> >>> So, maybe it deserves a separate series? >> Looking at the spec (TDX module ABI spec 348551-007US), is it enumerated via >> TDX_FEATURES0.ENHANCED_DEMOTE_INTERRUPTIBILITY? > Yes. I checked the unreleased TDX module code that enumerates this bit (starting > from version TDX_1.5.28.00.972). TDH.MEM.PAGE.DEMOTE will not return > TDX_INTERRUPTED_RESTARTABLE for L1 VMs. According to the content pasted by Kai below, it just says there will be no TDX_INTERRUPTED_RESTARTABLE for TDH.MEM.PAGE.DEMOTE if no L2 VMs. KVM doesn't support TD partition yet, just for clarification,  what if the demotion is for L1 VM, but there are L2 VMs configured? > >> 5.4.25.3.9. >> >> Interruptibility >> >> If the TD is not partitioned (i.e., it has been configured with no L2 >> VMs), and the TDX Module enumerates >> TDX_FEATURES0.ENHANCED_DEMOTE_INTERRUPTIBILITY as 1, TDH.MEM.PAGE.DEMOTE >> is not interruptible. >> >> So if the decision is to not use 2M page when TDH_MEM_PAGE_DEMOTE can return >> TDX_INTERRUPTED_RESTARTABLE, maybe we can just check this enumeration in >> fault handler and always make mapping level as 4K? > Thanks for this info! I think this is a very good idea and the right direction. > If no objection, I'll update the code in this way. > > >