Re: [PATCH 1/3] gpu: nova-core: extract radix3 page table into its own module

["Alexandre Courbot" <acourbot@nvidia.com>]

On Mon Sep 14, 2026 at 5:56 AM JST, John Hubbard wrote:
> On 9/13/26 1:36 PM, Gary Guo wrote:
>> On Sun Sep 13, 2026 at 8:54 PM BST, John Hubbard wrote:
>>> In order to boot the GSP, nova-core loads the GSP firmware image into
>>> system memory, and the GPU copies it into the framebuffer, the GPU's own
>>> memory. The GPU finds the GSP firmware image's pages via "radix3", a
>>> three-level page table of 4 KiB pages that the driver builds. Today the
>>> table exists as fields within the GSP firmware wrapper, which is fine
>>> because there is only one radix3 consumer.
>>>
>>> The upcoming r000 series[1], however, introduces a second radix3 caller:
>>> the ucodes firmware image. That is because the GSP has been changed, so
>>> that it automatically fetches the subset of ucodes that it requires,
>>> thus reducing the size of the GSP image. This is a helpful change for
>>> the firmware situation overall, but it will require nova-core to load
>>> and provide ucodes, in much the same way that it was loading and
>>> providing the GSP firmware image.
>>>
>>> Therefore, split out radix3 into its own module.
>> 
>> I find the name itself confusing if I don't read the docs. The radix in "radix3"
>> is actually 512 (given 4 KiB page and 64-bit entry) and definitely not 3.
>> 
>> Perhaps name this "radixlv3" or something similar instead? Or perhaps call it
>> GspPageTable?
> Right, it's all about the number of levels, not the radix value, that's
> true. Open RM loves "radix3" so much that I've become tone-deaf to the
> name. :)
>
> three_level_radix works, but is silly long for this.
>
> Do we really care enough to insist on this, though? I'd be inclined
> to ask to just leave it alone.

As long as we agree on where the "3" comes from, I agree that keeping
the name aligned with OpenRM sounds preferable.