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

[Jason Gunthorpe <jgg@ziepe.ca>]

On Fri, Oct 10, 2025 at 11:44:04AM -0700, dan.j.williams@intel.com wrote:
> 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.

I suspect this ins't a TSM question but an existing question if any of
the underlying CC frameworks are enabled. 

It is this stuff:

https://github.com/systemd/systemd/blob/main/src/basic/confidential-virt.c
https://github.com/systemd/systemd/commit/2572bf6a39b6c548acef07fd25f461c5a88560af

  Like the s390 detection logic, the sysfs path being checked is not labeled
  as ABI, and may change in the future. It was chosen because its
  directly tied to the kernel's detection of the realm service interface
  rather to the Trusted Security Module (TSM) which is what is being
  triggered by the device entry.

Maybe a /sys/firmware/smc/rsi file might be appropriate?

Given how small a deployed fooprint ARM CCA has right now (ie none) it
would be good to fix this ASAP so it doesn't become entrenched.

Jason