> -----Original Message----- > From: Jason Gunthorpe <j...@nvidia.com> > Sent: Thursday, February 6, 2025 5:59 PM > To: Daniel P. Berrangé <berra...@redhat.com> > Cc: Shameerali Kolothum Thodi > <shameerali.kolothum.th...@huawei.com>; qemu-...@nongnu.org; > qemu-devel@nongnu.org; eric.au...@redhat.com; > peter.mayd...@linaro.org; nicol...@nvidia.com; ddut...@redhat.com; > Linuxarm <linux...@huawei.com>; Wangzhou (B) > <wangzh...@hisilicon.com>; jiangkunkun <jiangkun...@huawei.com>; > Jonathan Cameron <jonathan.came...@huawei.com>; > zhangfei....@linaro.org; nath...@nvidia.com > Subject: Re: [RFC PATCH 0/5] hw/arm/virt: Add support for user-creatable > nested SMMUv3 > > On Thu, Feb 06, 2025 at 05:54:57PM +0000, Daniel P. Berrangé wrote: > > > > We shouldn't assume any VFIO device exists in the QEMU cnofig at the > time > > > > we realize the virtual ssmu. I expect the SMMU may be cold plugged, > while > > > > the VFIO devices may be hot plugged arbitrarly later, and we should > have > > > > the association initialized the SMMU is realized. > > > > > > This is not supported kernel side, you can't instantiate a vIOMMU > > > without a VFIO device that uses it. For security. > > > > What are the security concerns here ? > > You should not be able to open iommufd and manipulate iommu HW that > you don't have a VFIO descriptor for, including creating physical > vIOMMU resources, allocating command queues and whatever else. > > Some kind of hot plug smmu would have to create a vSMMU without any > kernel backing and then later bind it to a kernel implementation.
Not sure I get the problem with associating vSMMU with a pSMMU. Something like an iommu instance id mentioned before, -device arm-smmuv3-accel,id=smmuv2,bus=pcie.2,host-smmu=iommu.1 This can realize the vSMMU without actually creating a vIOMMU in kernel. And when the dev gets attached/realized, check (GET_HW_INFO)the specified iommu instance id matches or not. Or the concern here is exporting an iommu instance id to user space? Thanks, Shameer
