Re: [PATCH v9 07/12] iommu/arm-smmu-v3-kexec: Add ASID/VMID reservation helpers

On Fri, Aug 21, 2026 at 08:15:26PM -0300, Jason Gunthorpe wrote:
> > +static int arm_smmu_kexec_resv_asid(struct arm_smmu_device *smmu, u32 asid)
> > +{
> > +	int ret;
> > +
> > +	/* A valid CD never has ASID 0; both kernels share the same HW limit */
> > +	if (!asid || asid >= 1UL << smmu->asid_bits)
> > +		return -EINVAL;
> > +
> > +	guard(mutex)(&arm_smmu_asid_lock);
> > +
> > +	/* The value entry marks the ASID as in-use and identifies its scan */
> > +	ret = xa_insert(&arm_smmu_asid_xa, asid,
> > +			xa_mk_value(arm_smmu_kexec_scan_id), GFP_KERNEL);
> > +	/*
> > +	 * An -EBUSY against a value entry safely shares a permanent reservation
> > +	 * made by another scan. A pointer entry means a live domain that will
> > +	 * free its ASID for reuse eventually: keep -EBUSY to fail the scan.
> > +	 */
> > +	if (ret == -EBUSY && xa_is_value(xa_load(&arm_smmu_asid_xa, asid)))
> > +		ret = 0;
> 
> Huh. Somewhere I had a patch to make ASID per smmu instance, just like vmid.
> I think you might actually need it here? Is it possible that one instance
> could probe, the core code could start changing domains and end up with an
> unintended ASID conflict on a later instance? Then things go sideways?

Yes. I've noticed a problem: SMMU-A allocates ASIDx from the global
space for a default domain, later SMMU-B wants to reserve ASIDx.

So my local v10 adds a new patch making ASID per smmu. If you would
like your version, I can swap that.

> 
> If you have that you can also drop the arm_smmu_kexec_resv_lock?

Yes. The entire thing ended up cleaner actually.

Thanks
Nicolin