Booting nova-core against a real GSP with CONFIG_DMA_API_DEBUG=y warns when the ~60 MiB firmware image is mapped as a scatter-gather table:
DMA-API: nova-core 0000:00:03.0: mapping sg segment longer than device claims to support [len=62914560] [max=65536] There are two separate issues behind it. Patch 1 has nova-core declare the segment size it actually supports. It re-decomposes every segment into 4 KiB GSP page-table entries, so it has no upper bound on segment length. Furthermore, I also checked what other GPUs do, and most do the same: set the max segment size u32::MAX. So this should be the correct behavior for nova as well. Patch 2 has SGTable::new() honor dma_get_max_seg_size() in addition to dma_max_mapping_size(). The abstraction is generic, so a driver with a real hardware segment limit would otherwise silently be handed segments it cannot express in a single descriptor. Tested on an RTX 5080 (GB203) passed through to a QEMU guest via VFIO with CONFIG_DMA_API_DEBUG=y: the warning is gone, and GSP boot and RPC still work. Discussed on Zulip: https://rust-for-linux.zulipchat.com/#narrow/channel/509436-Nova/topic/nova.20core.3A.20DMA-API.3A.20nova-core.200000.3A00.3A03.2E0.3A.20mapping.20sg.20segme/with/618319830 Matteo Kloiber (2): gpu: nova-core: declare unlimited DMA max segment size rust: scatterlist: honor the device's maximum segment size drivers/gpu/nova-core/gpu.rs | 7 +++++++ rust/helpers/dma.c | 5 +++++ rust/kernel/scatterlist.rs | 12 ++++++++++-- 3 files changed, 22 insertions(+), 2 deletions(-) base-commit: cee9395acd8043be0644b25c34bfa86623f2b935 -- 2.51.2
