On 29/5/25 23:34, Aneesh Kumar K.V wrote:
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?
By "already" you mean 2/3 you posted in reply to this, do not you? :)
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?
I am missing the point in having a kvm pointer in iommufd which does not do anything with the kvm struct, fget(kvm_fd) should be enough. Thanks,
-aneesh
--
Alexey
