On Mon, 12 Oct 2026 14:59:33 +0200
Ketil Johnsen <[email protected]> wrote:
> +void panthor_mmu_protm_exit_event(struct panthor_device *ptdev)
> +{
> + /* We left protected mode and scheduler is about to resume normal
> + * scheduling. Do the necessary cache operation so any page table
> + * updates we might have done during protm is correctly visible
> + * to the GPU.
> + */
> + int ret;
> +
> + guard(mutex)(&ptdev->mmu->as.slots_lock);
> +
> + ptdev->mmu->as.delay_update_mask = 0;
> +
> + if (!ptdev->mmu->as.delayed_update_mask)
> + return;
> +
> + ret = panthor_gpu_flush_caches(ptdev, CACHE_CLEAN | CACHE_INV,
> + CACHE_CLEAN | CACHE_INV, CACHE_INV);
I've been thinking about this a bit more, and I don't get why we need
to flush the caches here. If we assume that only one PROTM group is
resident when PROTM is entered, that means the other resident VMs are
idle until the other groups are resumed. My understanding is that we
have an automatic cache reset at the PROTM section boundaries to avoid
data leaks (invalidation of all caches), so why do we need an extra
flush here?
Tangentially to this, now that only one group is active in PROTM,
what's the benefit of keeping VMs on slot. Things don't get resumed
automatically, and I doubt the as_enable() is what takes time when
resuming the groups. If this new limitation stands (one group resident
when in PROTM), I'd rather simplify things to take advantage of this.
> + if (ret)
> + panthor_device_schedule_reset(ptdev);
> +}
