STRUCT GAUDI2_DEVICE(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’– NAME πŸ’–

struct gaudi2_device β€” the ASIC-specific manage structure, bestie. it's the bookkeeping struct, and honestly? she's carrying the whole device on her back πŸ’…

this lil page lives in the Kernel API Manual, and it's here to walk you through every single field like a group chat recap 🫢


✨ SYNOPSIS ✨

struct gaudi2_device {
    int (*cpucp_info_get)(struct hl_device *hdev);
    struct user_mapped_block mapped_blocks[NUM_USER_MAPPED_BLOCKS];
    int lfsr_rand_seeds[MME_NUM_OF_LFSR_SEEDS];
    spinlock_t hw_queues_lock;
    void *scratchpad_kernel_address;
    dma_addr_t scratchpad_bus_address;
    void *virt_msix_db_cpu_addr;
    dma_addr_t virt_msix_db_dma_addr;
    u64 dram_bar_cur_addr;
    u64 hw_cap_initialized;
    u64 active_hw_arc;
    u64 dec_hw_cap_initialized;
    u64 tpc_hw_cap_initialized;
    u64 active_tpc_arc;
    u64 nic_hw_cap_initialized;
    u64 active_nic_arc;
    u32 hw_events[GAUDI2_EVENT_SIZE];
    u32 events_stat[GAUDI2_EVENT_SIZE];
    u32 events_stat_aggregate[GAUDI2_EVENT_SIZE];
    u32 num_of_valid_hw_events;
    struct gaudi2_queues_test_info queues_test_info[GAUDI2_NUM_TESTED_QS];
};

look at her. 21 fields. main character energy, no cap πŸ‘‘


🌸 Members 🌸

okay so field-by-field, let's go πŸƒβ€β™€οΈ

  • cpucp_info_get β€” a function pointer that gets information on the device from CPU-CP. she's the little fetch quest for device intel ✨
  • mapped_blocks β€” an array that holds the base address and size of all blocks the user can map. like a guest list but for memory πŸŽ€
  • lfsr_rand_seeds β€” array of MME ACC random seeds to set. seeds!! 🌱
  • hw_queues_lock β€” protects the H/W queues from concurrent access. it's giving bouncer at the club door, nobody gets in at the same time 😀
  • scratchpad_kernel_address β€” general purpose PAGE_SIZE contiguous memory. and listen: this memory region should be write-only. currently used for HBW QMAN writes which is redundant. so like, write-only, okay?? don't come at her trying to read πŸ™ˆ
  • scratchpad_bus_address β€” scratchpad bus address. the bus-address twin of the above, slay πŸ’«
  • virt_msix_db_cpu_addr β€” host memory page for the virtual MSI-X doorbell. a whole page, just for a doorbell πŸ›ŽοΈ
  • virt_msix_db_dma_addr β€” bus address of the page for the virtual MSI-X doorbell. same doorbell, different address flavor πŸ’œ
  • dram_bar_cur_addr β€” current address of DRAM PCI bar. current! as in right now πŸ“
  • hw_cap_initialized β€” this field contains a bit per H/W engine. when that engine is initialized, that bit is set by the driver to signal we can use this engine in later code paths. each bit is cleared upon reset of its corresponding H/W engine. one bit per engine, on when ready, off on reset β€” literally a vibe check for hardware ⭐
  • active_hw_arc β€” this field contains a bit per ARC of an H/W engine, with the exception of TPC and NIC engines. once an engine arc is initialized, its respective bit is set. driver can uniquely identify each initialized ARC and use this information in later code paths. each respective bit is cleared upon reset of its corresponding ARC of the H/W engine. yes TPC and NIC are not invited to this one, they have their own fields πŸ’€
  • dec_hw_cap_initialized β€” this field contains a bit per decoder H/W engine. when that engine is initialized, that bit is set by the driver to signal we can use this engine in later code paths. each bit is cleared upon reset of its corresponding H/W engine. decoders get their own bitmask, periodt πŸ”₯
  • tpc_hw_cap_initialized β€” this field contains a bit per TPC H/W engine. when that engine is initialized, that bit is set by the driver to signal we can use this engine in later code paths. each bit is cleared upon reset of its corresponding H/W engine. TPC's turn πŸ’…
  • active_tpc_arc β€” this field contains a bit per ARC of the TPC engines. once an engine arc is initialized, its respective bit is set. each respective bit is cleared upon reset of its corresponding ARC of the TPC engine. the ARC bitmask, TPC edition πŸ¦‹
  • nic_hw_cap_initialized β€” this field contains a bit per nic H/W engine. short and sweet, she doesn't overexplain πŸŽ€
  • active_nic_arc β€” this field contains a bit per ARC of the NIC engines. once an engine arc is initialized, its respective bit is set. each respective bit is cleared upon reset of its corresponding ARC of the NIC engine. and that's the NIC ARC bitmask, completing the trilogy ✨
  • hw_events β€” array that holds all H/W events that are defined valid. the valid ones only, we don't associate with invalid events πŸ’β€β™€οΈ
  • events_stat β€” array that holds histogram of all received events. count 'em up πŸ“Š
  • events_stat_aggregate β€” same as events_stat but doesn't get cleared on reset. she remembers. iconic behavior πŸ‘‘
  • num_of_valid_hw_events β€” used to hold the number of valid H/W events. just a count, bestie πŸ”’
  • queues_test_info β€” information used by the driver when testing the HW queues. test era, we love to see it 🧚

okay real talk for a sec 🫢 β€” don't go reading scratchpad_kernel_address expecting sensible results. the docs say it should be write-only, and that it's currently used for HBW QMAN writes which is redundant. respect the write-only lifestyle or catch these bugs 😭

πŸ”₯ SEE ALSO πŸ”₯

  • Kernel file ./drivers/accel/habanalabs/gaudi2/gaudi2P.h struct dup_block_ctx(9)
  • struct gaudi2_queues_test_info(9)

go read those too, they're the friend group πŸ’œ


and that's the page!! 🌈 source: ./drivers/accel/habanalabs/gaudi2, version vibes from October 2026 β€” mwah, ty for reading, ily, go init some engines πŸ’–πŸŽ€πŸ¦‹

πŸ“¦ where this page comes from