| 1 | 1 | ||
|---|---|---|---|
| 2 | > -----Original Message----- | 2 | > -----Original Message----- |
| 3 | > From: Jason Gunthorpe <jgg@nvidia.com> | 3 | > From: Jason Gunthorpe <jgg@nvidia.com> |
| 4 | > Sent: Friday, January 31, 2025 2:24 PM | 4 | > Sent: Thursday, February 6, 2025 6:13 PM |
| 5 | > To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com> | 5 | > To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com> |
| 6 | > Cc: Daniel P. Berrangé <berrange@redhat.com>; qemu-arm@nongnu.org; | 6 | > Cc: Daniel P. Berrangé <berrange@redhat.com>; qemu-arm@nongnu.org; |
| 7 | > qemu-devel@nongnu.org; eric.auger@redhat.com; | 7 | > qemu-devel@nongnu.org; eric.auger@redhat.com; |
| 8 | > peter.maydell@linaro.org; nicolinc@nvidia.com; ddutile@redhat.com; | 8 | > peter.maydell@linaro.org; nicolinc@nvidia.com; ddutile@redhat.com; |
| 9 | > Linuxarm <linuxarm@huawei.com>; Wangzhou (B) | 9 | > Linuxarm <linuxarm@huawei.com>; Wangzhou (B) |
| 10 | > <wangzhou1@hisilicon.com>; jiangkunkun <jiangkunkun@huawei.com>; | 10 | > <wangzhou1@hisilicon.com>; jiangkunkun <jiangkunkun@huawei.com>; |
| 11 | > Jonathan Cameron <jonathan.cameron@huawei.com>; | 11 | > Jonathan Cameron <jonathan.cameron@huawei.com>; |
| 12 | > zhangfei.gao@linaro.org; Nathan Chen <nathanc@nvidia.com> | 12 | > zhangfei.gao@linaro.org; nathanc@nvidia.com |
| 13 | > Subject: Re: [RFC PATCH 0/5] hw/arm/virt: Add support for user-creatable | 13 | > Subject: Re: [RFC PATCH 0/5] hw/arm/virt: Add support for user-creatable |
| 14 | > nested SMMUv3 | 14 | > nested SMMUv3 |
| 15 | > | 15 | > |
| 16 | > On Fri, Jan 31, 2025 at 09:33:16AM +0000, Shameerali Kolothum Thodi | 16 | > On Thu, Feb 06, 2025 at 06:04:57PM +0000, Shameerali Kolothum Thodi |
| 17 | > wrote: | 17 | > wrote: |
| 18 | > > > Some kind of hot plug smmu would have to create a vSMMU without | ||
| 19 | > any | ||
| 20 | > > > kernel backing and then later bind it to a kernel implementation. | ||
| 21 | > > | ||
| 22 | > > Not sure I get the problem with associating vSMMU with a pSMMU. | ||
| 23 | > Something | ||
| 24 | > > like an iommu instance id mentioned before, | ||
| 25 | > > | ||
| 26 | > > -device arm-smmuv3-accel,id=smmuv2,bus=pcie.2,host-smmu=iommu.1 | ||
| 27 | > > | ||
| 28 | > > This can realize the vSMMU without actually creating a vIOMMU in kernel. | ||
| 29 | > > And when the dev gets attached/realized, check (GET_HW_INFO)the | ||
| 30 | > specified | ||
| 31 | > > iommu instance id matches or not. | ||
| 32 | > > | ||
| 33 | > > Or the concern here is exporting an iommu instance id to user space? | ||
| 18 | > | 34 | > |
| 19 | > > And Qemu does some checking to make sure that the device is indeed | 35 | > Philisophically we do not permit any HW access through iommufd without |
| 20 | > associated | 36 | > a VFIO fd to "prove" the process has rights to touch hardware. |
| 21 | > > with the specified phys-smmuv3. This can be done going through the | ||
| 22 | > sysfs path checking | ||
| 23 | > > which is what I guess libvirt is currently doing to populate the topology. | ||
| 24 | > So basically | ||
| 25 | > > Qemu is just replicating that to validate again. | ||
| 26 | > | 37 | > |
| 27 | > I would prefer that iommufd users not have to go out to sysfs.. | 38 | > We don't have any way to prove the process has rights to touch the |
| 39 | > iommu hardware seperately from VFIO. | ||
| 40 | |||
| 41 | It is not. Qemu just instantiates a vSMMU and assigns the IOMMU | ||
| 42 | instance id to it. | ||
| 43 | |||
| 28 | > | 44 | > |
| 29 | > > Or another option is extending the IOMMU_GET_HW_INFO IOCTL to | 45 | > So even if you invent an iommu ID we cannot accept it as a handle to |
| 30 | > return the phys | 46 | > create viommu in iommufd. |
| 31 | > > smmuv3 base address which can avoid going through the sysfs. | ||
| 32 | > | ||
| 33 | > It also doesn't seem great to expose a physical address. But we could | ||
| 34 | > have an 'iommu instance id' that was a unique small integer? | ||
| 35 | 47 | ||
| 36 | Ok. But how the user space can map that to the device? | 48 | Creating the vIOMMU only happens when the user does a cold/hot plug of |
| 37 | 49 | a VFIO device. At that time Qemu checks whether the assigned id matches | |
| 38 | Something like, | 50 | with whatever the kernel tell it. |
| 39 | /sys/bus/pci/devices/0000:7d:00.1/iommu/instance.X ? | ||
| 40 | 51 | ||
| 41 | Thanks, | 52 | Thanks, |
| 42 | Shameer | 53 | Shameer | diff view generated by jsdifflib |