Re: [PATCH v3 14/14] gpu: nova-core: gsp: Retrieve GSP static info to gather GPU information

[Joel Fernandes <joelagnelf@nvidia.com>]

On 11/12/2025 3:22 PM, Joel Fernandes wrote:
> On 11/11/2025 5:02 PM, Lyude Paul wrote:
> [...]
> 
>>> +#[repr(C)]
>>> +#[derive(Debug, Copy, Clone)]
>>> +pub struct GspStaticConfigInfo_t {
>>> +    pub grCapsBits: [u8_; 23usize],
>>> +    pub gidInfo: NV2080_CTRL_GPU_GET_GID_INFO_PARAMS,
>>> +    pub SKUInfo: NV2080_CTRL_BIOS_GET_SKU_INFO_PARAMS,
>>> +    pub fbRegionInfoParams: NV2080_CTRL_CMD_FB_GET_FB_REGION_INFO_PARAMS,
>>> +    pub sriovCaps: NV0080_CTRL_GPU_GET_SRIOV_CAPS_PARAMS,
>>> +    pub sriovMaxGfid: u32_,
>>> +    pub engineCaps: [u32_; 3usize],
>>> +    pub poisonFuseEnabled: u8_,
>>> +    pub fb_length: u64_,
>>> +    pub fbio_mask: u64_,
>>> +    pub fb_bus_width: u32_,
>>> +    pub fb_ram_type: u32_,
>>> +    pub fbp_mask: u64_,
>>> +    pub l2_cache_size: u32_,
>>> +    pub gpuNameString: [u8_; 64usize],
>>> +    pub gpuShortNameString: [u8_; 64usize],
> 
> [...]
> 
>>> +mod util;
>>>  mod vbios;
>>>  
>>>  pub(crate) const MODULE_NAME: &kernel::str::CStr = <LocalModule as kernel::ModuleMetadata>::NAME;
>>> diff --git a/drivers/gpu/nova-core/util.rs b/drivers/gpu/nova-core/util.rs
>>> new file mode 100644
>>> index 000000000000..f1a4dea44c10
>>> --- /dev/null
>>> +++ b/drivers/gpu/nova-core/util.rs
>>> @@ -0,0 +1,16 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> +
>>> +/// Converts a null-terminated byte array to a string slice.
>>> +///
>>> +/// Returns "invalid" if the bytes are not valid UTF-8 or not null-terminated.
>>> +pub(crate) fn str_from_null_terminated(bytes: &[u8]) -> &str {
>>> +    use kernel::str::CStr;
>>> +
>>> +    // Find the first null byte, then create a slice that includes it.
>>> +    bytes
>>> +        .iter()
>>> +        .position(|&b| b == 0)
>>> +        .and_then(|null_pos| CStr::from_bytes_with_nul(&bytes[..=null_pos]).ok())
>>> +        .and_then(|cstr| cstr.to_str().ok())
>>> +        .unwrap_or("invalid")
>>
>> I feel like I'm missing something obvious here so excuse me if I am. But if
>> CStr::from_bytes_with_nul is already scanning the string for a NULL byte, why
>> do we need to do iter().position(|&b| b == 0)?
> 
> It is because the .get() above could potentially return an entire buffer with
> no-null termintaor, as unlikely as that might be. In this case the
> `.unwrap_or(msg.gpuNameString.len() - 1),` bit will execute returning 63 as the
> length of the buffer space is 64 bytes. `CStr::from_bytes_with_nul()` will then
> separately look for the NULL and fail into returning "invalid" as the string.
> 
> So mainly, the redundant `.position()` call is it is to handle the failure case.

Sorry clarifying my answer as I was referring to the other snippet. The real
reason is from_bytes_with_nul(bytes: &[u8]) requires the slice to be exactly the
length of the string plus one byte for NULL. You can't pass it a long slice and
have interior NULLs.

This is also mentioned here:

    /// The provided slice must be `NUL`-terminated, does not contain any
    /// interior `NUL` bytes.
    pub const fn from_bytes_with_nul(bytes: &[u8]) -> Result<&Self..

It is possible that callers pass buffers with interior NULLs, these come from
the firmware. So str_from_null_terminated has to find the NULL position first.

Does that answer your question?

Thanks.