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
