On Wed, Oct 29, 2025 at 10:28:35PM -0700, Nicolin Chen wrote:
> 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
Hmm, the table "13.5 Summary of attribute/permission configuration
fields" in SMMU spec doesn't seem to show the complete picture..
I found the pseudo code in ARMv8 spec telling the details:
shared/translation/attrs/S2AttrDecode
// S2AttrDecode()
// ==============
// Converts the Stage 2 attribute fields into orthogonal attributes and hints
MemoryAttributes S2AttrDecode(bits(2) SH, bits(4) attr, AccType acctype)
MemoryAttributes memattrs;
apply_force_writeback = HaveStage2MemAttrControl() && HCR_EL2.FWB ==
'1';
// Device memory
if (apply_force_writeback && attr<2> == '0') || attr<3:2> == '00' then
memattrs.memtype = MemType_Device;
case attr<1:0> of
when '00' memattrs.device = DeviceType_nGnRnE;
when '01' memattrs.device = DeviceType_nGnRE;
when '10' memattrs.device = DeviceType_nGRE;
when '11' memattrs.device = DeviceType_GRE;
// Normal memory
elsif apply_force_writeback then
if attr<2> == '1' then
memattrs.memtype = MemType_Normal;
memattrs.inner.attrs = attr<1:0>;
memattrs.outer.attrs = attr<1:0>;
memattrs.shareable = SH<1> == '1';
memattrs.outershareable = SH == '10';
elsif attr<1:0> != '00' then
memattrs.memtype = MemType_Normal;
memattrs.outer = S2ConvertAttrsHints(attr<3:2>, acctype);
memattrs.inner = S2ConvertAttrsHints(attr<1:0>, acctype);
memattrs.shareable = SH<1> == '1';
memattrs.outershareable = SH == '10';
else
memattrs = MemoryAttributes UNKNOWN; // Reserved
return MemAttrDefaults(memattrs);
So, it seems that you are right. SHCFG will be overridden by S2FWB.
However, we have CPU like Grace that doesn't have S2FWB..
Nicolin
