Nouveau - Dec 2025 - [PATCH 10/11] gpu: nova-core: LibosMemoryRegionInitArgument size must be page aligned

On Sat Nov 15, 2025 at 8:30 AM JST, Timur Tabi wrote:
> GSP-RM insists that the 'size' parameter of the
> LibosMemoryRegionInitArgument struct be aligned to 4KB.
(nit: use imperative style in title, e.g. "gpu: nova-core: align
LibosMemoryRegionInitArgument size to page size")
>
> Signed-off-by: Timur Tabi <ttabi at nvidia.com>
> ---
>  drivers/gpu/nova-core/gsp/fw.rs | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/nova-core/gsp/fw.rs
b/drivers/gpu/nova-core/gsp/fw.rs
> index cacdfb2d4810..0104395e04d7 100644
> --- a/drivers/gpu/nova-core/gsp/fw.rs
> +++ b/drivers/gpu/nova-core/gsp/fw.rs
> @@ -355,7 +355,7 @@ fn id8(name: &str) -> u64 {
>          Self(bindings::LibosMemoryRegionInitArgument {
>              id8: id8(name),
>              pa: obj.dma_handle(),
> -            size: num::usize_as_u64(obj.size()),
> +            size:
num::usize_as_u64(obj.size().next_multiple_of(GSP_PAGE_SIZE)),
You can use the `Alignment` type here, as the rest of the code does:

    let size = num::usize_as_u64(obj.size())
        .align_up(Alignment::new::<GSP_PAGE_SIZE>())?;

Now `align_up` returns an error in case of overflow, that we will need
to pass down to the caller by changing the return type of `new`. It is a
bit annoying, but better than the behavior of `next_mutiple_of` in such
a case, which is to panic. :)

On Wed, 2025-11-19 at 12:36 +0900, Alexandre Courbot
wrote:
> You can use the `Alignment` type here, as the rest of the code does:
> 
> ??? let size = num::usize_as_u64(obj.size())
> ??????? .align_up(Alignment::new::<GSP_PAGE_SIZE>())?;
> 
> Now `align_up` returns an error in case of overflow, that we will need
> to pass down to the caller by changing the return type of `new`. It is a
> bit annoying, but better than the behavior of `next_mutiple_of` in such
> a case, which is to panic. :)
I see your point, but these are u64s that we're talking about.  The only way
next_mutiple_of() can
panic is if obj.size() is greater than 0xFFFFFFFFFFFFF000, which is not
possible.

I would say in this case, a panic is preferable to a convoluted error return
that will never be
exercised, because failure here indicates a coding error, not an input error.