kernel
kernel copied to clipboard
hermit-os
virtio assumes contiguous memory, but their is no guarantee
https://github.com/hermitcore/libhermit-rs/blob/b52be1ea6f4a815dc7d32bc054c8cfe70dba0a58/src/arch/x86_64/kernel/virtio.rs#L103-L116
@tlambertz the code assumes contiguous memory. But there is no guarantee. I think that you have to use https://github.com/hermitcore/libhermit-rs/blob/master/src/mm/mod.rs#L239.
I just looked it up in the Vec documentation and found this is actually guaranteed:
Most fundamentally, Vec is and always will be a (pointer, capacity, length) triplet. No more, no less. ... If a Vec has allocated memory, then the memory it points to is on the heap (as defined by the allocator Rust is configured to use by default), and its pointer points to len initialized, contiguous elements in order (what you would see if you coerced it to a slice), followed by capacity-len logically uninitialized, contiguous elements.
In the virtual address space, the vector is contiguous but maybe not in the physical address space. What do you need?
Ah you are right, I need (guest-)physical contiguous, so I have to fix this.
In the current implementation virtio queues can only send blocking requests, which use the first available descriptors. Since we never use a descriptor-chain longer than one page this is not an issue which can cause problems right now.
No, I fixed this for both queues in the new implementation.
Uses now the mm::allocate() call.
Although, the FS driver does currently use the old implementation with the boxed vector.
