Expressing devices that have dependencies on the memory_manager and transitively the partition unit

Today there's devices like the framebuffer and vpci that have an unexpressed dependency with the partition that ultimately implements map/unmap via the memory_manager.

It doesn't seem like we express this dependency in any way today, which means that a device could issue map/unmap calls while a partition is undergoing reset. That seems wrong?

We chatted about this a bit in office hours and we thought that perhaps it makes sense to make the memory_manager its own state unit. The rationale being that on state transitions, we should make sure to correctly flush and commit any pending changes to the memory mappings of the vm to the backing partition unit before we can complete that state transition.

Thoughts? That's a much more involved change, but I think it's the correct model to follow

Start by tracing the framebuffer and vpci devices, the memory_manager, and the partition unit to understand how map/unmap calls interact with reset and state transitions. Determine how pending VM memory mappings could be flushed and committed before a transition completes. Done would mean the dependency is explicitly represented and reset cannot race with those mapping operations.