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

Stefano Garzarella
2025-01-14T16:51:41Z

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@redhat.com> 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@ziepe.ca/ 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@mail.gmail.com/

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