From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f201.google.com (mail-pl1-f201.google.com [209.85.214.201]) (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 C11462F28FB for ; Tue, 3 Feb 2026 20:32:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770150729; cv=none; b=UZQDRZcAxk7qojs60dsu2J4TmHPqc8Uq/Efob+GFV3b2kFayHq6yOvwFYNiJ5vIpKjeIJni6wXasy1FRtPkm0YqVfLpqAzpsU/O430mrCOgoL79/XdGvMU7Z+9wC6AIfTu8gRWpSkRye5bEhLlDtRoOMo5ysJN1FByyjudwZzME= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770150729; c=relaxed/simple; bh=bKHWA8su8QIXIXtDVlgoocC0CLqf6RJFADPLXMN6Yqg=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=YOQnsOjS6gUZKDbv8ypfaK9whW0CKXYvgwoZLARCUIYt4XG3ZezwF49SgKTBuRFS9sOnmlTZ2auk3DUK1q7MjbFdJjkLW5wsLZ2PL2uY5A6TqCesjk7/3b6esACZa4TzNjr68C2i+/HA7osnZKr8azZqeGikh5pB1P+QdpCkydI= 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=twRgEPQr; arc=none smtp.client-ip=209.85.214.201 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="twRgEPQr" Received: by mail-pl1-f201.google.com with SMTP id d9443c01a7336-29f1f79d6afso67376285ad.0 for ; Tue, 03 Feb 2026 12:32:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1770150727; x=1770755527; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=Sro3VZZ5Btk693WGQpZmCjZMxNDIjNnXRKqN3fdBlbA=; b=twRgEPQrx8ihipmSjeIbE43pizWMUk8KGSj42Ictd9w59m6GTbRfzKWdLBRMkgD0ZN oOklaLVgCcYYr9f5SReacSbDepVAniet8UfBCIXKuSfcfUBupdF8FQWTKThXcF+1/8Yv ENHw0Z1evIYIsoTaFH5vlDdTi+bZmUWOBMit45sHVMRT/k3UWXLAfKbt6Pmuyr++3UgM kBhOJfaUXbINgrdmmvqBfqWReL1wCjo2a8KOpcbiPf+FeqoF8Iym+SiKQdX+T7gtwM1d cqf9P6Q08ZjByCkoUIVV2003ImhnvS2MTLmjwfvo76aWncDnrETNm5TEOYweMeTWOQiY mUVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770150727; x=1770755527; h=content-transfer-encoding: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=Sro3VZZ5Btk693WGQpZmCjZMxNDIjNnXRKqN3fdBlbA=; b=MAxFWpJRr6SYiriSeEvZg+JPdyKnzUb6Wg9+0bb9oxTpzX2Uc+N9eau8aHrY79rvOO vSYMcuqoWHUp8r2KghbuIecQzQbGRnffaqWJWvfQB2/Cn0DDdKxxrejtaa++f5NHSPAd j29hQtjTFX99ibKhyrAcYLzbgekVX0dMAoYQI2PTB8YpAYG4LLOJ4GQxIeeoK+1Uv50x G+CSn2hVvjgDZ6Y4iKajOrbces30luZLQ4bq1bP2hSwFQ1iIKOPC1JNGdEGCYMa5S2WE 2SS/eW1ZCQPHfMpJlHhzlYrMHuRv2BJsRJVlxmz7BIKP7jxUWwgiErwALJq8h2HAH19F nHXQ== X-Forwarded-Encrypted: i=1; AJvYcCVskreTAyJyIHAY/dYPRhPml0S76k8gGnBRw9VTAuXYcJKBtXV1ypwk11FTQVim+D+9qTAMqRB+U+hH6P0=@vger.kernel.org X-Gm-Message-State: AOJu0YxlUNcyTO3YOGbX0TPdD7sPnwwo275MAhmm/e/Vqu0sx9uYmZBn 0ylxJVQyxD48FTckb767AK6EG2/ctFUnGHYDnztmaMNvmBxYWWE/mQfrwN32Z2fEKB9ugNF/mzl bYB0hsQ== X-Received: from plav14.prod.google.com ([2002:a17:902:f0ce:b0:2a7:6eb5:7e34]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:902:e807:b0:2a7:b8f9:5a5e with SMTP id d9443c01a7336-2a933feb333mr5180435ad.46.1770150727058; Tue, 03 Feb 2026 12:32:07 -0800 (PST) Date: Tue, 3 Feb 2026 12:32:05 -0800 In-Reply-To: <8c5aca4bacb31475a510e6a109956e7fa4a63de5.camel@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260129011517.3545883-1-seanjc@google.com> <20260129011517.3545883-12-seanjc@google.com> <8c5aca4bacb31475a510e6a109956e7fa4a63de5.camel@intel.com> Message-ID: Subject: Re: [RFC PATCH v5 11/45] x86/tdx: Add helpers to check return status codes From: Sean Christopherson To: Rick P Edgecombe Cc: Dave Hansen , "kvm@vger.kernel.org" , "linux-coco@lists.linux.dev" , Kai Huang , Xiaoyao Li , Yan Y Zhao , "dave.hansen@linux.intel.com" , "kas@kernel.org" , "binbin.wu@linux.intel.com" , "mingo@redhat.com" , "pbonzini@redhat.com" , "ackerleytng@google.com" , "linux-kernel@vger.kernel.org" , Isaku Yamahata , "sagis@google.com" , "tglx@kernel.org" , "bp@alien8.de" , Vishal Annapurve , "x86@kernel.org" Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Fri, Jan 30, 2026, Rick P Edgecombe wrote: > On Thu, 2026-01-29 at 12:35 -0800, Sean Christopherson wrote: > > On Thu, Jan 29, 2026, Dave Hansen wrote: > > > On 1/28/26 17:14, Sean Christopherson wrote: > > > ... > > > > =C2=A0=C2=A0 err =3D tdh_mng_vpflushdone(&kvm_tdx->td); > > > > - if (err =3D=3D TDX_FLUSHVP_NOT_DONE) > > > > + if (IS_TDX_FLUSHVP_NOT_DONE(err)) > > > > =C2=A0=C2=A0 goto out; > > > > =C2=A0=C2=A0 if (TDX_BUG_ON(err, TDH_MNG_VPFLUSHDONE, kvm)) { > > >=20 > > > I really despise the non-csopeable, non-ctaggable, non-greppable name= s > > > like this. Sometimes it's unavoidable. Is it really unavoidable here? > > >=20 > > > Something like this is succinct enough and doesn't have any magic ## > > > macro definitions: > > >=20 > > > =C2=A0 TDX_ERR_EQ(err, TDX_FLUSHVP_NOT_DONE) >=20 > I like the editor friendliness. The only downside is that it puts the onu= s on > the caller to make sure supported defines are passed into TDX_ERR_EQ(). Eh, that's easy enough to handle with a static_assert(). > Today there are a few special cases like IS_TDX_NON_RECOVERABLE(). Why bother with a wrapper for that one? It's a single bit, just test that = bit. For me, providing IS_TDX_NON_RECOVERABLE() is _more_ confusing, because it suggests that there's a NON_RECOVERABLE error, when in fact (IIUC) it's mor= e or less a modifier. > I don't know, I'm ok either way. I lean towards keeping it as in this pat= ch > because we already had an error code bit interpretation bug: > https://lore.kernel.org/kvm/24d2f165-f854-4996-89cf-28d644c592a3@intel.co= m/ >=20 > So the centralization of bit interpretation seems like a real win. >=09 > > FWIW, I have zero preference on this.=C2=A0 I included the patch purely= because it was > > already there. >=20 > Ha, actually we all had a long thread on this: > https://lore.kernel.org/kvm/70484aa1b553ca250d893f80b2687b5d915e5309.came= l@intel.com/ Oh, it's _that_ discussion :-) What I meant was, "I don't have a strong preference between TDX_ERR_EQ() an= d this patch". What I didn't like was tdx_operand_invalid(), because that re= ads like a command and it's not at all clear that it's macro-like in behavior. I'd vote for IS_TDX_ERR() over TDX_ERR_EQ(), but either works for me (as do= es this patch). > I see now that we closed it with you but never got Dave's final buy in.