From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.18]) (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 CC62A28C84A for ; Thu, 23 Apr 2026 11:38:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776944287; cv=none; b=Kr1Ov8ek51SXan7vN4J6m5pSbu21Wn6wMDlhqOXf2IU9Xn0ewbuff0hQ2LDYUt6dVAxgvlLy4KNVs0f5oynTHjynGBHgsUo19OQsUi9qRutDn8RdFROn7I89fK6nhzPkw6XLDa7vP/C9gz9RF/Lao+3ZJpVaBDSCdYfJUdq5jXc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776944287; c=relaxed/simple; bh=R4Ca6IN1mWJGYFdQzaPE55EKhI3bfpMmk2W2eUuXQk4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=LojC1ZXAleE6xZgzDUDpdcLL0A1PA54PlH5NTu13Ch17bcNY1TYm4/VdA3V8n+jInlQJrlSm9tjwgsPULwOT7JMzmewjb5OjmiYhlPt4BnjKqhbEbegp8aR7Ulf3N7FuksrwUWw8NepS6piFl+1SX18F8Z5dTcfDM1E4EgFm5Zs= 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=DsqCfQK5; arc=none smtp.client-ip=192.198.163.18 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="DsqCfQK5" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1776944287; x=1808480287; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=R4Ca6IN1mWJGYFdQzaPE55EKhI3bfpMmk2W2eUuXQk4=; b=DsqCfQK5IIjltm5zK2IwxGplYNYl3/8BnuN1lSIKe5xm1Wc9jY8pDjff EFGg+219TshrOfqRRkmy0PewUZSAX8HgtQ6KsJed4/QMAm63CanOa6Cg9 tbWr5UH33W2leOwmr+YXtQKknxS6qkbYV3h3hbuJ/kAZnOFjYh469Wrjr c+uOsmiY/yr3/zxyrjysRHDWH4dBoJr7+LW1FCPHrSdavzmHHF7OmDlSZ aN4pVCuGu9JYqOJdMFNwtetwDIEKqQBl7OM7VPEpBmjYkqXvASofoXzWA EhZ7x2nQ4OHIYp1WZFfYTPD3fUd5CL99HBlSR0ESwcR6PvQOt/6dZGWps w==; X-CSE-ConnectionGUID: iJTzF3aXQ3mPHakCzsrO7Q== X-CSE-MsgGUID: fymXLvBwSYutvq4s6qwscg== X-IronPort-AV: E=McAfee;i="6800,10657,11764"; a="77076525" X-IronPort-AV: E=Sophos;i="6.23,194,1770624000"; d="scan'208";a="77076525" Received: from orviesa006.jf.intel.com ([10.64.159.146]) by fmvoesa112.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 23 Apr 2026 04:38:06 -0700 X-CSE-ConnectionGUID: YOC+9CzoQ1qbgt/bfOfHKw== X-CSE-MsgGUID: VwVj9JQlQQC/APZI3GucUw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,194,1770624000"; d="scan'208";a="231608619" Received: from yilunxu-optiplex-7050.sh.intel.com (HELO localhost) ([10.239.159.165]) by orviesa006.jf.intel.com with ESMTP; 23 Apr 2026 04:38:03 -0700 Date: Thu, 23 Apr 2026 19:15:46 +0800 From: Xu Yilun To: Dan Williams Cc: "Edgecombe, Rick P" , "Gao, Chao" , "Xu, Yilun" , "x86@kernel.org" , "kas@kernel.org" , "baolu.lu@linux.intel.com" , "dave.hansen@linux.intel.com" , "Li, Xiaoyao" , "Jiang, Dave" , "linux-pci@vger.kernel.org" , "linux-coco@lists.linux.dev" , "linux-kernel@vger.kernel.org" , "Duan, Zhenzhong" , "Verma, Vishal L" , "kvm@vger.kernel.org" Subject: Re: [PATCH v2 05/31] x86/virt/tdx: Extend tdx_page_array to support IOMMU_MT Message-ID: References: <20260327160132.2946114-1-yilun.xu@linux.intel.com> <20260327160132.2946114-6-yilun.xu@linux.intel.com> <828f174d49a1ecaec65ba1179e08c6b22e249297.camel@intel.com> <69e2c9334cbf7_147c8010040@djbw-dev.notmuch> <69e7f166319a5_fe083100f7@djbw-dev.notmuch> Precedence: bulk X-Mailing-List: linux-coco@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <69e7f166319a5_fe083100f7@djbw-dev.notmuch> > A couple recommendations come to mind: > > * s/tdx_page_array_free/tdx_page_array_destroy/ > > ...since "destroy" mirrors create and matches other cases where only > metadata is managed. > > * Create a new tdx_page_array_repopulate() helper to make it clear which > paths depend on being able to repopulate and move the WARN_ON_ONCE() out of > the common path that does not repopulate. "repopulate" can have > "realloc" semantics where it allocates on first use, but otherwise > "populate" gets to not care about the corner cases. Make the WARN case > fail repopulate. Agree. I end up add a function like that: /** * tdx_page_array_repopulate() - repopulate a tdx_page_array * @array: The array descriptor to reallocate for. * @pages: Pointer to struct page array for tdx_page_array populating * @nr_pages: Size of @pages array. * * Re-populate the tdx_page_array. If @array is %NULL, it behaves exactly like * tdx_page_array_create(). * * Return: Re-populated tdx_page_array or NULL on failure. */ static struct tdx_page_array * tdx_page_array_repopulate(struct tdx_page_array *array, struct page **pages, unsigned int nr_pages) { struct tdx_page_array *tmp = array; int ret; if (tmp) { /* Don't pass in something partially initialized */ if (!tmp->root || !tmp->pages || !tmp->nr_pages) return NULL; /* * When re-populating, the old pages are no longer tracked. * Theoretically they require cache flushing before reclaiming * for other kernel usage, similar to tdx_page_array_destroy(). * Since there is no use case to repopulate and then reclaim * old pages yet, just warn to prompt future improvement. */ if (WARN_ON_ONCE(tmp->need_phymem_page_wbinvd)) return NULL; } else { tmp = tdx_page_array_alloc(); if (!tmp) return NULL; } ret = tdx_page_array_populate(tmp, pages, nr_pages); if (ret) { /* Only destroy newly allocated object */ if (!array) tdx_page_array_destroy(tmp); return NULL; } return tmp; }