Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

VirtIO block TODOs #57

Open
5 of 11 tasks
erichchan999 opened this issue May 3, 2024 · 0 comments
Open
5 of 11 tasks

VirtIO block TODOs #57

erichchan999 opened this issue May 3, 2024 · 0 comments
Assignees

Comments

@erichchan999
Copy link
Contributor

erichchan999 commented May 3, 2024

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:

[   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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant