> -----Original Message----- > From: Nicolin Chen <[email protected]> > Sent: Monday, March 3, 2025 5:05 PM > To: Shameerali Kolothum Thodi <[email protected]> > Cc: Eric Auger <[email protected]>; [email protected]; Peter > Maydell <[email protected]>; Jason Gunthorpe <[email protected]>; > Daniel P. Berrangé <[email protected]>; [email protected]; > [email protected]; Linuxarm <[email protected]>; Wangzhou > (B) <[email protected]>; jiangkunkun <[email protected]>; > Jonathan Cameron <[email protected]>; > [email protected] > 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/[email protected]/ [1] https://lore.kernel.org/linux-arm-kernel/[email protected]/
