vhost-device/vhost-device-scsi
Manos Pitsidianakis a1e013286f Move all crates to workspace root
Having all the workspace crates under the crates/ directory is
unnecessary. Rust documentation itself recommends all crates to be in
the root directory:

https://doc.rust-lang.org/book/ch14-03-cargo-workspaces.html#creating-the-second-package-in-the-workspace

I paste the text content here, in case the online page ever changes or
becomes unavailable:

    ## Creating the Second Package in the Workspace

    Next, let’s create another member package in the workspace and call it add_one. Change the top-level Cargo.toml to specify the add_one path in the members list:

    Filename: Cargo.toml

    [workspace]

    members = [
        "adder",
        "add_one",
    ]

    Then generate a new library crate named add_one:

    $ cargo new add_one --lib
         Created library `add_one` package

    Your add directory should now have these directories and files:

    ├── Cargo.lock
    ├── Cargo.toml
    ├── add_one
    │   ├── Cargo.toml
    │   └── src
    │       └── lib.rs
    ├── adder
    │   ├── Cargo.toml
    │   └── src
    │       └── main.rs
    └── target

Signed-off-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
2023-10-16 12:03:57 +05:30
..
src Move all crates to workspace root 2023-10-16 12:03:57 +05:30
test Move all crates to workspace root 2023-10-16 12:03:57 +05:30
ARCHITECTURE.md Move all crates to workspace root 2023-10-16 12:03:57 +05:30
Cargo.toml Move all crates to workspace root 2023-10-16 12:03:57 +05:30
CHANGELOG.md Move all crates to workspace root 2023-10-16 12:03:57 +05:30
LICENSE-APACHE Move all crates to workspace root 2023-10-16 12:03:57 +05:30
LICENSE-BSD-3-Clause Move all crates to workspace root 2023-10-16 12:03:57 +05:30
README.md Move all crates to workspace root 2023-10-16 12:03:57 +05:30

vhost-device-scsi

This is a Rust implementation of a vhost-device-scsi daemon.

Usage

Run the vhost-device-scsi daemon:

vhost-device-scsi -r --socket-path /tmp/vhost-user-scsi.sock /path/to/image.raw /path/to/second-image.raw ...

Run QEMU:

qemu-system-x86_64 ... \
  -device vhost-user-scsi-pci,num_queues=1,param_change=off,chardev=vus \
  -chardev socket,id=vus,path=/tmp/vhost-user-scsi.sock \
  # must match total guest meory
  -object memory-backend-memfd,id=mem,size=384M,share=on \
  -numa node,memdev=mem

Limitations

We are currently only supporting a single request queue and do not support dynamic reconfiguration of LUN parameters (VIRTIO_SCSI_F_CHANGE).

Features

This crate is a work-in-progress. Currently, it's possible to mount and read up to 256 read-only raw disk images. Some features we might like to add at some point, roughly ordered from sooner to later:

  • Write support. This should just be a matter of implementing the WRITE command, but there's a bit of complexity around writeback caching we need to make sure we get right.
  • Support more LUNs. virtio-scsi supports up to 16384 LUNs per target. After 256, the LUN encoding format is different; it's nothing too complicated, but I haven't gotten around to implementing it.
  • Concurrency. Currently, we process SCSI commands one at a time. Eventually, it'd be a good idea to use threads or some fancy async/io_uring stuff to concurrently handle multiple commands. virtio-scsi also allows for multiple request queues, allowing the guest to submit requests from multiple cores in parallel; we should support that.
  • iSCSI passthrough. This shouldn't be too bad, but it might be a good idea to decide on a concurrency model (threads or async) before we spend too much time here.