Now that the connection oriented seqpacket sockets are used for vm
control messages, a response can be received by the requested. This
change prints out that response.
TEST=crosvm suspend|resume|balloon|stop <socket>
BUG=chromium:848187
Change-Id: I18ac23c26127332e2be498113cc0c3310fd09a7d
Reviewed-on: https://chromium-review.googlesource.com/1482370
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
The advantage of seqpacket is that they are connection oriented. A
listener can be created that accepts new connections, useful for the
path based VM control sockets. Previously, the only bidirectional
sockets in crosvm were either stream based or made using socketpair.
This change also whitelists sendmsg and recvmsg for the common device
policy.
TEST=cargo test
BUG=chromium:848187
Change-Id: I83fd46f54bce105a7730632cd013b5e7047db22b
Reviewed-on: https://chromium-review.googlesource.com/1470917
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
This change adds the ability to make seqpacket pairs, and set the
timeouts of the sockets. This also adds a TcpListener style api for
accepting UnixSeqpacket sockets.
TEST=cargo test -p sys_util
BUG=chromium:848187
Change-Id: I9f9bb5224cdfaf257d8e4a1bdaac8128be874951
Reviewed-on: https://chromium-review.googlesource.com/1482371
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
These panic!()s might be user-triggerable, and in any event are not fatal errors.
BUG=chromium:908689
TEST=Unit tests in file.
Change-Id: I774bb633dc627247bd807727542589400b59ed07
Reviewed-on: https://chromium-review.googlesource.com/1487674
Commit-Ready: Miriam Zimmerman <mutexlox@chromium.org>
Tested-by: Miriam Zimmerman <mutexlox@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
This allows the default pivot root used by crosvm to be defined at
build time. If it is not set, /var/empty is used.
BUG=chromium:934513,chromium:933582
TEST=PreCQ passes
Change-Id: I2b461170e6b75324740d4ff709fd599085cefe18
Reviewed-on: https://chromium-review.googlesource.com/1483330
Commit-Ready: Allen Webb <allenwebb@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Add a script to run `cargo fmt` on all Rust code contained in crosvm.
This is different from `cargo fmt --all` which formats multiple crates
but a single workspace only. Crosvm consists of multiple workspaces.
Usage:
$ bin/fmt
To print a diff and exit 1 if code is not formatted, but without
changing any files, use:
$ bin/fmt --check
TEST=those commands
TEST=local kokoro
Change-Id: I4194509ad3a1bbc829c4b1069d54d940b927113b
Reviewed-on: https://chromium-review.googlesource.com/1477498
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Tested-by: David Tolnay <dtolnay@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
These are each their own workspace so I guess `cargo fmt` at the top
level of the repo does not hit them.
I checked that none of the other workspace roots currently need to be
reformatted.
TEST=cargo check
Change-Id: I734cbc0f909fd3c2138513d9539b917bce80c0a8
Reviewed-on: https://chromium-review.googlesource.com/1477496
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>
Gate the current software tpm device behind a crosvm flag called
`--software-tpm`. When we get to leveraging the physical tpm, we will
likely want that behind a separate `--hardware-tpm` flag that is
automatically detected when the vm being launched is gLinux.
Based on feedback from apronin:
> Hm, long-term it may actually make sense to have software-tpm and
> real-tpm-for-glinux as two separate run-time options and only enable
> real-tpm-for-glinux for glinux.
>
> we want to protect guests from exploits, but we also want to limit
> access to tpm for random guests. So, enterprises may set this to "no
> TPM" for Linux images their employees run on their devices, so that
> they don't get creative with trying to break TPM from inside those
> images.
BUG=chromium:911799
TEST=run TPM playground program inside crosvm with flag set
TEST=confirm TPM playground does not run with flag unset
Change-Id: I1bccf62be63d40203463623f43b1a6ee2d51f6c0
Reviewed-on: https://chromium-review.googlesource.com/1478377
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Tested-by: David Tolnay <dtolnay@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
During review of CL:1387655 we observed that it shouldn't be necessary
for both vtpm_op_send and vtpm_op_recv to perform virtqueue kicks. It
should be sufficient for vtpm_op_send to place both an output buffer and
an input buffer on the virtio queue as a single descriptor chain, and
perform a single kick that executes both operations.
This requires a larger virtio queue because a single virtio buffer
cannot be both read and written.
BUG=chromium:911799
TEST=run TPM playground program inside crosvm
Change-Id: I6822efc3318a3952f91f64904e0434d916beae97
Reviewed-on: https://chromium-review.googlesource.com/1465642
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Tested-by: David Tolnay <dtolnay@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Cleanup only -- no functional change intended.
A lot of the current TPM virtio device is closely based on previously
existing virtio devices. This CL cleans up the TPM device in preparation
for a change that will let it handle send+recv as a single descriptor
chain.
- Pass all EventFds together inside of the Worker object.
- Introduce an Error enum to enable use of `?` error handling.
- Introduce NeedsInterrupt enum to clarify meaning of return value of
Worker::process_queue.
- Simplify code for instantiating Worker and spawning thread.
TEST=run TPM playground inside crosvm
Change-Id: I4a9a4b379a28d2336a1d9f2dce46f013e647ea16
Reviewed-on: https://chromium-review.googlesource.com/1478381
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>
Use of this value was removed in CL:1446932.
TEST=cargo check gpu_renderer
Change-Id: I8473cbddd074bb553187532926b7c6a870a24a51
Reviewed-on: https://chromium-review.googlesource.com/1477499
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: David Tolnay <dtolnay@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: David Riley <davidriley@chromium.org>
I have been running into Debug-printed error messages too often and
needing to look up in the source code each level of nested errors to
find out from the comment on the error variant what the short name of
the variant means in human terms. Worse, many errors (like the one shown
below) already had error strings written but were being printed from the
calling code in the less helpful Debug representation anyway.
Before:
[ERROR:src/main.rs:705] The architecture failed to build the vm: NoVarEmpty
After:
[ERROR:src/main.rs:705] The architecture failed to build the vm: /var/empty doesn't exist, can't jail devices.
TEST=cargo check --all-features
TEST=FEATURES=test emerge-amd64-generic crosvm
Change-Id: I77122c7d6861b2d610de2fff718896918ab21e10
Reviewed-on: https://chromium-review.googlesource.com/1469225
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>
The Chrome OS Rust toolchain has been updated to Rust 1.32.0[1]; update
the version in Kokoro and the rust-toolchain file to match.
It looks like there is also one minor formatting change (again).
BUG=None
TEST=Build kokoro image and run tests
[1]: https://chromium-review.googlesource.com/1432733
Change-Id: I5669d99463618e19cb5e957171560dbea33bd5b8
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1470913
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Update the default Rust toolchain to the version specified in the
rust-toolchain file (which is part of the crosvm source directory, not
baked into the Docker image) during each kokoro run.
This will let us seamlessly update rust-toolchain without breaking the
builds using the existing kokoro Docker image once this change is in
place.
BUG=None
TEST=Build image with 1.31.0, then run test with rust-toolchain 1.32.0
Change-Id: If4f6dffc20af33011d2a96a0cf6b3db3582a2fd0
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1470914
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: David Tolnay <dtolnay@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
PluginVm uses /dev/urandom, so we need to mount it, along with
/dev/zero, /dev/null, and /dev/full.
Note that we are not using minijail's mount_dev() API because it will
try to create tmpfs without using MS_NODEV flag and, since crovm may not
have CAP_SYS_ADMIN capability, Chrome OS LSM will stop it. So we rely on
the parent process to have minimal set of devices present and bind-mount
those into the jail.
BUG=b:117989168
TEST=cargo test --features=plugin
Change-Id: I6d8ab122c56614a8f7dbfe3d0eb8ed33532dc6a7
Signed-off-by: Dmitry Torokhov <dtor@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1447551
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
I was skimming the gpu flag code (tpm will need something similar) and
found the way resource_bridge_wl_socket is used misleading. The same
variable is declared in two different places depending on whether
building with gpu. This CL combines them into one `let` statement.
Also moved the generic param onto None which comes out more readable
after rustfmt while still providing helpful context for the reader.
TEST=cargo check && cargo check --features gpu
Change-Id: I57a1ae214947475efa7bf01ab123a71a58411244
Reviewed-on: https://chromium-review.googlesource.com/1470915
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Tested-by: David Tolnay <dtolnay@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Allow --tap-fd to be given mutliple times, a different virtual network
card will be added each time the flag is given.
Additionally, --tap-fd is no longer mutually exclusive with --host-ip,
etc.
Bug=chromium:931470
Test=booted cuttlefish device with multiple network cards
Change-Id: I4108f97c7f4b19db12fcb3c533088a04a58e56db
Reviewed-on: https://chromium-review.googlesource.com/1469222
Commit-Ready: Jorge Moreira Broche <jemoreira@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Jorge Moreira Broche <jemoreira@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
This exports a new C API to resize a disk image. The new function is
intended to only expand (increase in size) to avoid accidentally
truncating user data due to bugs elsewhere.
BUG=chromium:858815
TEST=build_test.py
Change-Id: I6f834209aba693618e0f51d920e7b73d4f2a9dfc
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1464384
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
The glibc realloc() implementation may call the mremap syscall in some
cases; we currently allow mremap in x86_64/common_device.policy but not
the arm equivalent, but this path appears to be reachable on any Linux
platform[1]. Add mremap to the arm policy as well for consistency.
mremap is no more powerful than the existing mmap and munmap syscalls,
so I believe this is safe to allow for all device processes.
Also reorder the mmap2 line in the arm policy so it is in alphabetical
order and can be more easily compared to the x86_64 policy.
BUG=chromium:927919
TEST=Boot crosvm on kevin
[1]: https://sourceware.org/git/?p=glibc.git;a=blob;f=malloc/malloc.c;h=6e766d11bc85b6480fa5c9f2a76559f8acf9deb5;hb=HEAD#l2854
Change-Id: Ie51a21baf30d3e37ce3adacf8e255f981613543d
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1459020
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Remove a bunch of TODOs that mention things that the C++ test does that
we don't need to do, and replace a TODO with a detailed explanation of
why the code behaves as it does.
BUG=chromium:908689
TEST=None; comment-only change
Change-Id: I6791fbe329e8cdd1cac0d55b7770927d60c051c4
Reviewed-on: https://chromium-review.googlesource.com/1454141
Commit-Ready: Miriam Zimmerman <mutexlox@chromium.org>
Tested-by: Miriam Zimmerman <mutexlox@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Some of the variants of the CommandCounter enum are not currently used;
add a directive to ignore dead code warnings for these variants, since
they are defined by the hardware/spec and may be used in the future.
BUG=None
TEST='cargo build' executes without warnings
Change-Id: I72b6cd24722de801ebfe63bb7419c4e972463082
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1454139
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Miriam Zimmerman <mutexlox@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
The default panic hook prints panic information and a backtrace to
stderr, where it gets dropped into /dev/null in the typical crostini
context.
This change adds a panic hook that will call the default panic hook
with stderr redirected to a pipe, which will then get forwarded to
syslog.
The new hook also forces an abort at the end to ensure the crash
reporter sees the panicked crosvm process, which will generate a
minidump for later debugging.
TEST=manually add panic!() observe /var/log/messages
BUG=None
Change-Id: I4e76afe811943e55cec91761447e03b949a674a4
Reviewed-on: https://chromium-review.googlesource.com/1440881
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Based on Linux boot protocol references:
- x86: Documentation/x86/boot.txt
- arm: Documentation/devicetree/bindings/chosen.txt
BUG=None
TEST=Boot Alpine Linux netboot initrd on x86_64 and aarch64
Change-Id: If4730765638f0a0b8bb8f63203c98e4765a354ee
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1407221
Tested-by: kokoro <noreply+kokoro@google.com>
This will allow placement of the initrd after the end of the device tree
blob in the next patch.
This also moves the load of the fdt into setup_system_memory() so that
the position of the initrd can be calculated (in the next patch) before
calling configure_system().
BUG=None
TEST=Boot Termina on x86-64
Change-Id: I6dcfce3aa48ae0932157a40fa28ea9fb384263c8
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1443634
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
EXT_sRGB_write_control was not getting advertised due to virgl not
performing EGL initialization. Move crosvm over to using the normal
virgl EGL initialization path.
BUG=chromium:925569
TEST=piglit/bin/fbo-srgb
Change-Id: I1acc5823ef1922395f1a6bf8e7996b23ee4c3632
Reviewed-on: https://chromium-review.googlesource.com/1446932
Commit-Ready: David Riley <davidriley@chromium.org>
Tested-by: David Riley <davidriley@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
This allows decoupling input from the wayland socket while using a
standard virtio device for it. The proposed virtio input spec can be
found at
https://www.kraxel.org/virtio/virtio-v1.0-cs03-virtio-input.pdf, it
has already been implemented in qemu and (guest) kernel support exists
since version 4.1.
This change adds the following options to crosvm:
--evdev: Grabs a host device and passes it through to the guest
--<device>: Creates a default configuration for <device>,
receives the input events from a unix socket. <device> can be
'keyboard', 'mouse' or 'trackpad'.
Bug=chromium:921271
Test=booted on x86 linux and manually tried virtio-input devices
Change-Id: I8455b72c53ea2f431009ee8140799b0797775e76
Reviewed-on: https://chromium-review.googlesource.com/1412355
Commit-Ready: Jorge Moreira Broche <jemoreira@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
As reported by the Firecracker team, the block device model doesn't
check if an I/O request starts before the end of the disk but extends
beyond it. For writes to disks backed by raw files, this could end up
unintentionally extending the size of the disk.
Add bounds checks to the request execution path to catch these
out-of-bounds I/Os and fail them. While we're here, fix a few other
minor issues: only seek for read and write requests (the 'sector' field
of the request should be ignored for flush, write zeroes, and discard),
and check for overflow when performing the shifts to convert from
sectors to bytes.
BUG=chromium:927393
TEST=cargo test -p devices block
Change-Id: I0dd19299d03a4f0716093091f173a5c507529963
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1448852
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Some IOCTL macros are define to accept a parameter, EVIOCGBIT is an
example. This commit adds the ability to generate functions that
accept any number of arguments to generate the IOCTL number.
Bug=chromium:921271
Test=cargo test -p sys_util
Change-Id: I966a3ac85e05764acff5d61cf85dc95b2b70ec20
Reviewed-on: https://chromium-review.googlesource.com/1406812
Commit-Ready: Jorge Moreira Broche <jemoreira@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
This plumbs in minijail_mount_dev() to allow mounting minimal set of
devices, such as full, zero, urandom, etc. in the jail.
BUG=b:117989168
TEST=cargo test -p io_jail
Change-Id: I072347a5eedab32d1fad6255c4e18e0242b9ac9f
Signed-off-by: Dmitry Torokhov <dtor@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1447330
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
By default virglrenderer logs to stderr with VREND_DEBUG. dup stdout
which is logged via logger to stderr so that virglrenderer logs can be
seen.
BUG=chromium:925590
TEST=cat /var/log/messages
Change-Id: I3e1a5056dab9cfd895867b1835b421b144ee536b
Reviewed-on: https://chromium-review.googlesource.com/1441352
Commit-Ready: David Riley <davidriley@chromium.org>
Tested-by: David Riley <davidriley@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
The fork::tests::panic_safe unit test has been hanging intermittently in
CQ runs. The root cause isn't understood yet, but the most likely
explanation seems to be that the wait_process helper is hanging.
There should be only two causes for that hang: either the cloned process
is not exiting, or the wait() call in wait_process is not returning.
The wait() should only hang if another thread has already reaped the
cloned process.
In order to help debug the issue, change the general wait() to a
waitpid() on the specific cloned process ID. This will give us more
information about what happens when the test fails - if the waitpid()
returns ECHILD instead of hanging, this will indicate that something
else is waiting on our child process and racing with our wait().
BUG=chromium:925725
TEST=cargo test --release -p sys_util panic_safe
Change-Id: Ib25d88b35b16c75d4d8fe62fc779c9470303368a
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1444317
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Logically, each VCPU is using GuestMemory, which holds a ref count to
the underlying memory mappings. This change formalizes this by giving an
actual reference of GuestMemory to each Vcpu struct.
This change is needed because the Vm can go out of scope and clean up
its reference, but the Vcpus may still be running, triggering an EFAULT
and a lot of confused days spent debugging.
TEST=With the unwind panic handler, trigger a panic right after the
final vcpu thread barrier. If the VCPU threads do not complain
about EFAULT (errno 14), this change worked.
BUG=None
Change-Id: I6289147de0adde61c81630357701487937b17ade
Reviewed-on: https://chromium-review.googlesource.com/1441355
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
This device tree is derived from the Android fstab file which is
provided via command line flag.
BUG=chromium:922737
TEST=None
CQ-DEPEND=CL:1415390
CQ-DEPEND=CL:1415270
Change-Id: Idd007c844f84cab3ff37be16a718f14e5f630312
Reviewed-on: https://chromium-review.googlesource.com/1370058
Commit-Ready: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dylan Reid <dgreid@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>
After trying symlinks and bind-mounts and various other shenanigans,
give up and move the crosvm working directory to a relative path that is
the same as in the chrome OS chroot.
This allows other crates in the cros checkout to find the crosvm crates
they depend on.
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Change-Id: I643497f08c59328e02775ad3ac0ef9feafbf2930
Reviewed-on: https://chromium-review.googlesource.com/1436595
Commit-Ready: Chih-Yang Hsia <paulhsia@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Chih-Yang Hsia <paulhsia@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Each device (Bus, Pci, Proxy, etc), gets a debug label associated with
it. When a child is spawned, the debug label for it is stored in
a map with the child's pid as the key. If a SIGCHLD is handled, this map
is used to print a more helpful message about exactly which child died.
BUG=None
TEST=run with sandboxing and a faulty child device
check logs for message about child died
the child should have a debug label
Change-Id: I61fbbee0a8e701249533a7a3a6a1ad48840f12e5
Reviewed-on: https://chromium-review.googlesource.com/1432835
Commit-Ready: Chih-Yang Hsia <paulhsia@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Some crates that are needed for crosvm need crates that live inside the
crosvm directory. To allow those crates to be used, add a symlink that
allows access to the crosvm source code from a path equivalent to that
used inside the Chrome OS chroot.
In particular, the cras crate is needed by devices and devices needs the
data_model and sys_util crates. Creating a platform/crosvm directory
parallel to the third_party/adhd directory lets the build of the cras
crates find their dependencies.
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Change-Id: I2a1e28638e80c8008b1ecc29c2b0b69cba1c13e2
Reviewed-on: https://chromium-review.googlesource.com/1433518
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Chih-Yang Hsia <paulhsia@chromium.org>
