Re: [PATCH 3/3] x86/sev: add a SVSM vTPM platform device

[Stefano Garzarella]

On Tue, Jan 14, 2025 at 09:07:20AM -0400, Jason Gunthorpe wrote:
> On Tue, Jan 14, 2025 at 11:42:34AM +0100, Stefano Garzarella wrote:
> > Hi Jarkko,
> >
> > On Thu, 19 Dec 2024 at 17:07, Stefano Garzarella <sgarzare@xxxxxxxxxx> wrote:
> > >
> > > On Thu, Dec 19, 2024 at 05:40:58PM +0200, Jarkko Sakkinen wrote:
> > > >On Thu Dec 19, 2024 at 5:35 PM EET, Stefano Garzarella wrote:
> > > >> So to use them directly in sev, we would have to move these definitions
> > > >> into include/linux/tpm.h or some other file in inlcude/. Is this
> > > >> acceptable for TPM maintainers?
> > > >
> > > >There's only me.
> > > >
> > > >I don't know.
> > > >
> > > >What you want to put to include/linux/tpm.h anyway?
> > >
> > > At least tpmm_chip_alloc(), tpm2_probe(), and tpm_chip_register()
>
> The intention was that tpm drivers would be under drivers/char/tpm/
>
> Do you really need to put your tpm driver in arch code? Historically
> drivers in arch code have not worked out so well.

I think I misinterpreted your answer here: https://lore.kernel.org/linux-coco/20241211150048.GJ1888283@xxxxxxxx/ when I asked about calling "the code in
tpm_platform_probe() directly in sev".

I totally agree that it's not a good idea, which is why I had proposed
this: https://lore.kernel.org/linux-coco/CAGxU2F7QjQTnXsqYeKc0q03SQCoW+BHbej9Q2Z8gxbgu-3O2fA@xxxxxxxxxxxxxx/

  Otherwise we need an intermediate module in drivers/char/tpm. Here we
  have 2 options:
  1. continue as James did by creating a platform_device.
  2. or we could avoid this by just exposing a registration API invoked by
  sev to specify the send_recv() callback to use. I mean something like
  renaming tpm_platform_probe() in tpm_platform_register(), and call it in
  snp_init_platform_device().

I'm thinking of sending an RFC implementing 2 so we can discuss there,
it should be a good compromise between your suggestions and James'
version.

> Meaning that you'd export some of your arch stuff for the tpm driver
> to live in its natural home

@Tom do you think we can eventually expose sev API like
svsm_perform_call_protocol(), svsm_get_caa(), etc.?

Maybe option 2 that I proposed could avoid this and have sev register a
simple callback so that we avoid exposing these internal APIs.

Thanks,
Stefano