> -----Original Message----- > From: Daniel P. Berrangé <berra...@redhat.com> > Sent: Friday, February 7, 2025 10:32 AM > To: Shameerali Kolothum Thodi <shameerali.kolothum.th...@huawei.com> > Cc: Nicolin Chen <nicol...@nvidia.com>; Jason Gunthorpe > <j...@nvidia.com>; qemu-...@nongnu.org; qemu-devel@nongnu.org; > eric.au...@redhat.com; peter.mayd...@linaro.org; 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 Fri, Feb 07, 2025 at 10:21:17AM +0000, Shameerali Kolothum Thodi > wrote: > > > > > > > -----Original Message----- > > > From: Nicolin Chen <nicol...@nvidia.com> > > > Sent: Thursday, February 6, 2025 8:33 PM > > > To: Shameerali Kolothum Thodi > > > <shameerali.kolothum.th...@huawei.com>; Daniel P. Berrangé > > > <berra...@redhat.com>; Jason Gunthorpe <j...@nvidia.com> > > > Cc: qemu-...@nongnu.org; qemu-devel@nongnu.org; > > > eric.au...@redhat.com; peter.mayd...@linaro.org; > 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 02:22:01PM -0400, Jason Gunthorpe wrote: > > > > On Thu, Feb 06, 2025 at 06:18:14PM +0000, Shameerali Kolothum > Thodi > > > wrote: > > > > > > > > > > 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. > > > > > > > > This is not hard up until the guest is started. If you boot a guest > > > > without a backing viommu iommufd object then there will be some > more > > > > complexities. > > > > > > Yea, I imagined that things would be complicated with hotplugs.. > > > > > > On one hand, I got the part that we need some fixed link forehand > > > to ease migration/hotplugs. > > > > > > On the other hand, all IOMMUFD ioctls need a VFIO device FD, which > > > brings the immediate attention that we cannot even decide vSMMU's > > > capabilities being reflected in its IDR/IIDR registers, without a > > > coldplug device -- if we boot a VM (one vSMMU<->pSMMU) with only a > > > hotplug device, the IOMMU_GET_HW_INFO cannot be done during > guest > > > > Right. I forgot about the call to smmu_dev_get_info() during the reset. > > That means we need at least one dev per Guest SMMU during Guest > > boot :( > > That's pretty unpleasant as a usage restriction. It sounds like there > needs to be a way to configure & control the vIOMMU independantly of > attaching a specific VFIO device.
Yes, that would be ideal. Just wondering whether we can have something like the vfio_register_iommu_driver() for iommufd subsystem by which it can directly access iommu drivers ops(may be a restricted set). Not sure about the layering violations and other security issues with that... Thanks, Shameer
