-
Notifications
You must be signed in to change notification settings - Fork 1
Conversation
Bumps [proc-macro2](https://github.com/dtolnay/proc-macro2) from 1.0.51 to 1.0.55. - [Release notes](https://github.com/dtolnay/proc-macro2/releases) - [Commits](dtolnay/proc-macro2@1.0.51...1.0.55) --- updated-dependencies: - dependency-name: proc-macro2 dependency-type: indirect update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>
Bumps [regex-syntax](https://github.com/rust-lang/regex) from 0.6.28 to 0.6.29. - [Release notes](https://github.com/rust-lang/regex/releases) - [Changelog](https://github.com/rust-lang/regex/blob/master/CHANGELOG.md) - [Commits](https://github.com/rust-lang/regex/commits) --- updated-dependencies: - dependency-name: regex-syntax dependency-type: indirect update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>
Bumps [io-lifetimes](https://github.com/sunfishcode/io-lifetimes) from 1.0.8 to 1.0.9. - [Release notes](https://github.com/sunfishcode/io-lifetimes/releases) - [Commits](sunfishcode/io-lifetimes@v1.0.8...v1.0.9) --- updated-dependencies: - dependency-name: io-lifetimes dependency-type: indirect update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>
Bumps [rust-vmm-ci](https://github.com/rust-vmm/rust-vmm-ci) from `c2f8c93` to `3640704`. - [Release notes](https://github.com/rust-vmm/rust-vmm-ci/releases) - [Commits](rust-vmm/rust-vmm-ci@c2f8c93...3640704) --- updated-dependencies: - dependency-name: rust-vmm-ci dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com>
Bumps [clap](https://github.com/clap-rs/clap) from 4.1.8 to 4.1.14. - [Release notes](https://github.com/clap-rs/clap/releases) - [Changelog](https://github.com/clap-rs/clap/blob/master/CHANGELOG.md) - [Commits](clap-rs/clap@v4.1.8...v4.1.14) --- updated-dependencies: - dependency-name: clap dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>
Bumps [rustix](https://github.com/bytecodealliance/rustix) from 0.36.9 to 0.36.12. - [Release notes](https://github.com/bytecodealliance/rustix/releases) - [Commits](bytecodealliance/rustix@v0.36.9...v0.36.12) --- updated-dependencies: - dependency-name: rustix dependency-type: indirect update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>
Bumps [clang-sys](https://github.com/KyleMayes/clang-sys) from 1.6.0 to 1.6.1. - [Release notes](https://github.com/KyleMayes/clang-sys/releases) - [Changelog](https://github.com/KyleMayes/clang-sys/blob/master/CHANGELOG.md) - [Commits](KyleMayes/clang-sys@v1.6.0...v1.6.1) --- updated-dependencies: - dependency-name: clang-sys dependency-type: indirect update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>
Bumps [libc](https://github.com/rust-lang/libc) from 0.2.139 to 0.2.141. - [Release notes](https://github.com/rust-lang/libc/releases) - [Commits](rust-lang/libc@0.2.139...0.2.141) --- updated-dependencies: - dependency-name: libc dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>
Bumps [proc-macro2](https://github.com/dtolnay/proc-macro2) from 1.0.55 to 1.0.56. - [Release notes](https://github.com/dtolnay/proc-macro2/releases) - [Commits](dtolnay/proc-macro2@1.0.55...1.0.56) --- updated-dependencies: - dependency-name: proc-macro2 dependency-type: indirect update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>
Bumps [rust-vmm-ci](https://github.com/rust-vmm/rust-vmm-ci) from `3640704` to `8627b37`. - [Release notes](https://github.com/rust-vmm/rust-vmm-ci/releases) - [Commits](rust-vmm/rust-vmm-ci@3640704...8627b37) --- updated-dependencies: - dependency-name: rust-vmm-ci dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com>
Bumps [futures-core](https://github.com/rust-lang/futures-rs) from 0.3.26 to 0.3.28. - [Release notes](https://github.com/rust-lang/futures-rs/releases) - [Changelog](https://github.com/rust-lang/futures-rs/blob/master/CHANGELOG.md) - [Commits](rust-lang/futures-rs@0.3.26...0.3.28) --- updated-dependencies: - dependency-name: futures-core dependency-type: indirect update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>
Implement VhostUserBackend instead of VhostUserBackendMut for VhostUserVsockBackend. VhostUserBackendMut trait is supposed to be used for structures without interior mutability. But VhostUserVsockBackend already uses Mutex to protect its threads, so it can implement the trait with interior mutability (i.e. VhostUserBackend). Signed-off-by: Priyansh Rathi <techiepriyansh@gmail.com>
Bumps [regex](https://github.com/rust-lang/regex) from 1.7.1 to 1.8.1. - [Release notes](https://github.com/rust-lang/regex/releases) - [Changelog](https://github.com/rust-lang/regex/blob/master/CHANGELOG.md) - [Commits](rust-lang/regex@1.7.1...1.8.1) --- updated-dependencies: - dependency-name: regex dependency-type: indirect update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
Bumps [windows_x86_64_gnu](https://github.com/microsoft/windows-rs) from 0.42.1 to 0.42.2. - [Release notes](https://github.com/microsoft/windows-rs/releases) - [Commits](https://github.com/microsoft/windows-rs/commits) --- updated-dependencies: - dependency-name: windows_x86_64_gnu dependency-type: indirect update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>
Bumps [clap](https://github.com/clap-rs/clap) from 4.1.14 to 4.2.4. - [Release notes](https://github.com/clap-rs/clap/releases) - [Changelog](https://github.com/clap-rs/clap/blob/master/CHANGELOG.md) - [Commits](clap-rs/clap@v4.1.14...v4.2.4) --- updated-dependencies: - dependency-name: clap dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
Bumps [getrandom](https://github.com/rust-random/getrandom) from 0.2.8 to 0.2.9. - [Release notes](https://github.com/rust-random/getrandom/releases) - [Changelog](https://github.com/rust-random/getrandom/blob/master/CHANGELOG.md) - [Commits](rust-random/getrandom@v0.2.8...v0.2.9) --- updated-dependencies: - dependency-name: getrandom dependency-type: indirect update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>
Bumps [futures-task](https://github.com/rust-lang/futures-rs) from 0.3.27 to 0.3.28. - [Release notes](https://github.com/rust-lang/futures-rs/releases) - [Changelog](https://github.com/rust-lang/futures-rs/blob/master/CHANGELOG.md) - [Commits](rust-lang/futures-rs@0.3.27...0.3.28) --- updated-dependencies: - dependency-name: futures-task dependency-type: indirect update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>
Bumps [rustix](https://github.com/bytecodealliance/rustix) from 0.36.12 to 0.36.13. - [Release notes](https://github.com/bytecodealliance/rustix/releases) - [Commits](bytecodealliance/rustix@v0.36.12...v0.36.13) --- updated-dependencies: - dependency-name: rustix dependency-type: indirect update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>
That buffer is used to store bytes coming from the guest before sending them to the Unix domain socket. Some use cases might want to increase or decrease this space, so it would be best to make it user-customizable. Users can use "--tx-buffer-size=" to configure TX buffer. Fixes: rust-vmm#319 Signed-off-by: uran0sH <huangwenyuu@outlook.com>
Bumps [tempfile](https://github.com/Stebalien/tempfile) from 3.4.0 to 3.5.0. - [Changelog](https://github.com/Stebalien/tempfile/blob/master/NEWS) - [Commits](https://github.com/Stebalien/tempfile/commits) --- updated-dependencies: - dependency-name: tempfile dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
Bumps [thiserror](https://github.com/dtolnay/thiserror) from 1.0.38 to 1.0.40. - [Release notes](https://github.com/dtolnay/thiserror/releases) - [Commits](dtolnay/thiserror@1.0.38...1.0.40) --- updated-dependencies: - dependency-name: thiserror dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>
Bumps [anstream](https://github.com/rust-cli/anstyle) from 0.3.0 to 0.3.2. - [Commits](rust-cli/anstyle@anstream-v0.3.0...anstream-v0.3.2) --- updated-dependencies: - dependency-name: anstream dependency-type: indirect update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>
This commit aims to allow the vhost-user-vsock to support local yaml configuration. It introduces a new parameter '--config <CONFIG>' to allow user to input a yaml configuration during startup and uses config-rs to parse it. Note that the configuration is currently made conflicted to the original input parameters. It introduces a new error -- ConfigParse inside the crates/vsock/src/vhu_vsock.rs to support runtime error handling and the new test_vsock_config_from_file() test. It includes a new README.md with a parameter specification and a config example in the Usage section. It also introduces serde_deserialize(yaml) for VsockParam to let config-rs directly pack the field specified in the array into the VsockParam as suggested in config-rs. The serde crate is added to crates/vsock/Cargo.toml correspondingly. This commit also changes the original #[clap] into #[arg] as suggested in clap-v4. Signed-off-by: Yiyang Wu <toolmanp@outlook.com>
Bumps [futures](https://github.com/rust-lang/futures-rs) from 0.3.26 to 0.3.28. - [Release notes](https://github.com/rust-lang/futures-rs/releases) - [Changelog](https://github.com/rust-lang/futures-rs/blob/master/CHANGELOG.md) - [Commits](rust-lang/futures-rs@0.3.26...0.3.28) --- updated-dependencies: - dependency-name: futures dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>
Bumps [cpufeatures](https://github.com/RustCrypto/utils) from 0.2.6 to 0.2.7. - [Commits](RustCrypto/utils@cpufeatures-v0.2.6...cpufeatures-v0.2.7) --- updated-dependencies: - dependency-name: cpufeatures dependency-type: indirect update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>
Bumps [windows_x86_64_msvc](https://github.com/microsoft/windows-rs) from 0.42.1 to 0.42.2. - [Release notes](https://github.com/microsoft/windows-rs/releases) - [Commits](https://github.com/microsoft/windows-rs/commits) --- updated-dependencies: - dependency-name: windows_x86_64_msvc dependency-type: indirect update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>
It's possible to receive backend events before the VMM contacts us to activate the vrings. Trying to call process_tx in this state will trigger a NoMemoryConfigured error which will end crashing the worker thread. As NoMemoryConfigured is a transitory error, deal with it gracefully printing a warning but continuing the normal execution. Signed-off-by: Sergio Lopez <slp@redhat.com>
It's possible to receive an incoming UDS connection before the VMM has contacted us to initialize the vrings. In this case, close the incoming connection so the client is aware of we aren't yet ready, and to avoid having a lingering incomplete connection around. Signed-off-by: Sergio Lopez <slp@redhat.com>
Signed-off-by: Li Zebin <cutelizebin@gmail.com>
Bumps [digest](https://github.com/RustCrypto/traits) from 0.10.6 to 0.10.7. - [Commits](RustCrypto/traits@digest-v0.10.6...digest-v0.10.7) --- updated-dependencies: - dependency-name: digest dependency-type: indirect update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>
Bumps [clap](https://github.com/clap-rs/clap) from 4.3.5 to 4.3.8. - [Release notes](https://github.com/clap-rs/clap/releases) - [Changelog](https://github.com/clap-rs/clap/blob/master/CHANGELOG.md) - [Commits](clap-rs/clap@v4.3.5...v4.3.8) --- updated-dependencies: - dependency-name: clap dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>
Bumps [serde_yaml](https://github.com/dtolnay/serde-yaml) from 0.9.21 to 0.9.22. - [Release notes](https://github.com/dtolnay/serde-yaml/releases) - [Commits](dtolnay/serde-yaml@0.9.21...0.9.22) --- updated-dependencies: - dependency-name: serde_yaml dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>
Bumps [rust-vmm-ci](https://github.com/rust-vmm/rust-vmm-ci) from `7e9af57` to `9dfe5b2`. - [Commits](rust-vmm/rust-vmm-ci@7e9af57...9dfe5b2) --- updated-dependencies: - dependency-name: rust-vmm-ci dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com>
Bumps [num_cpus](https://github.com/seanmonstar/num_cpus) from 1.15.0 to 1.16.0. - [Release notes](https://github.com/seanmonstar/num_cpus/releases) - [Changelog](https://github.com/seanmonstar/num_cpus/blob/master/CHANGELOG.md) - [Commits](seanmonstar/num_cpus@v1.15.0...v1.16.0) --- updated-dependencies: - dependency-name: num_cpus dependency-type: indirect update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
Bumps [itoa](https://github.com/dtolnay/itoa) from 1.0.6 to 1.0.7. - [Release notes](https://github.com/dtolnay/itoa/releases) - [Commits](dtolnay/itoa@1.0.6...1.0.7) --- updated-dependencies: - dependency-name: itoa dependency-type: indirect update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>
Signed-off-by: Erik Schilling <erik.schilling@linaro.org>
In future, we could add the ability to change the configuration at runtime and allow new guests to be added even without having to restart the daemon. So it is reasonable to not differentiate between the single and multiple VM cases, even with only one guest. Signed-off-by: Priyansh Rathi <techiepriyansh@gmail.com>
Adds support for communication between sibling VMs that use the vhost-user-vsock devices from the same vhost-user-vsock application. Tested with nc-vsock patched to set `.svm_flags = VMADDR_FLAG_TO_HOST`: host$ vhost-user-vsock \ --vm guest-cid=3,uds-path=/tmp/vm3.vsock,socket=/tmp/vhost3.socket \ --vm guest-cid=4,uds-path=/tmp/vm4.vsock,socket=/tmp/vhost4.socket vm_cid3$ nc-vsock -l 1234 vm_cid4$ nc-vsock 3 1234 Signed-off-by: Priyansh Rathi <techiepriyansh@gmail.com>
Cross-check the packet `src_cid` with the CID configured for the guest. This will forbid a VM from impersonating another. Signed-off-by: Priyansh Rathi <techiepriyansh@gmail.com>
Bumps [epoll](https://github.com/nathansizemore/epoll) from 4.3.1 to 4.3.2. - [Release notes](https://github.com/nathansizemore/epoll/releases) - [Commits](https://github.com/nathansizemore/epoll/commits) --- updated-dependencies: - dependency-name: epoll dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>
With epoll-4.3.2, bitflags moves to 2.3.3 from 1.3.2 and breaks the build with following error: error[E0369]: binary operation `!=` cannot be applied to type `Events` Fix those by using the .bits() functions. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Before bumping, the error was: error[E0554]: `#![feature]` may not be used on the stable release channel --> [...]/rustix-0.37.20/src/lib.rs:101:26 | 101 | #![cfg_attr(rustc_attrs, feature(rustc_attrs))] | ^^^^^^^^^^^^^^^^^^^^ error[E0554]: `#![feature]` may not be used on the stable release channel --> [...]/rustix-0.37.20/src/lib.rs:117:5 | 117 | feature(core_intrinsics) | ^^^^^^^^^^^^^^^^^^^^^^^^ error[E0554]: `#![feature]` may not be used on the stable release channel --> [...]/rustix-0.37.20/src/lib.rs:117:13 | 117 | feature(core_intrinsics) | ^^^^^^^^^^^^^^^ For more information about this error, try `rustc --explain E0554`. error: could not compile `rustix` (lib) due to 3 previous errors Bumped using: cargo update -p rustix --aggressive Signed-off-by: Erik Schilling <erik.schilling@linaro.org>
This version brings the SCSI bindings and allows us to drop the git dependency (which was complicating the packaging situation). Thanks-to: Jiang Liu <gerry@linux.alibaba.com> Signed-off-by: Erik Schilling <erik.schilling@linaro.org>
4.3.2 got yanked [1]. No reason was given, but it looks like a build fix for a bitflags updated [2]. Signed-off-by: Erik Schilling <erik.schilling@linaro.org> [1] https://crates.io/crates/epoll/4.3.2 [2] nathansizemore/epoll@d3a2304
Once we publish crates to crates.io, only the crate subfolder is uploaded. Symlink the license files in in order to include them during packaging. `cargo package` will replace the symlinks with the actual files during packaging, so crates.io will include the license file. Signed-off-by: Erik Schilling <erik.schilling@linaro.org>
Signed-off-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
Signed-off-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
@stefano-garzarella This is the PR as it was rebased against current upstream so it shows unrelated commits (I have to re-rebase it against this repo) Should I make a new PR with only the alsa backend? I see there is code and open PRs handling TX and streams already so the alsa backend is the biggest difference. |
Yep, would be great if you can rebase on top of
@MatiasVara @dorindabassey WDYT? |
if streams.len() <= start_id || streams.len() <= start_id + count { | ||
resp.code = VIRTIO_SND_S_BAD_MSG.into(); | ||
} else { | ||
let desc_response = descriptors[2]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we sure that we always have this layout?
I mean: descriptor[1] header and descriptor[2] payload.
Or is it an implementation detail of the linux driver?
I ask because in virtio-vsock we had a similar problem: the specification doesn't define these details and the driver initially used 2 separate descriptors for header and payload, then it started to use only one descriptor and vhost-user-vsock didn't work.
That's fine for now, but I would put a comment if that's the case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think so, at least from my understanding of the spec wording (I haven't worked with virtqueues directly before, caveat emptor)
A generic control message consists of a request part and a response part.
A request part has, or consists of, a common header containing the following device-readable field:
code
specifies a device request type (VIRTIO_SND_R_*).
A response part has, or consists of, a common header containing the following device-writable field:
code
indicates a device request status (VIRTIO_SND_S_*).
The status field can take one of the following values:
VIRTIO_SND_S_OK - success.
VIRTIO_SND_S_BAD_MSG - a control message is malformed or contains invalid parameters.
VIRTIO_SND_S_NOT_SUPP - requested operation or parameters are not supported.
VIRTIO_SND_S_IO_ERR - an I/O error occurred.
The request part may be followed by an additional device-readable payload, and the response part may be followed by an additional device-writable payload.
So in this case the generic ctrl header is followed by the additional device-readable payload, and then the response comes after.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, so even in this case it's an implementation detail of the driver. Nothing prevents it from using a single writable descriptor to contain both the header and the response payload, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Almost all rust-vmm daemons get this wrong in one way or another... We would really need something like rust-vmm/vm-virtio#33 to prevent daemons from needing to worry about this stuff...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, I came to the same conclusion.
So that's okay in my opinion for now, but we should put comments where we make this assumption to say that's how the driver works in Linux 6.4.
WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@epilys header and payload could be on a single buffer, though, couldn't they?
The important thing is not to mix writable and readable buffers, but then for virtqueue it can contain anything as long as it's contiguous memory. So nothing should prevent the driver from using a single contiguous memory area and expecting the device to write both the header and the response payload there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
are they considered the same element? (response header + payload)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I think what you quoted above talks about an "element" in the virtqueue. So the element there is a descriptor chain. The chain then can have any form (as long as r/w constraints are satisfied) and consist of multiple descriptors.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
an element for the virtqueue are just contiguous bytes, then as each device uses them, they are a higher level of abstraction
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see, thanks!
Signed-off-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
Signed-off-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
Signed-off-by: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
Didn't rebase yet against |
is this the struct you are referring to?
I think the next PR fixes that, so once we merge it, I think you should be able to rebase on top of it. |
I wonder if it make sense to you to split the PR into maybe 3 or 4, it depends - (documentation, "changes for ctrl queue, tx and rx queue that you think is nice to have", and the alsa-Backend.) IMHO that would simplify the review and merge process. |
@dorindabassey you can view each commit separately, there are standalone commits for CTRL queue, TX queue and the alsa backend. Click on the files changed tab and select "view changes for X/Y/Z commit" |
Hi Manos, Everything is okay now, I think you can rebase your PR on top of our current work. Just a small note - please take care with the rebasing so that the already existing changes do not get lost. thank you :) |
Summary of the PR
This PR adds a new crate,
vhost-user-sound
, that provides avhost-user
backend daemon for the VIRTIO Sound device as specified in the VIRTIO Spec v.1.2 1Supported features are:
Buffer/period settings need some tuning, the first period seems to come up short; I'm not familiar with ALSA programming at all.
What remains to be done:
Usage / Testing functionality
This PR was tested with QEMU, with a proposed patchset that enables generic
vhost-user
devices in virtualized guests 2, contributed by @stsquad.The following command line invocations were used:
Run the
vhost-device
daemonRun a guest in QEMU
Apply the patchset 2.
Apply these patches to create a
vhost-user-snd
andvhost-user-snd-pci
device 3.[PATCH] Add virtio-sound and virtio-sound-pci devices
[PATCH] Add vhost-user-snd and vhost-user-snd-pci devices
Build for desired target architecture, e.g.
x86_64
.Get/build kernel configured with
CONFIG_SND_VIRTIO
.Launch QEMU with
Use
speaker-test -l 1
to play some pink noise for one loop (-l N
) orspeaker-test -t wav -w /path/to/file.wav -l 1
.Requirements
git commit -s
), and the commitmessage has max 60 characters for the summary and max 75 characters for each
description line.
test.
Release" section of CHANGELOG.md (if no such section exists, please create one).
unsafe
code is properly documented.Footnotes
Virtual I/O Device (VIRTIO) Version 1.2 Committee Specification Draft 01 09 May 2022 ↩
https://patchew.org/QEMU/20230418162140.373219-1-alex.bennee@linaro.org/ ↩ ↩2
https://github.com/epilys/qemu-virtio-snd/commits/54ae1cdd15fef2d88e9e387a175f099a38c636f4 ↩