You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Use one compiler:
VirtIO block example uses multiple compilers (clang + aarch64-linux-gnu-gcc) to also cross compile for linux userspace. We want to get one compiler, e.g zig cc working instead.
Build example on macOS: Support for virtIO sound #37
mkfs.fat doesn't exist in the macOS system, furthermore fdisk behaves differently. Need to find alternative tools to make the virtual disk for macOS users.
Dropped requests:
We never know if requests are dropped from the other end which means a reply would never come back. Right now this happens when the queues are full. Need to consider whether we need to implement a timeout functionality, or change how the other end responds to a full queue.
EDIT: no longer a problem as the virtualiser guarantees existence of a certain number of in-flight requests. If we let the response queue capacity be equal or greater than that we can guarantee no dropped requests.
Initialisation order
Client VMs busy wait for the virtualiser to be ready, which busy waits on the driver to be ready. Need to find a proper solution.
Add virtIO block tests to CI:
Add, at the very least, a simple testing script that tests simple read/write into the virtIO device.
Stress testing + benchmark:
Set up an environment that allows us to stress test the virtIO block implementation. We are considering using postmark and IOZone
Poweroff errors:
Figure out why the virtIO block device seems to not be happy with linux's poweroff procedure. When the client powers off it logs the following:
[ 32.662153] /dev/vda: Can't open blockdev
[ 32.666415] /dev/vda: Can't open blockdev
[ 32.675882] /dev/vda: Can't open blockdev
mount: mounting /dev/vda on /mnt failed: Device or resource busy
Stopping network: OK
Saving random seed: OK
Stopping klogd: OK
Stopping syslogd: OK
umount: /dev/vda busy - remounted read-only
umount: devtmpfs busy - remounted read-only
umount: can't unmount /: Invalid argument
The system is going down NOW!
Use atomics when spinning on the ready field:
Like it is done for virtIO sound.
Investigate a smarter way to assign partitions to clients:
Right now it is whichever PD decides to set blk_data1, blk_data2 etc.
Support driver using DMA:
The current linux userspace block driver does not use DMA to transfer data between the device and the rest of the system. As such we'll need to expose the data region to the driver for it to read/write data to/from the device. Once we figure out how to do DMA in userspace (and get it working), we can remove this.
Doesn't seem possible unless we write our own kernel module, more is explained in Update block UIO driver for latest sDDF #97
The text was updated successfully, but these errors were encountered:
Future TODOs following this PR #28
Use one compiler:
VirtIO block example uses multiple compilers (clang + aarch64-linux-gnu-gcc) to also cross compile for linux userspace. We want to get one compiler, e.g zig cc working instead.
Build example on macOS: Support for virtIO sound #37
mkfs.fat doesn't exist in the macOS system, furthermore fdisk behaves differently. Need to find alternative tools to make the virtual disk for macOS users.
Dropped requests:
We never know if requests are dropped from the other end which means a reply would never come back. Right now this happens when the queues are full. Need to consider whether we need to implement a timeout functionality, or change how the other end responds to a full queue.
EDIT: no longer a problem as the virtualiser guarantees existence of a certain number of in-flight requests. If we let the response queue capacity be equal or greater than that we can guarantee no dropped requests.
Initialisation order
Client VMs busy wait for the virtualiser to be ready, which busy waits on the driver to be ready. Need to find a proper solution.
VGIC active & pending problem:
This issue directly affects the virtIO block system Problems within the VGIC vIRQ edge-triggered interrupt emulation and and the problem it's causing when implementing driver VMs #56. The driver VM misses interrupts from the client when it is disabled. You'll see this when this line
BLK_DRIVER_VMM|ERROR: vIRQ 0x32 is not enabled
appears.Add virtIO block tests to CI:
Add, at the very least, a simple testing script that tests simple read/write into the virtIO device.
Stress testing + benchmark:
Set up an environment that allows us to stress test the virtIO block implementation. We are considering using postmark and IOZone
Poweroff errors:
Figure out why the virtIO block device seems to not be happy with linux's poweroff procedure. When the client powers off it logs the following:
Use atomics when spinning on the ready field:
Like it is done for virtIO sound.
Investigate a smarter way to assign partitions to clients:
Right now it is whichever PD decides to set blk_data1, blk_data2 etc.
Support driver using DMA:The current linux userspace block driver does not use DMA to transfer data between the device and the rest of the system. As such we'll need to expose the data region to the driver for it to read/write data to/from the device. Once we figure out how to do DMA in userspace (and get it working), we can remove this.
Doesn't seem possible unless we write our own kernel module, more is explained in Update block UIO driver for latest sDDF #97
The text was updated successfully, but these errors were encountered: