Re: [PATCH v4 08/27] hw/arm/smmuv3-accel: Add set/unset_iommu_device callback

[Eric Auger <eric.auger@redhat.com>]

On 10/27/25 12:56 PM, Shameer Kolothum wrote:
> Hi Eric,
>
> Based on further off-list discussions, this needs some clarification.
>
>> -----Original Message-----
>> From: Nicolin Chen <nicolinc@nvidia.com>
>> Sent: 02 October 2025 17:44
>> To: Shameer Kolothum <skolothumtho@nvidia.com>
>> Cc: eric.auger@redhat.com; qemu-arm@nongnu.org; qemu-
>> devel@nongnu.org; peter.maydell@linaro.org; Jason Gunthorpe
>> <jgg@nvidia.com>; ddutile@redhat.com; berrange@redhat.com; Nathan
>> Chen <nathanc@nvidia.com>; Matt Ochs <mochs@nvidia.com>;
>> smostafa@google.com; wangzhou1@hisilicon.com;
>> jiangkunkun@huawei.com; jonathan.cameron@huawei.com;
>> zhangfei.gao@linaro.org; zhenzhong.duan@intel.com; yi.l.liu@intel.com;
>> shameerkolothum@gmail.com
>> Subject: Re: [PATCH v4 08/27] hw/arm/smmuv3-accel: Add
>> set/unset_iommu_device callback
> [..]
>
>> There are a couple of things going on here:
>> 1) We should not attach directly to the S2 HWPT that eventually
>>    will be shared across vSMMU instances. In other word, an S2
>>    HWPT will not be attachable for lacking of its tie to an SMMU
>>    instance and not having a VMID at all. Instead, each vIOMMU
>>    object allocated using this S2 HWPT will hold the VMID.
> The above statement is not 100% correct as per the current kernel
> and QEMU implementation. At present, VFIO core allocates an s2
> HWPT when IOMMU_HWPT_ALLOC_NEST_PARENT flag is set and
> attaches to it. 
>
> In the set_iommu_device () path, we use this s2 HWPT id to create a 
> vIOMMU and pre-allocate bypass and abort IOMMU_DOMAIN_NESTED
> HWPTs, which are ready to be attached if required.
those are s1 ones (bypass and abort) , right?
>
> On unset_iommu_device() path, we attach back to the s2 HWPT as it
> does today.
OK
>  
>> 2) A device cannot attach to a vIOMMU directly but has to attach
>>    through a proxy nested HWPT (IOMMU_DOMAIN_NESTED). To attach
>>    to an IOMMU_DOMAIN_NESTED, a vDEVICE must be allocated with a
>>    given vSID.
> Also, it became clear that we need to relax the above restriction and allow
> attaching proxy nested HWPTs without requiring a vDEVICE. This is necessary
> to handle cases where the SMMUv3 operates in global bypass or abort modes,
> as controlled by the GBPA register, which do not have any associated devices.
>
> Please see Nicolin’s kernel patch [0] that introduces this relaxation.
>
> I’ve updated this QEMU series accordingly. SMMUv3 GBPA based HWPT will
> now be attached during both reset() and GBPA update paths.

OK

Thank you for the update

Eric
>
> The commit log and documentation will also be updated to reflect above
> change.
>
> Thanks,
> Shameer
> [0] https://lore.kernel.org/linux-iommu/20251024040551.1711281-1-nicolinc@nvidia.com/