Skip to content

[WIP] usdm: add hugepage allocation fallback for VFIO#145

Open
gcabiddu wants to merge 1 commit intomainfrom
hugepage-fallback-fix
Open

[WIP] usdm: add hugepage allocation fallback for VFIO#145
gcabiddu wants to merge 1 commit intomainfrom
hugepage-fallback-fix

Conversation

@gcabiddu
Copy link
Contributor

@gcabiddu gcabiddu commented Mar 2, 2026

When hugepages are configured but none are free (e.g. all consumed by DPDK), QATlib VFIO hugepage allocations fail with no fallback, breaking all QAT hardware offload.

Add a three-layer defense:

  1. Init-time check: Read free_hugepages from sysfs during __qae_vfio_init_hugepages(). If zero, disable hugepage mode immediately.

  2. Runtime fallback: If hugepage slab allocation fails and no hugepage slab has ever been successfully allocated, disable hugepage mode and fall back to regular (4KB) VFIO memory allocation via ioctl path.

  3. Mixed-state guard: If hugepage slabs already exist, refuse to fall back to avoid mixing 2MB and 4KB page table entries which would corrupt IOVA mappings.

Also fix store_mmap_range() to derive page table granularity from the actual slab type (p_ctrl_blk->type) rather than the global hugepage mode flag, ensuring correctness after fallback.

@gcabiddu gcabiddu changed the title usdm: add hugepage allocation fallback for VFIO [WIP] usdm: add hugepage allocation fallback for VFIO Mar 2, 2026
When hugepages are configured but none are free (e.g. all consumed by
DPDK), QATlib VFIO hugepage allocations fail with no fallback, breaking
all QAT hardware offload.

Add a three-layer defense:

1. Init-time check: Read free_hugepages from sysfs during
   __qae_vfio_init_hugepages(). If zero, disable hugepage mode
   immediately.

2. Runtime fallback: If hugepage slab allocation fails and no hugepage
   slab has ever been successfully allocated, disable hugepage mode and
   fall back to regular (4KB) VFIO memory allocation via ioctl path.

3. Mixed-state guard: If hugepage slabs already exist, refuse to fall
   back to avoid mixing 2MB and 4KB page table entries which would
   corrupt IOVA mappings.

Also fix store_mmap_range() to derive page table granularity from the
actual slab type (p_ctrl_blk->type) rather than the global hugepage
mode flag, ensuring correctness after fallback.

Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
*/
snprintf(free_hp_path, sizeof(free_hp_path), "%s/%s/free_hugepages",
sys_dir_path, HUGEPAGE_SYS_NODE);
if (parse_sysfs_value(free_hp_path, &free_hp) == 0 && free_hp == 0)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the parse fails (returns -1) g_num_hugepages will not be set to 0 here. Shouldn't the logic be:

if (parse... == 0)
    {
    if (free_hp == 0)
        g_num_hugepages = 0;
    }
else // failed to parse the free_hugepages value
    {
    g_num_hugepages = 0;
    }

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, right. Can be written:

ret = parse_sysfs_value(free_hp_path, &free_hp);
if (ret || ret == 0 && free_hp == 0) {
    g_num_hugepages = 0;
}

This way the return value can be preserved and returned to the calleer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants