Dan Williams <dan.j.williams@xxxxxxxxx> writes:
> From: Xu Yilun <yilun.xu@xxxxxxxxxxxxxxx>
>
> Add kAPIs pci_tsm_{bind,unbind,guest_req}() for PCI devices.
>
> pci_tsm_bind/unbind() are supposed to be called by kernel components
> which manages the virtual device. The verb 'bind' means VMM does extra
> configurations to make the assigned device ready to be validated by
> CoCo VM as TDI (TEE Device Interface). Usually these configurations
> include assigning device ownership and MMIO ownership to CoCo VM, and
> move the TDI to CONFIG_LOCKED TDISP state by LOCK_INTERFACE_REQUEST
> TDISP message. The detailed operations are specific to platform TSM
> firmware so need to be supported by vendor TSM drivers.
>
> pci_tsm_guest_req() supports a channel for CoCo VM to directly talk
> to TSM firmware about further TDI operations after TDI is bound, e.g.
> get device interface report, certifications & measurements. So this kAPI
> is supposed to be called from KVM vmexit handler.
>
> A problem to solve here is the TDI operation lock. The TDI operations
> involve TDISP message communication with devices, which is transferred
> via PF0's DOE. When multiple VFs or MFDs are involved at the same time,
> these messages are not intended to interleave with each other. So
> serialize all TSM operations of one slot by holding the DSM device (PF0)
> pci_tsm.lock.
>
> Add a struct pci_tdi to represent the TDI context, which is common to
> all PFs/VFs/MFDs so embedded it in struct pci_tsm. The appearing of the
> tsm::tdi means the device is in BOUND state and vice versa. So no extra
> enum pci_tsm_state value is added for bind. That also means the access
> to tsm::tdi must with the DEM device (PF0) TSM lock.
>
Now that we have guest kernel also susing tsm_register, should we have
patch [PATCH 01/13] coco/tsm: Introduce a core device for TEE Security
Managers add tsm-core.c to drivers/virt/coco/ ?
Something similar to https://git.gitlab.arm.com/linux-arm/linux-cca/-/commit/2e83f71b4b3a71ee56a77b45f5214b6223dda3b5
-aneesh
