Re: [PATCH v4 19/27] hw/arm/smmuv3-accel: Install S1 bypass hwpt on reset

[Nicolin Chen <nicolinc@nvidia.com>]

On Wed, Oct 29, 2025 at 11:19:59AM -0700, Shameer Kolothum wrote:
> > According to SMMU spec 6.3 GBPA register's Additional information:
> >  - If SMMU_IDR1.ATTR_TYPES_OVR == 0, MTCFG, SHCFG, ALLOCCFG are
> >    effectively fixed as Use incoming and it is IMPLEMENTATION
> >    SPECIFIC whether these fields read as zero or a previously
> >    written value. In this case, MemAttr reads as UNKNOWN.
> >  - If SMMU_IDR1.ATTR_PERMS_OVR == 0, INSTCFG and PRIVCFG are
> >    effectively fixed as Use incoming and it is IMPLEMENTATION
> >    SPECIFIC whether these fields read as zero or a previously
> >    written value.
> > 
> > On the other hand, QEMU seems to set both OVR fields to 0, so all
> > those "other attributes" wouldn't be necessarily forwarded to the
> > kernel?
> 
> OK. Based on the QEMU OVR value, GBPA now resets to 0x1000, meaning
> SHCFG = 0b01 (Use incoming). However, in the current vSTE bypass/abort
> cases, SHCFG is set to 0b00 (Non-shareable).

Ah, no, my bad. SHCFG will need to be forwarded, if the hw_info
call reports that host SMMU has SMMU_IDR1.ATTR_TYPES_OVR == 1.

So, the SHCFG=incoming has been the default case, but to support
a non-incoming configuration, kernel needs to allow SHCFG in the
vSTE.

> However, I think the SHCFG will be overridden by S2FWB.

I don't think S2FWB affects SHCFG. SHCFG has been set by kernel:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c?h=v6.18-rc3#n1681

> So, I don’t think we need to modify anything at this stage. In general,
> though, the kernel might need to propagate some of these attributes,
> possibly INSTCFG and PRIVCFG, since they are not overridden by S2FWB ?

Yes. I have drafted a few patches, and will send soon.

Thanks
Nicolin