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 <[email protected]>
>> Sent: 02 October 2025 17:44
>> To: Shameer Kolothum <[email protected]>
>> Cc: [email protected]; [email protected]; qemu-
>> [email protected]; [email protected]; Jason Gunthorpe
>> <[email protected]>; [email protected]; [email protected]; Nathan
>> Chen <[email protected]>; Matt Ochs <[email protected]>;
>> [email protected]; [email protected];
>> [email protected]; [email protected];
>> [email protected]; [email protected]; [email protected];
>> [email protected]
>> 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/[email protected]/
