Re: [PATCH v4 3/4] tpm: add SNP SVSM vTPM driver

From: Stefano Garzarella
Date: Thu Mar 27 2025 - 10:12:32 EST


On Thu, Mar 27, 2025 at 01:57:31PM +0200, Jarkko Sakkinen wrote:
On Thu, Mar 27, 2025 at 01:53:59PM +0200, Jarkko Sakkinen wrote:
On Thu, Mar 27, 2025 at 11:03:07AM +0100, Stefano Garzarella wrote:
> On Wed, Mar 26, 2025 at 09:30:53PM +0200, Jarkko Sakkinen wrote:
> > On Mon, Mar 24, 2025 at 11:46:48AM +0100, Stefano Garzarella wrote:

[...]

> > > +
> > > +static struct tpm_class_ops tpm_chip_ops = {
> > > + .flags = TPM_OPS_AUTO_STARTUP,
> > > + .recv = tpm_svsm_recv,
> > > + .send = tpm_svsm_send,
> > > + .cancel = tpm_svsm_cancel,
> > > + .status = tpm_svsm_status,
> > > + .req_complete_mask = 0,
> > > + .req_complete_val = 0,
> > > + .req_canceled = tpm_svsm_req_canceled,
> >
> > If this was bundled with the patch set, this would short a lot:
> >
> > https://lore.kernel.org/linux-integrity/20250326161838.123606-1-jarkko@xxxxxxxxxx/T/#u
> >
> > So maybe for v5? Including this patch does not take send_recv()
> > out of consideration, it is just smart thing to do in all cases.
> >
> > It would be probably easiest to roll out my patch together with
> > rest of the patch set.
>
> Yeah, I agree. I'll include it in this series and adapt this patch on top of
> it.

Yeah, and you could simplify to goal in the other patch set: it's about
avoiding double-copy of a buffer.

Yep, agree!


It's a totally legit argument that we can measure. So in the end this
will help out landing that too because it takes away the extra cruft
and streamlines the goal.

... IMHO there is this unwritten law for upstreaming kernel features
that goes something like "further the goals are from white papers,
closer they are to mainline" ;-)

:-D I'll make a note of it!

Thanks,
Stefano