Alexey Kardashevskiy <aik@xxxxxxx> writes:
> On 27/5/25 21:48, Aneesh Kumar K.V wrote:
>> Alexey Kardashevskiy <aik@xxxxxxx> writes:
>>
>>> On 27/5/25 01:44, Aneesh Kumar K.V wrote:
>>>> Alexey Kardashevskiy <aik@xxxxxxx> writes:
>>>>
>>>>> On 26/5/25 15:05, Aneesh Kumar K.V wrote:
>>>>>> Xu Yilun <yilun.xu@xxxxxxxxxxxxxxx> writes:
>>>>>>
>>>>>>> On Tue, May 20, 2025 at 12:47:05PM +0530, Aneesh Kumar K.V wrote:
>>>>>>>> Xu Yilun <yilun.xu@xxxxxxxxxxxxxxx> writes:
>>>>>>>>
>>>>>>>>> On Thu, May 15, 2025 at 10:47:31PM -0700, Dan Williams wrote:
>>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>> To clarify, this commit message is staled. We are proposing existing to
>>>>>>>>> QEMU, then pass to TSM through IOMMUFD VDEVICE.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Can you share the POC code/git repo implementing that? I am looking for
>>>>>>>> pci_tsm_bind()/pci_tsm_unbind() example usage.
>>>>>>>
>>>>>>> The usage of these kAPIs should be in IOMMUFD, that's what I'm doing for
>>>>>>> Stage 2 patchset. I need to rebase this series, adopt suggestions from
>>>>>>> Jason, and make TDX Connect work to verify, so need more time...
>>>>>>>
>>>>>>
>>>>>> Since the bind/unbind operations are PCI-specific callbacks, and iommufd
>>>>>
>>>>> Not really, it is PCI-specific in TSM (for DOE) but since IOMMUFD is not doing any of that, it can work with struct device (not pci_dev). Thanks,
>>>>>
>>>>
>>>> Ok, something like this? and iommufd will call tsm_bind()?
>>>
>>> yeah, I guess, there is a couple of places like this
>>>
>>> git grep pci_dev drivers/iommu/iommufd/
>>>
>>> drivers/iommu/iommufd/device.c: struct pci_dev *pdev = to_pci_dev(idev->dev);
>>> drivers/iommu/iommufd/eventq.c: struct pci_dev *pdev = to_pci_dev(dev);
>>>
>>> Although I do not see any compelling reason to have pci_dev in the TSM API, struct device should just work and not spill any PCI details to IOMMUFD but whatever... Thanks,
>>
>> Getting the kvm reference is tricky here. Also the locking while
>> updating vdevice->tsm_bound needs some solution. Here is what I am
>> improving. Are you also planning something similar?
>
>
> At the moment I am planning getting/holding the KVM reference in the TSM:
>
> https://lore.kernel.org/r/20250218111017.491719-15-aik@xxxxxxx
>
> but may push it even further to the AMD TSM (CCP, the firmware driver) as this where I actually need the kvm struct to get GCTX+ASID from kvm_svm; Intel folks have a similar intimate knowledge sharing between kvm_intel and TDX-connect. Thanks,
So you won't be able to work with already available kvm reference in
viommu alloc? I will send the tsm_bind changes i have done so that we
can share the diff against that with explanation of why things can't
work that way?
-aneesh
