Series comparison

 RE: [RFC PATCH 0/5] hw/arm/virt: Add support for user-creatable nested SMMUv3
 > -----Original Message-----
 > From: Jason Gunthorpe <jgg@nvidia.com>
-> Sent: Thursday, February 6, 2025 5:47 PM
+> Sent: Thursday, February 6, 2025 5:59 PM
 > To: Daniel P. Berrangé <berrange@redhat.com>
 > Cc: Shameerali Kolothum Thodi
 > <shameerali.kolothum.thodi@huawei.com>; qemu-arm@nongnu.org;
 > qemu-devel@nongnu.org; eric.auger@redhat.com;
 > peter.maydell@linaro.org; nicolinc@nvidia.com; ddutile@redhat.com;
 ...
 > Jonathan Cameron <jonathan.cameron@huawei.com>;
 > zhangfei.gao@linaro.org; nathanc@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:10:32PM +0000, Daniel P. Berrangé wrote:
+> On Thu, Feb 06, 2025 at 05:54:57PM +0000, Daniel P. Berrangé wrote:
-> > On Thu, Feb 06, 2025 at 01:02:38PM -0400, Jason Gunthorpe wrote:
+> > > > We shouldn't assume any VFIO device exists in the QEMU cnofig at the
-> > > On Thu, Feb 06, 2025 at 03:07:06PM +0000, Shameerali Kolothum Thodi
+> time
-> wrote:
+> > > > we realize the virtual ssmu. I expect the SMMU may be cold plugged,
-> > > > > If we set the physical/guest SMMU relationship directly, then at the
+> while
-> > > > > time the VFIO device is plugged, we can diagnose the incorrectly
+> > > > the VFIO devices may be hot plugged arbitrarly later, and we should
-> > > > > placed VFIO device, and better reason about behaviour.
+> have
-> > > >
+> > > > the association initialized the SMMU is realized.
 > > > > Agree.
 > > >
-> > > Can you just take in a VFIO cdev FD reference on this command line:
+> > > This is not supported kernel side, you can't instantiate a vIOMMU
-> > >
+> > > without a VFIO device that uses it. For security.
 > > >  -device arm-smmuv3-accel,id=smmuv2,bus=pcie.2
 > > >
 > > > And that will lock the pSMMU/vSMMU relationship?
 > >
-> > We shouldn't assume any VFIO device exists in the QEMU cnofig at the
+> > What are the security concerns here ?
 > 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
+> You should not be able to open iommufd and manipulate iommu HW that
-> without a VFIO device that uses it. For security.
+> 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.
-I think that is fine if Qemu knows about association beforehand. During
+Not sure I get the problem with associating vSMMU with a pSMMU. Something
-vIOMMU instantiation it can cross check whether the user specified
+like an iommu instance id mentioned before,
 pSMMU <->vSMMU is correct for the device.
-Also how do we do it with multiple VF devices under a pSUMMU ? Which
+-device arm-smmuv3-accel,id=smmuv2,bus=pcie.2,host-smmu=iommu.1
-cdev fd in that case?
 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

> -----Original Message-----
> From: Jason Gunthorpe <jgg@nvidia.com>
> Sent: Thursday, February 6, 2025 5:47 PM
> To: Daniel P. Berrangé <berrange@redhat.com>
> Cc: Shameerali Kolothum Thodi
> <shameerali.kolothum.thodi@huawei.com>; qemu-arm@nongnu.org;
> qemu-devel@nongnu.org; eric.auger@redhat.com;
> peter.maydell@linaro.org; nicolinc@nvidia.com; ddutile@redhat.com;
> Linuxarm <linuxarm@huawei.com>; Wangzhou (B)
> <wangzhou1@hisilicon.com>; jiangkunkun <jiangkunkun@huawei.com>;
> Jonathan Cameron <jonathan.cameron@huawei.com>;
> zhangfei.gao@linaro.org; nathanc@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:10:32PM +0000, Daniel P. Berrangé wrote:
> > On Thu, Feb 06, 2025 at 01:02:38PM -0400, Jason Gunthorpe wrote:
> > > On Thu, Feb 06, 2025 at 03:07:06PM +0000, Shameerali Kolothum Thodi
> wrote:
> > > > > If we set the physical/guest SMMU relationship directly, then at the
> > > > > time the VFIO device is plugged, we can diagnose the incorrectly
> > > > > placed VFIO device, and better reason about behaviour.
> > > >
> > > > Agree.
> > >
> > > Can you just take in a VFIO cdev FD reference on this command line:
> > >
> > >  -device arm-smmuv3-accel,id=smmuv2,bus=pcie.2
> > >
> > > And that will lock the pSMMU/vSMMU relationship?
> >
> > 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.

I think that is fine if Qemu knows about association beforehand. During 
vIOMMU instantiation it can cross check whether the user specified
pSMMU <->vSMMU is correct for the device.

Also how do we do it with multiple VF devices under a pSUMMU ? Which
cdev fd in that case?

Thanks,
Shameer

> -----Original Message-----
> From: Jason Gunthorpe <jgg@nvidia.com>
> Sent: Thursday, February 6, 2025 5:59 PM
> To: Daniel P. Berrangé <berrange@redhat.com>
> Cc: Shameerali Kolothum Thodi
> <shameerali.kolothum.thodi@huawei.com>; qemu-arm@nongnu.org;
> qemu-devel@nongnu.org; eric.auger@redhat.com;
> peter.maydell@linaro.org; nicolinc@nvidia.com; ddutile@redhat.com;
> Linuxarm <linuxarm@huawei.com>; Wangzhou (B)
> <wangzhou1@hisilicon.com>; jiangkunkun <jiangkunkun@huawei.com>;
> Jonathan Cameron <jonathan.cameron@huawei.com>;
> zhangfei.gao@linaro.org; nathanc@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