Closed CtrlZ233 closed 7 months ago
Right, that's expected as callers of the device driver may send data from arbitrary locations in memory, e.g. on the stack. If your platform requires all DMA to be within a previously allocated region (rather than sharing it on demand) then your Hal::share
implementation can copy the data (if direction
is DriverToDevice
or Both
) from the buffer to an appropriate allocation and return the address of the copy. Hal::unshare
can then copy the result back (if direction
is DeviceToDriver
or Both
) and deallocate the DMA memory.
You can see an implementation of this for protected VMs in AOSP: https://cs.android.com/android/platform/superproject/main/+/main:packages/modules/Virtualization/vmbase/src/virtio/hal.rs
I implemented Hal trait for VirtioHal and use it to init VirtIONet, However, the address of the input parameter buf of the share interface is not within the range of the previous dma allocated address. I am not sure whether this is the correct behavior.
virtio-drivers = { git = "https://github.com/rcore-os/virtio-drivers", rev = "a35c6e6" }