On Mon, Jul 14, 2025 at 04:59:35PM +0100, Shameer Kolothum wrote:
> +static void
> +smmuv3_accel_ste_range(gpointer key, gpointer value, gpointer user_data)
> +{
> + SMMUDevice *sdev = (SMMUDevice *)key;
> + uint32_t sid = smmu_get_sid(sdev);
> + SMMUSIDRange *sid_range = (SMMUSIDRange *)user_data;
> +
> + if (sid >= sid_range->start && sid <= sid_range->end) {
> + SMMUv3State *s = sdev->smmu;
> + SMMUState *bs = &s->smmu_state;
> +
> + smmuv3_accel_install_nested_ste(bs, sdev, sid);
> + }
> +}
> +
> +void
> +smmuv3_accel_install_nested_ste_range(SMMUState *bs, SMMUSIDRange *range)
> +{
> + if (!bs->accel) {
> + return;
> + }
> +
> + g_hash_table_foreach(bs->configs, smmuv3_accel_ste_range, range);
This will not work correctly?
The bs->configs is a cache that gets an entry inserted to when a
config is fetched via smmuv3_get_config(), which gets invoked by
smmuv3_notify_iova() and smmuv3_translate() only.
But CMDQ_OP_CFGI_ALL can actually happen very early, e.g. Linux
driver does that in the probe() right after SMMU CMDQ is enabled,
at which point neither smmuv3_notify_iova nor smmuv3_translate
could ever get invoked, meaning that the g_hash_table is empty.
Without the acceleration, this foreach works because vSMMU does
not need to do anything since the cache is indeed empty.
But, with accel, it must call smmuv3_accel_install_nested_ste().
So, I think this should foreach the viommu->device_list instead.
Thanks
Nicolin
