Re: [PATCH v8 12/14] iommu/arm-smmu-v3: Introduce struct arm_smmu_vmaster

From: Jason Gunthorpe
Date: Mon Mar 17 2025 - 11:50:50 EST


On Tue, Mar 11, 2025 at 10:43:08AM -0700, Nicolin Chen wrote:
> > > +int arm_smmu_attach_prepare_vmaster(struct arm_smmu_attach_state *state,
> > > + struct arm_smmu_nested_domain *nested_domain)
> > > +{
> > > + struct arm_smmu_vmaster *vmaster;
> > > + unsigned long vsid;
> > > + int ret;
> > > +
> > > + iommu_group_mutex_assert(state->master->dev);
> > > +
> > > + /* Skip invalid vSTE */
> > > + if (!(nested_domain->ste[0] & cpu_to_le64(STRTAB_STE_0_V)))
> > > + return 0;
> >
> > Ok, and we don't need to set 'state->vmaster' in this case because we
> > only report stage-1 faults back to the vSMMU?
>
> This is a good question that I didn't ask myself hard enough..
>
> I think we should probably drop it. An invalid STE should trigger
> a C_BAD_STE event that is in the supported vEVENT list. I'll run
> some test before removing this line from v9.

It won't trigger C_BAD_STE, recall Robin was opposed to thatm so we have this:

static void arm_smmu_make_nested_domain_ste(
struct arm_smmu_ste *target, struct arm_smmu_master *master,
struct arm_smmu_nested_domain *nested_domain, bool ats_enabled)
{
unsigned int cfg =
FIELD_GET(STRTAB_STE_0_CFG, le64_to_cpu(nested_domain->ste[0]));

/*
* Userspace can request a non-valid STE through the nesting interface.
* We relay that into an abort physical STE with the intention that
* C_BAD_STE for this SID can be generated to userspace.
*/
if (!(nested_domain->ste[0] & cpu_to_le64(STRTAB_STE_0_V)))
cfg = STRTAB_STE_0_CFG_ABORT;

So, in the case of a non-valid STE, and a device access, the HW will
generate one of the translation faults and that will be forwarded.

Some software component will have to transform those fault events into
C_BAD_STE for the VM.

I imagined userspace would do this, but it could be done in the kernel
too. Regardless, I think Will is right and the the viommu should be
set even in this case to capture the events.

Jason