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 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