Re: [PATCH v7 13/13] Documentation: userspace-api: iommufd: Update vIOMMU

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2024/11/14 08:18, Nicolin Chen wrote:
On Tue, Nov 12, 2024 at 09:15:02PM +0800, Yi Liu wrote:
On 2024/11/6 04:04, Nicolin Chen wrote:
+5. IOMMUFD_OBJ_VIOMMU can be only manually created via the IOMMU_VIOMMU_ALLOC
+   uAPI, provided a dev_id (for the device's physical IOMMU to back the vIOMMU)
+   and an hwpt_id (to associate the vIOMMU to a nesting parent HWPT_PAGING). The
+   iommufd core will link the vIOMMU object to the struct iommu_device that the
+   struct device is behind.

It looks to be reasonable to share the viommu_obj between devices behind
the same physical IOMMU. This design seems no enforcement for it. So it's
all up to userspace from what I got. :)

It enforces at the vDEVICE allocation:
	if (viommu->iommu_dev != __iommu_get_iommu_dev(idev->dev)) {
		return -EINVAL;

this matches the device and the viommu.


Yet, assuming you are referring to creating two vIOMMUs per VM for
two devices behind the same IOMMU (?), there is no enforcement..

right, but not limited to two vIOMMUs as the viommu_obj is not instanced
per vIOMMUs.

The suggested way for VMM, just like two devices sharing the same
s2 parent hwpt, is to share the vIOMMU object.

so the user would try to create vDevices with a given viommu_obj until
failure, then it would allocate another viommu_obj for the failed device.
is it? sounds reasonable.

--
Regards,
Yi Liu




[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux