> -----Original Message----- > From: Jason Gunthorpe <[email protected]> > Sent: Thursday, February 6, 2025 6:13 PM > To: Shameerali Kolothum Thodi <[email protected]> > Cc: Daniel P. Berrangé <[email protected]>; [email protected]; > [email protected]; [email protected]; > [email protected]; [email protected]; [email protected]; > Linuxarm <[email protected]>; Wangzhou (B) > <[email protected]>; jiangkunkun <[email protected]>; > Jonathan Cameron <[email protected]>; > [email protected]; [email protected] > 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
