Received-SPF: pass (google.com: domain of linux-kernel+bounces-153946-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Date: Mon, 22 Apr 2024 12:50:31 -0700
In-Reply-To: <ea77e297510c8f578005ad29c14246951cba8222.camel@intel.com>
Precedence: bulk
Mime-Version: 1.0
References: <54ae3bbb-34dc-4b10-a14e-2af9e9240ef1@intel.com>
 <ZfR4UHsW_Y1xWFF-@google.com> <ay724yrnkvsuqjffsedi663iharreuu574nzc4v7fc5mqbwdyx@6ffxkqo3x5rv>
 <39e9c5606b525f1b2e915be08cc95ac3aecc658b.camel@intel.com>
 <m536wofeimei4wdronpl3xlr3ljcap3zazi3ffknpxzdfbrzsr@plk4veaz5d22>
 <ZiFlw_lInUZgv3J_@google.com> <7otbchwoxaaqxoxjfqmifma27dmxxo4wlczyee5pv2ussguwyw@uqr2jbmawg6b>
 <3290ad9f91cf94c269752ccfd8fe2f2bfe6313d1.camel@intel.com>
 <no7n57wmkm3pdkannl2m3u622icfdnof27ayukgkb7q4prnx6k@lfm5cnbie2r5> <ea77e297510c8f578005ad29c14246951cba8222.camel@intel.com>
Message-ID: <Zia_hxSH1p_8qB8L@google.com>
Subject: Re: [PATCH v19 007/130] x86/virt/tdx: Export SEAMCALL functions
From: Sean Christopherson <seanjc@google.com>
To: Rick P Edgecombe <rick.p.edgecombe@intel.com>
Cc: "kirill.shutemov@linux.intel.com" <kirill.shutemov@linux.intel.com>, Tina Zhang <tina.zhang@intel.com>, 
	Dave Hansen <dave.hansen@intel.com>, Hang Yuan <hang.yuan@intel.com>, 
	Kai Huang <kai.huang@intel.com>, "x86@kernel.org" <x86@kernel.org>, Bo2 Chen <chen.bo@intel.com>, 
	"sagis@google.com" <sagis@google.com>, 
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Erdem Aktas <erdemaktas@google.com>, 
	"isaku.yamahata@gmail.com" <isaku.yamahata@gmail.com>, "kvm@vger.kernel.org" <kvm@vger.kernel.org>, 
	Isaku Yamahata <isaku.yamahata@intel.com>, "pbonzini@redhat.com" <pbonzini@redhat.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Apr 22, 2024, Rick P Edgecombe wrote:
> On Mon, 2024-04-22 at 14:46 +0300, kirill.shutemov@linux.intel.com wrote:
> > On Fri, Apr 19, 2024 at 08:04:26PM +0000, Edgecombe, Rick P wrote:
> > > On Fri, 2024-04-19 at 17:46 +0300, kirill.shutemov@linux.intel.com=C2=
=A0wrote:
> > > >=20
> > > > > Side topic #3, the ud2 to induce panic should be out-of-line.
> > > >=20
> > > > Yeah. I switched to the inline one while debugging one section mism=
atch
> > > > issue and forgot to switch back.
> > >=20
> > > Sorry, why do we need to panic?
> >=20
> > It panics in cases that should never occur if the TDX module is
> > functioning properly. For example, TDVMCALL itself should never fail,
> > although the leaf function could.
>=20
> Panic should normally be for desperate situations when horrible things wi=
ll
> likely happen if we continue, right? Why are we adding a panic when we di=
dn't
> have one before? Is it a second change, or a side affect of the refactor?

The kernel already does panic() if TDCALL itself fails,

  static inline void tdcall(u64 fn, struct tdx_module_args *args)
  {
	if (__tdcall_ret(fn, args))
		panic("TDCALL %lld failed (Buggy TDX module!)\n", fn);
  }

  /* Called from __tdx_hypercall() for unrecoverable failure */
  noinstr void __noreturn __tdx_hypercall_failed(void)
  {
	instrumentation_begin();
	panic("TDVMCALL failed. TDX module bug?");
  }

it's just doesn in C code via panic(), not in asm via a bare ud2.