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

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

If you have that you can also drop the arm_smmu_kexec_resv_lock?

+/**
+ * arm_smmu_kexec_unresv_ids() - Roll back a failing reservation scan
+ * @smmu: SMMU device of this kernel that failed its reservation scan

And wouldn't need this either.

Actually I think this is overkill regardless, just leave the xarray with ASIDs
reserved. Who cares?

The general logic looks otherwise OK to me

Jason

-- 
Jason