On 1/15/25 21:01, Jason Gunthorpe wrote:
On Wed, Jan 15, 2025 at 11:57:05PM +1100, Alexey Kardashevskiy wrote:
On 15/1/25 00:35, Jason Gunthorpe wrote:
On Tue, Jun 18, 2024 at 07:28:43AM +0800, Xu Yilun wrote:
is needed so the secure world can prepare anything it needs prior to
starting the VM.
OK. From Dan's patchset there are some touch point for vendor tsm
drivers to do secure world preparation. e.g. pci_tsm_ops::probe().
Maybe we could move to Dan's thread for discussion.
https://lore.kernel.org/linux-
coco/173343739517.1074769.13134786548545925484.stgit@dwillia2-
xfh.jf.intel.com/
I think Dan's series is different, any uapi from that series should
not be used in the VMM case. We need proper vfio APIs for the VMM to
use. I would expect VFIO to be calling some of that infrastructure.
Something like this experiment?
https://github.com/aik/linux/commit/
ce052512fb8784e19745d4cb222e23cabc57792e
Yeah, maybe, though I don't know which of vfio/iommufd/kvm should be
hosting those APIs, the above does seem to be a reasonable direction.
When the various fds are closed I would expect the kernel to unbind
and restore the device back.
I am curious about the value of tsm binding against an iomnufd_vdevice
instead of the physical iommufd_device.
It is likely that the kvm pointer should be passed to iommufd during the
creation of a viommu object. If my recollection is correct, the arm
smmu-v3 needs it to obtain the vmid to setup the userspace event queue:
struct iommufd_viommu *arm_vsmmu_alloc(struct device *dev,
struct iommu_domain *parent,
struct iommufd_ctx *ictx,
unsigned int viommu_type)
{
[...]
/* FIXME Move VMID allocation from the S2 domain allocation to
here */
vsmmu->vmid = s2_parent->s2_cfg.vmid;
return &vsmmu->core;
}
Intel TDX connect implementation also needs a reference to the kvm
pointer to obtain the secure EPT information. This is crucial because
the CPU's page table must be shared with the iommu. I am not sure
whether the amd architecture has a similar requirement.
---
baolu
