Re: [RFC PATCH v1 11/38] KVM: arm64: CCA: register host tsm platform device

[<dan.j.williams@intel.com>]

Jeremy Linton wrote:
> On 10/10/25 10:30 AM, Jason Gunthorpe wrote:
> > On Fri, Oct 10, 2025 at 10:28:36AM -0500, Jeremy Linton wrote:
> > 
> >>> So you could use auxiliary_device, you'd consider SMC itself to be the
> >>> shared HW block and all the auxiliary drivers are per-subsystem
> >>> aspects of that shared SMC interface. It is not a terrible fit for
> >>> what it was intended for at least.
> >>
> >> Turns out that changing any of this, will at the moment break systemd's
> >> confidential vm detection, because they wanted the earliest indicator the
> >> guest was capable and that turned out to be this platform device.
> > 
> > Having systemd detect a software created platform device sounds
> > compltely crazy, don't do that. Make a proper sysfs uapi for such a
> > general idea please.
> 
> Yes, I agree, its just at the time the statment was around what is the 
> most reliable early indicator, and since there isn't a hwcap or anything 
> that ended up being the choice, as disgusting as it is.
> 
> Presumably once all this works out the sysfs/api surface will be more 
> 'defined'

It has definition today.

All guest-side TSM drivers currently call tsm_report_register(), that
establishes /sys/kernel/config/tsm/report which is the common cross-arch
transport for retrieving CVM launch attestation reports.

In the TEE I/O patches [1] a /sys/class/tsm/tsmX device will be created
by all platforms that support TEE I/O. However, systemd would need to be
careful to differentiate host-side TSMs vs guest-side, and that is only
possible when the TSM supports TEE I/O.

I would be open to adding a simple attribute to that class device for
this common "am I a CVM" question for systemd. Would just need to update
all the CVM guest drivers to register that class device in the non TEE
I/O case.

[1]: http://lore.kernel.org/20250911235647.3248419-2-dan.j.williams@intel.com