Update block UIO driver for latest sDDF

[Ivan-Velickovic]

Currently the block UIO driver depends on the sDDF block virtualiser passing offsets instead of raw physical addresses. This was changed this au-ts/sddf@2d8dbee 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.

[erichchan999]

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.

[alexandermbrown]

I cannot merge my examples/virtio makefile changes as the sDDF commit I need (au-ts/sddf@ba06ec1) is after the one that breaks examples/virtio. Is this something that will be fixed soon?

[Ivan-Velickovic]

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.

[alexandermbrown]

What do you mean by regress exactly? The UIO block driver will simply be not buildable or are you making a workaround?

[Ivan-Velickovic]

The UIO block driver won't work correctly until we fix the issue. Hopefully not for long though.