Open Ivan-Velickovic opened 1 month ago
Currently blocked on this issue:
To allow DMA from within the driver VMs we need to allow read/write from linux userspace directly. The virtualiser passes a physical address to DMA into/from, and we wish to create a mapping in linux to this physical address to interact with. Linux does not seem to provide that option. The uio memory mappings we've been using so far are special mappings with VM_IO / VM_PFNMAP flag set in the VMA that fails direct I/O validations. The culprit seems to be remap_pfn_range, which marks the range of addresses as VM_IO. The same issue occurs when trying to mmap /dev/mem. For now all DMAable devices still require an extra copy.
I cannot merge my examples/virtio
makefile changes as the sDDF commit I need (https://github.com/au-ts/sddf/commit/ba06ec1) is after the one that breaks examples/virtio
. Is this something that will be fixed soon?
Everything needs to be on the latest sDDF for the release, so the plan is to temporarily regress the UIO block driver until it's fixed.
What do you mean by regress exactly? The UIO block driver will simply be not buildable or are you making a workaround?
The UIO block driver won't work correctly until we fix the issue. Hopefully not for long though.
Currently the block UIO driver depends on the sDDF block virtualiser passing offsets instead of raw physical addresses. This was changed this https://github.com/au-ts/sddf/commit/2d8dbee59118c1403489d63b040ff2122f97047b commit of sDDF and so we need to update the UIO driver accordingly.
Raw physical addresses suit native drivers better and having the same virtualiser code regardless of whether it's talking to a native driver or driver VM is important and so we should fix the UIO driver to accept/deal with physical addresses.
Originally the UIO block driver used offsets since it was easier and we had no native drivers.