> This is related to the comment made by Sashiko, but in which cases are
> we expecting `total_fb_end` to be `None` here? Is this the same set of
> systems for which `buddy_params` will be `None`? If so both arguments
> should be merged into a new type to remove the ability to represent
> invalid state where one is `Some` and the other is `None`.
Indeed I've been working on a patchset to better define the concept
for total_fb_end, so this patchset can work on top in a proper manner.
The question of whether total_fb_end == Some(0) or total_fb_end ==
None is a sufficient indicator for no framebuffer, and I suppose we
have to make a choice before we can land this patch, anyone got an opinion?
> >
> > /// Access the [`GpuBuddy`] allocator.
> > - pub(crate) fn buddy(&self) -> &GpuBuddy {
> > - &self.buddy
> > + pub(crate) fn buddy(&self) -> Result<&GpuBuddy> {
> > + self.buddy.as_ref().ok_or(ENODEV)
> > }
>
> For this kind of accessor to an `Option` it is considered more idiomatic
> to just return an `Option` and let the caller decide how to handle the
> error, but in this case it just seems to be a private convenience method
> used only by submodules, so doing that would defeat its purpose.
> Instead, can we make it private?
possibly, I'll look before resubmitting anything.
>
> <...>
> > diff --git a/drivers/gpu/nova-core/mm/pagetable/map.rs
> > b/drivers/gpu/nova-core/mm/pagetable/map.rs
> > index 77431c509a89..fd404b0734bb 100644
> > --- a/drivers/gpu/nova-core/mm/pagetable/map.rs
> > +++ b/drivers/gpu/nova-core/mm/pagetable/map.rs
> > @@ -81,7 +81,7 @@ pub(super) fn new(pdb_addr: VramAddress) -> Self {
> > /// Allocate and zero a physical page table page.
> > fn alloc_and_zero_page(mm: &mut GpuMm<'_>, level: PageTableLevel) ->
> > Result<PreparedPtPage> {
> > let blocks = KBox::pin_init(
> > - mm.buddy().alloc_blocks(
> > + mm.buddy()?.alloc_blocks(
> > GpuBuddyAllocMode::Simple,
> > SZ_4K.into_safe_cast(),
> > Alignment::new::<SZ_4K>(),
> > @@ -94,7 +94,7 @@ fn alloc_and_zero_page(mm: &mut GpuMm<'_>, level:
> > PageTableLevel) -> Result<Prep
> >
> > // Zero via PRAMIN.
> > let window = mm
> > - .pramin_mut()
> > + .pramin_mut()?
> > .window_at::<[u64; PAGE_SIZE / 8]>(page_vram)?;
> > for i in 0..PAGE_SIZE / 8 {
> > io_write!(window.view(), [build: i], 0);
> > @@ -120,7 +120,7 @@ fn ensure_single_pte_path(
> > for _ in 0..max_iter {
> > let result = self
> > .walker
> > - .walk_pde_levels(mm.pramin_mut(), vfn, |install_addr| {
> > + .walk_pde_levels(mm.pramin_mut()?, vfn, |install_addr| {
> > pt_pages.get(&install_addr).and_then(|p| {
> > p.alloc
> > .iter()
> > @@ -197,7 +197,7 @@ pub(super) fn install_mappings(
> > writable: bool,
> > ) -> Result {
> > {
> > - let pramin = mm.pramin_mut();
> > + let pramin = mm.pramin_mut()?;
> >
> > // Drain prepared PT pages, install all pending PDEs.
> > let mut cursor = pt_pages.cursor_front_mut();
> > @@ -255,7 +255,7 @@ pub(super) fn invalidate_ptes(
> > let invalid_pte = M::Pte::invalid();
> >
> > {
> > - let pramin = mm.pramin_mut();
> > + let pramin = mm.pramin_mut()?;
>
> I'll let Eliot comment on this in more depth as I am not very familiar
> with this module, but I'd like to avoid these runtime checks if
> possible. On systems without a framebuffer, we should not even be able
> to call these methods, so I'd like to enforce it at that level.
>
> Ideally, we would consolidate all the state requiring a framebuffer into
> a new type (i.e. my first comment, but pushed further), and put it
> behind a single `Option` that solely tells us whether the system has a
> framebuffer or not. Then methods requiring a framebuffer can be passed a
> reference to that type and work without runtime checking its presence.
I think we have to get to handling instmem maps in bar2 properly
before we can completely encapsulate everything.
Ideally instmem would have one API for allocation and it would be
backed on systems with VRAM with vram allocations, and with dma
allocations on 0-fb systems.
Then we would have to store the instmem backing in some sort of
encapsulation that hides the pramin/vram buddy/bar2 handling and
device handle for dma alloc handling
Does that make sense?
Dave.
