Hi Alex, On Mon, Mar 02, 2026 at 09:23:43PM +0900, Alexandre Courbot wrote: > Basically this feature is a prime candidate for an `Io` implementation. > It maps onto the BAR, has a fixed 1MB size, and needs to be accessed > using various sizes. It is also used to fill structured values, which > the I/O projection work will also allow us to do.
Agreed, PRAMIN maps naturally onto the Io abstraction and I had thought about this. > The current design doesn't allow the user to explicitly set the start of > the sliding window - this results in a sub-optimal usage of the hardware > and more complex code in this module. At this level, we just want > something that exposes the hardware as it is, i.e. "give me a view of > the 1MB of VRAM starting from this 64K-aligned address". I reduced the complexity quite a bit. I think we can further simplify, but for now I think it makes sense to keep it this way - I am happy with all the usage sites as well. It properly abstracts the internals without having the user worry about alignment or window size, so I think it simplifies things for the user quite a bit. I have tried the alternative before and the caller side became complicated. Not saying we should not simplify it further but we can do it piecemeal. The current code works and is easy to understand. Hope that's okay with you. > Then on top of that we can implement another type that handles the > window automatically if we want, but I don't think we will actually need > it. The page table code will most likely want to set the window to the > start of its structure, project it, and access it using compile-time > checked offsets. > > If that turns out to be insufficient, we can always compose something > more complex from this basic piece - but the base `Pramin` should stay > simple and truthful to the underlying hardware IMHO. This is a great future improvement if it makes sense. One issue I can see is for large page tables where the burden of moving the window would fall on the user. I don't want to box us into those constraints right now (especially since we also already know that MMU v3's PRAM mechanism is different and likely needs a HAL). If we want more APIs for fixed window sizes that can never be moved, we can always add that in the future, but for now I prefer to keep this as is (let us see if you like the v9, I think you will :)). Adding to this, auto repositioning does not really trigger if there is no need, and the current API removes the burden of managing the window from the user. I already took two passes to simplify the code since the posting last year so right now in my opinion it is quite simple and even further less lines of code. It should be acceptable as a first pass IMO. One more point on this is, we don't yet have BAR2 support so PRAMIN is the main way to directly write to VRAM, and instance memory is much larger than the window size. So PRAMIN is our primary mechanism for bootstrap (our spoke to HW experts, and they said this is acceptables). One other thing to note: the Io trait uses `usize` for offsets, while I just changed VRAM addresses to `u64` per your feedback on the other PRAMIN thread. So implementing Io for PRAMIN would require u64-to-usize conversions at the interface boundary. Not a blocker since offsets within the 1MB window are always small, but worth considering. Also it is still not clear to me about how to deal with Io trait's "offsets" if they are VRAM addresses". Even if we convert it to usize to satisfy Io trait, does it make sense in the Io trait itself to have them as usize? thanks, -- Joel Fernandes
