On 14/09/2026 11:22 am, Gary Guo wrote:
On Mon Sep 14, 2026 at 10:58 AM BST, Danilo Krummrich wrote:
On Mon Sep 14, 2026 at 2:45 AM CEST, Alexandre Courbot wrote:
On Mon Sep 14, 2026 at 6:08 AM JST, Matteo Kloiber wrote:
On Mon Sep 7, 2026 at 11:43 AM JST, Alexandre Courbot wrote:
It also means that without patch 1, nova-core would split the firmware
into hundreds of 64KB SG entries, which is not breaking but still
something we want to avoid. The correct fix is to make sure that
`dma_set_max_seg_size` is called by the driver, and while we are at it
we also want every driver to call `dma_set_mask_and_coherent`. Ideally
we would use the type system to make sure that both functions are called
before any DMA operation can take place (using a safe interface), but
I'm not quite sure yet how we can do this.
This sounds sensible indeed. Should I open a thread regarding that on Zulip?
Probably not necessary, the mailing-list has a larger audience and is
the right place for this. I expect people will jump in here with their
thoughts.
The problem with those is not that they must strictly be called before
allocating DMA memory, but they must not be called concurrently with other DMA
operations, such as allocating DMA memory, as it would technically be a data
race.
Do they really have to be called *before* allocating DMA memory, not do they
just need not be called *concurrent* to DMA memory allocation?
Similar to DMA masks, the segment parameters should be set appropriately
before any dma_map_sg() operation. Plus since they likely influence
scatterlist geometry, that means typically they're also going to need to
be set before building the scatterlist to be mapped in the first place.
I don't think there's any expectation that they would ever change
*between* different mappings - especially given the underlying hardware
properties they represent - so while that might technically be possible
in the C API if the caller can enforce sufficient ordering, it should be
fine to rule it out in the Rust abstraction if that makes things easier
to reason about.
Thanks,
Robin.
If it's the former, we can require these to require mutable reference instead,
so the probe takes `Pin<&'bound mut Device<Core<'_>>>` which still derefs to
`&'bound Device<Bound>`, but Rust will require the shared reference to not
co-exist with the mutable reference.
Best,
Gary
