This may help reduce cases of conflicts between independent CLs each
appending a dependency at the bottom of the list, of which I hit two
today rebasing some of my open CLs.
TEST=cargo check --all-features
Change-Id: Ief10bb004cc7b44b107dc3841ce36c6b23632aed
Reviewed-on: https://chromium-review.googlesource.com/1557172
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Tested-by: David Tolnay <dtolnay@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
This cleans up some feature flag plumping for libusb sandboxing as well.
BUG=chromium:831850
TEST=cargo test
CQ-DEPEND=CL:1512762
Change-Id: Ic70784db204ddced94498944b021bcb7dd708bb1
Reviewed-on: https://chromium-review.googlesource.com/1522214
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Jingkui Wang <jkwang@google.com>
Reviewed-by: Jingkui Wang <jkwang@google.com>
Those are bridges between xhci and backend.
CQ-DEPEND=CL:1510818
BUG=chromium:831850
TEST=cargo test
Change-Id: I04feab449d48b0c908aeebfda08d1869239cbe6f
Reviewed-on: https://chromium-review.googlesource.com/1510819
Commit-Ready: Jingkui Wang <jkwang@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
The Ac97 device provides the guest with an audio playback device. All
input devices are stubbed out. Only playback at 48kHz is supported.
The device is emulated by `Ac97Dev` which interfaces with the PCI bus.
`Ac97Dev` uses `Ac97` to drive audio functions and emulate the device
registers. Physical Ac97 devices consist of two parts, the bus master
and a mixer. These two sets of registers are emulated by the
`Ac97BusMaster` and `Ac97Mixer` structures.
`Ac97BusMaster` handles audio samples and uses `Ac97Mixer` to determine
the configuration of the audio backend.
BUG=chromium:781398
TEST=crosvm run --disable-sandbox --null-audio --rwdisk gentoo.ext4 -c2
-m2048 -p 'root=/dev/vda snd_intel8x0.inside_vm=1
snd_intel8x0.ac97_clock=48000' vmlinux.bin
and play audio with aplay -d2 -Dhw:0,0 -f dat /dev/urandom
CQ-DEPEND=CL:1402264
CQ-DEPEND=CL:1421588
CQ-DEPEND=CL:1433794
CQ-DEPEND=CL:1432835
Change-Id: I9985ffad753bccc1bf468ebbdacec0876560a5e0
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1366544
Commit-Ready: Chih-Yang Hsia <paulhsia@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Chih-Yang Hsia <paulhsia@chromium.org>
Reviewed-by: Chih-Yang Hsia <paulhsia@chromium.org>
This CL adds a "tpm" Cargo cfg to crosvm which enables a TPM device
backed by libtpm2 simulator.
Tested by running the following inside cros_sdk:
LIBRARY_PATH=~/src/minijail LD_LIBRARY_PATH=~/src/minijail \
cargo run --release \
--features tpm \
-- \
run \
-r rootfs.ext4 \
--seccomp-policy-dir seccomp/x86_64/ \
-p init=/bin/bash \
-p panic=-1 \
--disable-sandbox \
vmlinux.bin
with a Linux image built from CL:1387655.
The TPM self test completes successfully with the following output:
https://paste.googleplex.com/5996075978588160?raw
Justin's TPM playground runs with the following trace output.
https://paste.googleplex.com/4909751007707136?raw
Design doc: go/vtpm-for-glinux
TEST=ran TPM playground program inside crosvm
TEST=local kokoro
BUG=chromium:911799
Change-Id: I2feb24a3e38cba91f62c6d2cd1f378de4dd03ecf
Reviewed-on: https://chromium-review.googlesource.com/1387624
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Tested-by: David Tolnay <dtolnay@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
This change uses the resource bridge between virtio-gpu and virtio-cpu
to send resources over the host wayland connection that originated from
the virtio-gpu device. This will help support gpu accelerated wayland
surfaces.
BUG=chromium:875998
TEST=wayland-simple-egl
Change-Id: I3340ecef438779be5cb3643b2de8bb8c33097d75
Reviewed-on: https://chromium-review.googlesource.com/1182793
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
This CL adds a crate `sync` containing a type sync::Mutex which wraps
the standard library Mutex and mirrors the same methods, except that
they panic where the standard library would return a PoisonError. This
API codifies our error handling strategy around poisoned mutexes in
crosvm.
- Crosvm releases are built with panic=abort so poisoning never occurs.
A panic while a mutex is held (or ever) takes down the entire process.
Thus we would like for code not to have to consider the possibility of
poison.
- We could ask developers to always write `.lock().unwrap()` on a
standard library mutex. However, we would like to stigmatize the use
of unwrap. It is confusing to permit unwrap but only on mutex lock
results. During code review it may not always be obvious whether a
particular unwrap is unwrapping a mutex lock result or a different
error that should be handled in a more principled way.
Developers should feel free to use sync::Mutex anywhere in crosvm that
they would otherwise be using std::sync::Mutex.
TEST=boot linux
Change-Id: I9727b6f8fee439edb4a8d52cf19d59acf04d990f
Reviewed-on: https://chromium-review.googlesource.com/1359923
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Tested-by: David Tolnay <dtolnay@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
The virtio PCI spec (4.1.5.2 Notifying The Device) says:
"The driver notifies the device by writing the 16-bit virtqueue index
of this virtqueue to the Queue Notify address."
We were previously registering the notify address specifying
NoDatamatch; switch this to a 16-bit match of the queue index to follow
the specification.
BUG=chromium:854766
TEST=Boot crosvm with virtio devices converted to PCI
Change-Id: Ic950a8c7751268f7fcc21d5c37b0afc859f1e6d0
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1265861
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Implement a new virtio_9p device to be used for sharing directories with
the VM.
BUG=chromium:703939
TEST=mount inside a VM and run `bonnie++ -r 256`
Append the shared directory to the crosvm command line:
--shared-dir /path/to/dir:test_9p
Then mount in the guest:
mkdir /tmp/9p
mount -t 9p -o trans=virtio test_9p /tmp/9p -oversion=9p2000.L
Or for a 9p root:
run --shared-dir /mnt/vm_root:/dev/root -p 'root=/dev/root ro rootflags=ro,trans=virtio,version=9p2000.L,cache=loose rootfstype=9p' vmlinux.bin
CQ-DEPEND=CL:1065170
Change-Id: I41fc21306ab5fa318a271f172d7057b767b29f31
Signed-off-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1065173
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Basic 2D and 3D support is there. The drm_cursor_test and
null_platform_test in drm-tests should run to completion.
The extra device is hidden behind both a build time feature called 'gpu'
and the device is only added to a VM if the '--gpu' flag is given.
TEST=build with --features=gpu;
drm_cursor_test && null_platform_test
BUG=chromium:837073
Change-Id: Ic91acaaebbee395599d7e1ba41c24c9ed2d84169
Reviewed-on: https://chromium-review.googlesource.com/1036862
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Combine GPU buffer allocation with the system resource allocator making
life easier as only one allocator needs to get passed to the execute
function.
Change-Id: I199eb0fd6b99b629aaec1ae3295e8a1942da5309
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1099856
This implements DMABuf allocation type in the virtio wayland
device.
We attempt to locate a supported DRM device prior to engaging
the device jail. If found, the DRM device is passed to the
wayland device code and used to serve DMABuf allocations.
DMABuf support can be disabled by not providing crosvm with
access to any DRM device nodes.
The guest is expected to handle the case when DMABuf allocation
fails and fall-back to standard shared memory.
This initial change uses DRM directly but is structured in a
way that would allow the allocator to be replaced by minigbm
with minimal effort.
BUG=chromium:837209
TEST=crosvm finds drm device and returns valid dmabufs to guest
Change-Id: Ic1fd776dfdfefae2d7b321d449273ef269e9cc62
Reviewed-on: https://chromium-review.googlesource.com/1034088
Commit-Ready: David Reveman <reveman@chromium.org>
Tested-by: David Reveman <reveman@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Using minijail_fork removes the need to manage user and pid namespace
explicitly in crosvm and removes some parent/child synchonization
requirements too.
Change-Id: I47f9d39527d0a3ccf625600e9bfc2cccc3cb27ca
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/719443
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Moving the devices to their own module makes it easier to add tests that
use them.
Change-Id: I61bfef4037d16b20145b5fddce604835cdc4f67b
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/706559
Reviewed-by: Zach Reizner <zachr@chromium.org>
