Received-SPF: pass (google.com: domain of linux-kernel+bounces-104841-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Date: Fri, 15 Mar 2024 12:20:30 -0700
In-Reply-To: <07b75e0f18a5082a91f80fb234d29c97489e2f75.camel@intel.com>
Precedence: bulk
Mime-Version: 1.0
References: <cover.1708933498.git.isaku.yamahata@intel.com>
 <8f64043a6c393c017347bf8954d92b84b58603ec.1708933498.git.isaku.yamahata@intel.com>
 <e6e8f585-b718-4f53-88f6-89832a1e4b9f@intel.com> <bd21a37560d4d0695425245658a68fcc2a43f0c0.camel@intel.com>
 <54ae3bbb-34dc-4b10-a14e-2af9e9240ef1@intel.com> <ZfR4UHsW_Y1xWFF-@google.com>
 <ZfSJkwnC4LRCqQS9@google.com> <07b75e0f18a5082a91f80fb234d29c97489e2f75.camel@intel.com>
Message-ID: <ZfSQC8vsqqE2DziW@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: Dave Hansen <dave.hansen@intel.com>, Tina Zhang <tina.zhang@intel.com>, 
	Hang Yuan <hang.yuan@intel.com>, Kai Huang <kai.huang@intel.com>, 
	"x86@kernel.org" <x86@kernel.org>, Bo Chen <chen.bo@intel.com>, 
	"sagis@google.com" <sagis@google.com>, 
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, 
	"isaku.yamahata@gmail.com" <isaku.yamahata@gmail.com>, Erdem Aktas <erdemaktas@google.com>, 
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>, "pbonzini@redhat.com" <pbonzini@redhat.com>, 
	Isaku Yamahata <isaku.yamahata@intel.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Mar 15, 2024, Rick P Edgecombe wrote:
> On Fri, 2024-03-15 at 10:46 -0700, Sean Christopherson wrote:
> > On Fri, Mar 15, 2024, Sean Christopherson wrote:
> > > So my feedback is to not worry about the exports, and instead focus o=
n
> > > figuring out a way to make the generated code less bloated and easier=
 to
> > > read/debug.
> >=20
> > Oh, and please make it a collaborative, public effort.=C2=A0 I don't wa=
nt to
> > hear crickets and then see v20 dropped with a completely new SEAMCALL
> > scheme.
>=20
> And here we we're worrying that people might eventually grow tired of
> us adding mails to v19 and we debate every detail in public. Will do.

As a general rule, I _strongly_ prefer all review to be done on-list, in pu=
blic.
Copy+pasting myself from another Intel series[*]

 : Correct, what I object to is Intel _requiring_ a Reviewed-by before post=
ing.
 :=20
 : And while I'm certainly not going to refuse patches that have been revie=
wed
 : internally, I _strongly_ prefer reviews be on-list so that they are publ=
ic and
 : recorded.  Being able to go back and look at the history and evolution o=
f patches
 : is valuable, and the discussion itself is often beneficial to non-partic=
ipants,
 : e.g. people that are new-ish to KVM and/or aren't familiar with the feat=
ure being
 : enabled can often learn new things and avoid similar pitfalls of their o=
wn.

There are definitely situations where exceptions are warranted, e.g. if som=
eone
is a first-time poster and/or wants a sanity check to make sure their idea =
isn't
completely crazy.  But even then, the internal review should only be very c=
ursory.

In addition to the history being valuable, doing reviews in public minimize=
s the
probability of a developer being led astray, e.g. due to someone internally=
 saying
do XYZ, and then upstream reviewers telling them to do something entirely d=
ifferent.=20

As far as noise goes, look at it this way.  Every time a new TDX series is =
posted,
I get 130+ emails.  Y'all can do a _lot_ of public review and discussion be=
fore
you'll get anywhere near the point where it'd be noiser than spinning a new=
 version
of the series.

[*] https://lore.kernel.org/all/Y+ZxLfCrcTQ6poYg@google.com