Re: [PATCH v5 3/9] mshv: Introduce basic mshv bridge device for VFIO to build upon

[Jacob Pan]

Hi Jason,

On Thu, 3 Sep 2026 11:42:36 -0300
Jason Gunthorpe <jgg@xxxxxxxxxx> 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/20260902235609.GG2890729@xxxxxxxx/
> 
> 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