From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f73.google.com (mail-pj1-f73.google.com [209.85.216.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6B684239E75 for ; Mon, 9 Feb 2026 17:01:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.73 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770656485; cv=none; b=tU4xcWbrF+8lMfSMqW/mK8xQBzxWT+jS0KThyW7Aadq9jjTooW/QVWZjArRrO3mzHY5KLjDuRdVfolRC4XI+B9iuXpg9RW2d9V8vGpt8PIYfnbPa4YOYVst+esSeivo+XNTTAU6DLJ0ef8IJ5C5GeYkw7o3XuUB3G6aBquYJhfw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770656485; c=relaxed/simple; bh=ZgnQqes4djfrfi9IYR4uHMRZrCYkJ/8HL12/68MoSIw=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=E5txz7NEpKRILr59zyZrsgrtIPpPFcQvSV+OqzW+P91zmfzrt9NMcEtbHNAFxfmSE5ld62C9CID4mp43JyGxUN2tiiecE+aSA9MYsVoVn8pnBtyoHZ/ceg55ZUpO5RDDyLXbTmM9ciuthRmqcRE8ZXWl3r4DIxobYH1gcTvYCBk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=4lAoT8TW; arc=none smtp.client-ip=209.85.216.73 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="4lAoT8TW" Received: by mail-pj1-f73.google.com with SMTP id 98e67ed59e1d1-35626b11c51so1631191a91.1 for ; Mon, 09 Feb 2026 09:01:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1770656485; x=1771261285; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=YO6+F3jNsnF76vkonyTGMuR54wo2HffVdoLaCoDx93U=; b=4lAoT8TW4TkNrPVxRaCtU84vlrV3QRMd7QX7qxz3GIEiFgSlLzhIkAdeWk2hY9atgw IhLGI4a7POkF+NVnZ5vD8nr3BsM79GvkOf3TusmhnIL5YrpJKEBYExS1Z+O0VcYvLdP0 3qs1/zUF3Ff1MZEIgfqi4UVpG/2dxUpK0FOTQSu3gWpm7xoXljYce5heWrjFTYazNeJZ kgp5l+Su5xw5aZhC2mkKYmbsZvUO8yo/2MCmtQBkT93I79DcgpJaEt5mFISgPjSBm/aL +mpi8dh5I0NcCRHZs1QstThaa8Xcr0MyHn3kH2CDfBTMbFoN7aTMjNnQjBAhh0yAtyvH TEIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770656485; x=1771261285; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=YO6+F3jNsnF76vkonyTGMuR54wo2HffVdoLaCoDx93U=; b=QREjz8GCdIC0Kfx6Bq74LMHCL3TFMTIk9/8Yybg1nyAqV6USyLBOeLAd6qjeY8QGhq 1/Sigv80E6aBRHRyVbLm9u1uKB6ELlxUCMM5myUD4SkIBzztlYcIMrsq6PaWb8DTJJkC N9s8j+qIS+QnGSIJhs2+8Q3a5EsiG9/Z8rdybd/YoNGHbNweqx+XI6B3Mh6FZSZt3nDG vJ75btU2VaZfmw/pWTtM8VM6KzMW+b6juAcb4O8ctU3AjFrkXVG4EP1LZL9A3jc0edFO XqDnv2IRU+L+Afv1HpbZd3Aa9RMxX+NVRW2PDODP7AlwWDM2okwXPe1Cx/tUNqkp4K2l 9DYA== X-Forwarded-Encrypted: i=1; AJvYcCW6xAOpLjUipU9XUs77Wnzhb8TPT+RIcaAHw/KP/OMsn9sG7RP02wtqRCjA/eZY6m4V38XtiKu61DeBewM=@vger.kernel.org X-Gm-Message-State: AOJu0YwiR8aUuG+XT4p9ApYwhMtew8lnRNJd6+w8DQS0UWOI6qj4SXz2 cKHb0sVkeftFAah+zT2y9eiymqmOhXv3yHERE9pjL/WFfqETyTmXbS+Ozv4gDnKGrCdSrTaGdE9 6iF6rSA== X-Received: from pjtl24.prod.google.com ([2002:a17:90a:c598:b0:354:c16d:17b]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:2d86:b0:34c:c50e:9b80 with SMTP id 98e67ed59e1d1-354b3e42c3emr9815813a91.27.1770656484526; Mon, 09 Feb 2026 09:01:24 -0800 (PST) Date: Mon, 9 Feb 2026 09:01:23 -0800 In-Reply-To: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <6184812b4449947395417b07ae3bad2f191d178f.camel@intel.com> Message-ID: Subject: Re: [PATCH v3 00/24] KVM: TDX huge page support for private memory From: Sean Christopherson To: Yan Zhao Cc: Rick P Edgecombe , Fan Du , Xiaoyao Li , Kai Huang , "kvm@vger.kernel.org" , Dave Hansen , "thomas.lendacky@amd.com" , "vbabka@suse.cz" , "tabba@google.com" , "david@kernel.org" , "kas@kernel.org" , "linux-kernel@vger.kernel.org" , Ira Weiny , "francescolavra.fl@gmail.com" , "pbonzini@redhat.com" , "ackerleytng@google.com" , "nik.borisov@suse.com" , "binbin.wu@linux.intel.com" , Isaku Yamahata , Chao P Peng , "michael.roth@amd.com" , Vishal Annapurve , "sagis@google.com" , Chao Gao , Jun Miao , "jgross@suse.com" , "pgonda@google.com" , "x86@kernel.org" Content-Type: text/plain; charset="us-ascii" On Tue, Feb 03, 2026, Yan Zhao wrote: > On Fri, Jan 30, 2026 at 07:32:48AM -0800, Sean Christopherson wrote: > > On Mon, Jan 19, 2026, Yan Zhao wrote: > > > On Sat, Jan 17, 2026 at 12:58:02AM +0800, Edgecombe, Rick P wrote: > > > > On Fri, 2026-01-16 at 08:31 -0800, Sean Christopherson wrote: > > > IIUC, this concern should be gone as Dave has agreed to use "pfn" as the > > > SEAMCALL parameter [1]? > > > Then should we invoke "KVM_MMU_WARN_ON(!tdx_is_convertible_pfn(pfn));" in KVM > > > for every pfn of a huge mapping? Or should we keep the sanity check inside the > > > SEAMCALL wrappers? > > > > I don't have a strong preference. But if it goes in KVM, definitely guard it with > > KVM_MMU_WARN_ON(). > Thank you for your insights, Sean! > > > > BTW, I have another question about the SEAMCALL wrapper implementation, as Kai > > > also pointed out in [2]: since the SEAMCALL wrappers now serve as APIs available > > > to callers besides KVM, should the SEAMCALL wrappers return TDX_OPERAND_INVALID > > > or WARN_ON() (or WARN_ON_ONCE()) on sanity check failure? > > > > Why not both? But maybe TDX_SW_ERROR instead of TDX_OPERAND_INVALID? > Hmm, I previously returned TDX_OPERAND_INVALID for non-aligned base PFN. > TDX_SW_ERROR is also ok if we want to indicate that passing an invalid PFN is a > software error. > (I had tdh_mem_page_demote() return TDX_SW_ERROR when an incompatible TDX module > is used, i.e., when !tdx_supports_demote_nointerrupt()). > > > If an API has a defined contract and/or set of expectations, and those expectations > > aren't met by the caller, then a WARN is justified. But the failure still needs > > to be communicated to the caller. > Ok. > > The reason for 'not both' is that there's already TDX_BUG_ON_2() in KVM after > the SEAMCALL wrapper returns a non-BUSY error. I'm not sure if having double > WARN_ON_ONCE() calls is good, so I intended to let the caller decide whether to > warn. Two WARNs isn't the end of the world. It might even be helpful in some cases, e.g. to more precisely document what went wrong. > > > By returning TDX_OPERAND_INVALID, the caller can check the return code, adjust > > > the input or trigger WARN_ON() by itself; > > > By triggering WARN_ON() directly in the SEAMCALL wrapper, we need to document > > > this requirement for the SEAMCALL wrappers and have the caller invoke the API > > > correctly. > > > > Document what exactly? Most of this should be common sense. E.g. we don't generally > > document that pointers must be non-NULL, because that goes without saying 99.9% > > of the time. > Document the SEAMCALL wrapper's expectations. e.g., for demote, a PFN must be > 2MB-aligned, or the caller must not invoke tdh_mem_page_demote() if a TDX module > does not support feature ENHANCED_DEMOTE_INTERRUPTIBILITY... FWIW, for me, all of those are self-explanatory and/or effectively covered by the TDX specs. > > IMO, that holds true here as well. E.g. trying to map memory into a TDX guest > > that isn't convertible is obviously a bug, I don't see any value in formally > > documenting that requirement. > Do we need a comment for documentation above the tdh_mem_page_demote() API? I wouldn't bother, but I truly don't care if the TDX subsystem wants to document everything in gory detail.