On Wed Sep 9, 2026 at 5:59 AM CEST, Eliot Courtney wrote:
> +/// Guard that logs a warning if a [`PreparedMapping`] is dropped without
> +/// being consumed by [`Vmm::execute_map()`].
> +struct MustExecuteGuard {
> + armed: Cell<bool>,
> +}
> +
> +impl MustExecuteGuard {
> + const fn new() -> Self {
> + Self {
> + armed: Cell::new(true),
> + }
> + }
> +
> + fn disarm(&self) {
> + self.armed.set(false);
> + }
> +}
> +
> +impl Drop for MustExecuteGuard {
> + fn drop(&mut self) {
> + if self.armed.get() {
> + kernel::pr_warn!("PreparedMapping dropped without calling
> execute_map()\n");
> + }
> + }
> +}
> +
> +/// Guard that logs a warning if a [`MappedRange`] is dropped without
> +/// calling [`Vmm::unmap_pages()`].
> +struct MustUnmapGuard {
> + armed: Cell<bool>,
> +}
> +
> +impl MustUnmapGuard {
> + const fn new() -> Self {
> + Self {
> + armed: Cell::new(true),
> + }
> + }
> +
> + fn disarm(&self) {
> + self.armed.set(false);
> + }
> +}
> +
> +impl Drop for MustUnmapGuard {
> + fn drop(&mut self) {
> + if self.armed.get() {
> + kernel::pr_warn!("MappedRange dropped without calling
> unmap_pages()\n");
> + }
> + }
> +}
As mentioned in the previous reply, none of this seems necessary if we get rid
of the big vmm lock and use proper RAII guards instead.
> + // TODO: Internal page table pages (PDE, PTE pages) are still kept
> around.
> + // This is by design as repeated maps/unmaps will be fast. As a
> future TODO,
So, if I got the math right it means that once we scattered mappings across 1TiB
of address space, this is 2GiB of VRAM gone given that we currently only have
4KiB pages?
Performance wise it depends on the reclaim strategy. Also, given that we have no
software mirror, isn't this N * 4 PRAMIN reads for a mapping of N pages?
So, I'm not sure I'd call this by design.
> + // we can add a reclaimer here to reclaim if VRAM is short. For now,
> the PT
> + // pages are dropped once the `Vmm` is dropped.
