Hi Jason, On Thu, 3 Sep 2026 11:42:36 -0300 Jason Gunthorpe <[email protected]> wrote:
> On Wed, Sep 02, 2026 at 11:19:05AM -0700, Jacob Pan wrote: > > > If we do want to support this kvm-vfio bridge semantics beyond kvm, > > maybe this should be abstracted as a generic VFIO "hypervisor > > partition" association, with hypervisor-specific get/put callbacks, > > rather than adding an MSHV-only copy of the KVM hook. > > +Alex > > I don't like this patch at all. > > I think we should try to harmonize all these sort of "external" cases > as best we can. mshv, confidential compute, xen, etc all have a very > similar shape. > > I am discussing here with Aneesh an approach to use the viommu almost > exclusively for this. > > https://lore.kernel.org/all/[email protected]/ > > Can you imagine a way to do that for your stuff? > > In that case I imagine the iommufd vdevice create is what attaches the > vfio device to the partition, not a seperate ioctl over in some other > driver. When the viommu is created it knows what partition it is > affiliated with because it took in a FD that describes that partition. Yes, viommu/vdevice model maps well in my POC/RFC(WIP) without new ioctls. vdevice is attached to the vm partition via viommu (holds vm_fd). i.e. struct iommu_vdevice_alloc alloc = { .size = sizeof(alloc), .viommu_id = viommu_id, .dev_id = dev_id, .virt_id = vm_device_id, //vmm assigned }; int rc; rc = do_ioctl(iommufd, IOMMU_VDEVICE_ALLOC, &alloc, "IOMMU_VDEVICE_ALLOC"); In our case, we don't need a vdevice_init op since all we need is the virt_id, hyperv iommu driver will retrieved the vmm assigned logical device ID (virt_id) by existing API: static int hyperv_iommu_external_attach_dev(struct iommu_domain *domain, struct device *dev, struct iommu_domain *old) { ret = iommufd_viommu_get_vdev_id(external_domain->viommu, dev, &vdev_id); Then use vdev_id for the hypercall to attach external domain. I currently have a new IOMMU_VIOMMU_TYPE_MSHV with: /** * struct iommu_viommu_mshv - Microsoft Hypervisor virtual IOMMU * (IOMMU_VIOMMU_TYPE_MSHV) * @vm_fd: MSHV partition file descriptor * @flags: Must be 0 * @__reserved: Must be 0 */ struct iommu_viommu_mshv { __s32 vm_fd; __u32 flags; __aligned_u64 __reserved; }; That is MSHV-specific only because the fd validation and partition-ID lookup are MSHV-specific today. I think this could be generalized later into a common "external/hypervisor partition" vIOMMU type with driver-specific fd validation/get/put semantics. Thanks, Jacob
