> -----Original Message----- > From: Jason Gunthorpe <j...@nvidia.com> > Sent: Thursday, February 6, 2025 6:13 PM > To: Shameerali Kolothum Thodi <shameerali.kolothum.th...@huawei.com> > Cc: Daniel P. Berrangé <berra...@redhat.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 06:04:57PM +0000, Shameerali Kolothum Thodi > wrote: > > > 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? > > Philisophically we do not permit any HW access through iommufd without > a VFIO fd to "prove" the process has rights to touch hardware. > > We don't have any way to prove the process has rights to touch the > iommu hardware seperately from VFIO. It is not. Qemu just instantiates a vSMMU and assigns the IOMMU instance id to it. > > So even if you invent an iommu ID we cannot accept it as a handle to > create viommu in iommufd. Creating the vIOMMU only happens when the user does a cold/hot plug of a VFIO device. At that time Qemu checks whether the assigned id matches with whatever the kernel tell it. Thanks, Shameer
RE: [RFC PATCH 0/5] hw/arm/virt: Add support for user-creatable nested SMMUv3
Shameerali Kolothum Thodi via Thu, 06 Feb 2025 10:19:46 -0800
- RE: [RFC PATCH 0/5] hw/arm/virt: Add support... Shameerali Kolothum Thodi via
- Re: [RFC PATCH 0/5] hw/arm/virt: Add su... Daniel P . Berrangé
- RE: [RFC PATCH 0/5] hw/arm/virt: Add su... Shameerali Kolothum Thodi via
- Re: [RFC PATCH 0/5] hw/arm/virt: Add su... Jason Gunthorpe
- Re: [RFC PATCH 0/5] hw/arm/virt: Add su... Daniel P . Berrangé
- Re: [RFC PATCH 0/5] hw/arm/virt: Add su... Jason Gunthorpe
- Re: [RFC PATCH 0/5] hw/arm/virt: Add su... Daniel P . Berrangé
- Re: [RFC PATCH 0/5] hw/arm/virt: Add su... Jason Gunthorpe
- RE: [RFC PATCH 0/5] hw/arm/virt: Add su... Shameerali Kolothum Thodi via
- Re: [RFC PATCH 0/5] hw/arm/virt: Add su... Jason Gunthorpe
- RE: [RFC PATCH 0/5] hw/arm/virt: Add su... Shameerali Kolothum Thodi via
- Re: [RFC PATCH 0/5] hw/arm/virt: Add su... Jason Gunthorpe
- Re: [RFC PATCH 0/5] hw/arm/virt: Add su... Nicolin Chen
- Re: [RFC PATCH 0/5] hw/arm/virt: Add su... Jason Gunthorpe
- Re: [RFC PATCH 0/5] hw/arm/virt: Add su... Nicolin Chen
- Re: [RFC PATCH 0/5] hw/arm/virt: Add su... Jason Gunthorpe
- Re: [RFC PATCH 0/5] hw/arm/virt: Add su... Nicolin Chen
- Re: [RFC PATCH 0/5] hw/arm/virt: Add su... Jason Gunthorpe
- RE: [RFC PATCH 0/5] hw/arm/virt: Add su... Shameerali Kolothum Thodi via
- Re: [RFC PATCH 0/5] hw/arm/virt: Add su... Daniel P . Berrangé
- RE: [RFC PATCH 0/5] hw/arm/virt: Add su... Shameerali Kolothum Thodi via