> -----Original Message----- > From: Nicolin Chen <nicol...@nvidia.com> > Sent: Monday, March 3, 2025 5:05 PM > To: Shameerali Kolothum Thodi <shameerali.kolothum.th...@huawei.com> > Cc: Eric Auger <eric.au...@redhat.com>; ddut...@redhat.com; Peter > Maydell <peter.mayd...@linaro.org>; Jason Gunthorpe <j...@nvidia.com>; > Daniel P. Berrangé <berra...@redhat.com>; qemu-...@nongnu.org; > qemu-devel@nongnu.org; Linuxarm <linux...@huawei.com>; Wangzhou > (B) <wangzh...@hisilicon.com>; jiangkunkun <jiangkun...@huawei.com>; > Jonathan Cameron <jonathan.came...@huawei.com>; > zhangfei....@linaro.org > Subject: Re: [RFC PATCH 0/5] hw/arm/virt: Add support for user-creatable > nested SMMUv3 > > On Mon, Mar 03, 2025 at 03:21:57PM +0000, Shameerali Kolothum Thodi > wrote: > > I am working on the above now and have quick question to you😊. > > > > Looking at the smmu_dev_attach_viommu() fn here[0], > > it appears to do the following: > > > > 1. Alloc a s2_hwpt if not allocated already and attach it. > > 2. Allocate abort and bypass hwpt > > 3. Attach bypass hwpt. > > > > I didn't get why we are doing the step 3 here. To me it looks like, > > when we attach the s2_hwpt(ie, the nested parent domain attach), > > the kernel will do, > > > > arm_smmu_attach_dev() > > arm_smmu_make_s2_domain_ste() > > > > It appears through step 3, we achieve the same thing again. > > > > Or it is possible I missed something obvious here. > > Because a device cannot attach to a vIOMMU object directly, but > only via a proxy hwpt_nested. So, this bypass hwpt gives us the > port to associate the device to the vIOMMU, before a vDEVICE or > a "translate" hwpt_nested is allocated. > > Currently it's the same because an S2 parent hwpt holds a VMID, > so we could just attach the device to the S2 hwpt for the same > STE configuration as attaching the device to the proxy bypass > hwpt. Yet, this will change in the future after letting vIOMMU > objects hold their own VMIDs to share a common S2 parent hwpt > that won't have a VMID, i.e. arm_smmu_make_s2_domain_ste() will > need the vIOMMU object to get the VMID for STE. > > I should have added a few lines of comments there :)
Ok. Thanks for the explanation. I will keep it then and add few comments to make it clear. Do you have an initial implementation of the above with vIOMMU object holding the VMIDs to share? Actually I do have a dependency on that for my KVM pinned VMID series[0] where it was suggested that the VMID should associated with a vIOMMU object rather than the IOMMUFD context I used in there. And Jason mentioned about the work involved to do that here[1]. Appreciate if you could share if any progress is made on that so that I can try to rebase that KVM Pinned series on top of that and give it a try. Thanks, Shameer [0] https://lore.kernel.org/linux-iommu/20240208151837.35068-1-shameerali.kolothum.th...@huawei.com/ [1] https://lore.kernel.org/linux-arm-kernel/20241129150628.gg1253...@nvidia.com/
