This crate will house code using the new async/await features to be used
by other parts of crosvm.
Start the crate with a Future executor that runs tasks in a single
thread and allows futures that block on system file descriptors.
Change-Id: If77778ac056210dabbfc6e6e1e63df1c1b904a7f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1955045
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Tested-by: Dylan Reid <dgreid@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
Driver use virtio_wmb() before avail_index updating, here fence() is
compared with it, this guarantee that the descriptor_index is read after
avail_index.
BUG=none
TEST=run fio_read and fio_write in guest
Change-Id: I6a5e1bc7c915effd433b05aca246302c5a3e313c
Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.corp-partner.google.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2035079
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
The EventFd that wraps the MaybeOwnedFd will close the fd, but so will
MaybeOwnedFd, causing a double-close.
BUG=None
TEST=strace crosvm run
Change-Id: I277386cd20eaa1a8187274cc16084b1936355012
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2034026
Commit-Queue: Zach Reizner <zachr@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Xiong Zhang <xiong.y.zhang@intel.corp-partner.google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
This change adds the `recv_*_vec` suite of methods for getting an entire
packet into a `Vec` without needing to know the packet size through some
other means.
TEST=cargo test -p sys_util -p msg_socket
BUG=None
Change-Id: Ia4f931ccb91f6de6ee2103387fd95dfad3d3d38b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2034025
Commit-Queue: Zach Reizner <zachr@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Auto-Submit: Zach Reizner <zachr@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
The build-time seccomp compiler for aarch64 complains that it doesn't
recognize open, epoll_wait, recv, mmap2, dup2, poll, mkdir, or stat.
I tried to propose a change to upstream minijail to make it aware of
these syscalls, but the calls are in various forms of deprecation
so upstream is doubting the sanity of the policy files.
I applied the following mapping: open->openat, epoll_wait->epoll_pwait,
recv->recvfrom, mmap2->mmap, dup2->dup3, poll->ppoll, mkdir->mkdirat,
and stat->statx. In many cases the new syscall was already present so I
just deleted the old one.
BUG=None
TEST=Ran compile_seccomp_policy.py with an unmodified minijail until
it stopped complaining. I don't have an arm device for runtime testing.
Wrote an app to emulate the execution of the first 400 syscall #s though
the bpf filter and verified that the list that matches the filter is the
same as the policy file.
Change-Id: I599aa549a1712b898eb6b73492872a9676e7215d
Signed-off-by: Matt Delco <delco@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2036218
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Vhost-net reset method can stop the activate thread and let it to
return the ownership of eventfds and tap back to the device, so that
it is possible to be activated again.
BUG=None
TEST=launch Crosvm guest with vhost-net. It works fine with iperf test.
TEST=cargo test -p devices
Change-Id: I8f3cb6939595b4dffa0e95bcffbf9fcc8fcf71ba
Signed-off-by: Chuanxiao Dong <chuanxiao.dong@intel.corp-partner.google.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2009665
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
the event_source needs to be returned through the reset method to allow
the virtio-input device model reactivated again.
BUG=None
TEST=cargo test -p devices
Change-Id: I07a4add40b1c233e1ed328ccef1a1abd453ea0f7
Signed-off-by: Chuanxiao Dong <chuanxiao.dong@intel.corp-partner.google.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2032351
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
These were pinned at pre-1.0 versions. Update to the stable API to allow
new features to be used in the future.
Cq-Depend: chromium:2026764
Change-Id: Id2d979525e5210436cbb1cfa61e2b05fafb288f3
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2025907
Tested-by: Dylan Reid <dgreid@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
worker.run might encounter error when running but we still need it
to give the ownerships of the kill eventfd back so that it
can have a second round activate. And Worker structure also contains
several other eventfds which will be needed for a second round activate
so change to put this eventfd into Worker as well.
BUG=None
TEST=launch Crosvm guest with vhost-net and vsock. Both of them work fine.
TEST=cargo test -p devices
Change-Id: I34477cfa3de23d7ab849f741d0ffb098c720a629
Signed-off-by: Chuanxiao Dong <chuanxiao.dong@intel.corp-partner.google.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2009664
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Dylan Reid <dgreid@chromium.org>
The high 32 bits of writable_bits was set incorrectly when adding 64-bit
memory BARs to PciConfiguration: it would effectively always be all
zeroes (no writable bits) instead of all ones (all writable bits).
The writable_bits field is used to determine which bits to force to 0
when reading the BAR, which is used by the guest to determine the size
of a BAR: write an all-ones value to the BAR, read it back, and the
resulting value has only the writable bits still set. Since PCI BARs
must be a power of two in size, the effective size of the BAR is the
bitwise inverse of the resulting value plus one.
For 64-bit BARs, this process is the same, except that two contiguous
32-bit registers are combined, so for a 4096-byte 64-bit BAR, the
writable_bits field should be 0xFFFFFFFF_FFFFF000; however, with the
previous (buggy) code, it was 0x00000000_FFFFF000.
Add checks to the unit tests to verify that the writable_bits field is
correctly calculated as well.
BUG=None
TEST=cargo test -p devices pci_configuration
TEST=Boot Linux 4.19 kernel in crosvm
Change-Id: Ib97aa5dccf9bf042328c0fc9defe1797fc67bb05
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2033620
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
The default is 2015 and that causes any usage of `async` to cause kokoro
errors.
Change-Id: I9f962b6f578b0d1992377dfefdd724c080a6f1b5
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2024365
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
Minijail's policy compiler complains when there's multiple
unconditional rules for a syscall. In most cases the rules
are redundant to common_device.policy.
BUG=None
TEST=Ran compile_seccomp_policy.py until it stopped
complaining.
Change-Id: Ic43d1fd13f9c012641d71e526942229eb8b08ed4
Signed-off-by: Matt Delco <delco@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2034024
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Allow mounts from the parent namespace to propagate into the mount
namespace of the 9p device process.
BUG=none
TEST=none
Change-Id: Iff455c8967949bd3e0f2990c947d45bbbc541d45
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2018305
Reviewed-by: Yusuke Sato <yusukes@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Tested-by: Yusuke Sato <yusukes@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Chirantan Ekbote <chirantan@chromium.org>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
Transfer TRBs have a flag that indicates that data is transferred within
the TRB itself instead of as a separate buffer. Add support for this
type of transfer in the ScatterGatherBuffer implementation.
This fixes USB support when using Linux 5.1+ as the guest kernel, since
it now uses immediate data transfers.
BUG=chromium:1046564
TEST=`adb root` to connected phone on Linux 5.4 guest kernel
Change-Id: I6c37db422ac8e65d10e1a91807b15e903ad614de
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2026262
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Add a function to get a resource FD via resource_bridge by extracting code from
the wayland device implementation.
This function will be used by virtio-video devices.
BUG=b:147465619
TEST=Run ARCVM and check that a window is displayed
Change-Id: I7b064c9a04bd082e30dd488d0b14731228e6047d
Signed-off-by: Keiichi Watanabe <keiichiw@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2014520
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
... which does not require virglrenderer (or any renderer).
This will allow the Cuttlefish team to use minigbm as its gralloc
implementation when both hardware acceleration is available and
unavailable.
Adds a GPU `Backend` trait with all of the existing methods of the
current backend and converts the existing `Backend` into
`Virtio3DBackend` which implements the new trait.
Adds a `Virtio2DBackend` which creates resources with byte vectors on
the host and implements transfers via the old code from
gpu_buffer/src/lib.rs.
Adds a runtime flag to select between 2D and 3D mode with 3D mode as
the default.
Moves the process_resource_bridge() function to the `Frontend` and
instead expose a export_resource() function on the `Backend` to avoid
some code duplication.
BUG=b:123764798
TEST=build + launch cuttlefish w/ 2D mode (minigbm + custom hwcomposer)
TEST=built + launch cuttlefish w/ 2D mode (minigbm + drm_hwcomposer)
TEST=built + launch cuttlefish w/ 3D mode (minigbm + drm_hwcomposer)
Change-Id: Ie5b7a6f80f7e0da72a910644ba42d2f34b246be8
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1993913
Commit-Queue: Jason Macnak <natsu@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Lingfeng Yang <lfy@google.com>
Set the backend with null fd can reset the vq in vhost, which
can allow the activate fn to run again.
BUG=None
TEST=launch Crosvm guest with vhost-net. It works fine with iperf test.
TEST=cargo test -p devices
Change-Id: Ida952409147fd6fbd1d8f69b3a88a7ef03051d65
Signed-off-by: Chuanxiao Dong <chuanxiao.dong@intel.corp-partner.google.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2009523
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Adds support for pstore on ARCVM on x86_64.
The backend file of the buffer will be passed via argument of the crosvm.
BUG=b:144962428
TEST=kernel crash on eve-arcvm, check /sys/fs/pstore/console-ramoops-0
Launch crostini manually on eve-arcvm
Change-Id: I29492ac7a9067aa2ae23eb03fbb942ab7dd3aa8d
Signed-off-by: Kansho Nishida <kansho@google.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1973391
Reviewed-by: Keiichi Watanabe <keiichiw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Kansho Nishida <kansho@chromium.org>
The VCPU thread can panic when there is a bug, and this should trigger
an exit in crosvm instead of hanging the VCPU thread forever.
BUG=None
TEST=run crosvm with kernel, trigger a vcpu exit using guest
Change-Id: I1df0e04eda73ad67fec20adeff893f6c00699318
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2029929
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Zach Reizner <zachr@chromium.org>
Commit-Queue: Zach Reizner <zachr@chromium.org>
The original version of this test used sleeps, retries, and vague
commentary about how the test is made reliable. The new version of test
uses real synchronization primitives..
BUG=chromium:1045426
TEST=put all cores under load;
cargo test -p data_model
Change-Id: I7fa4ac45a9003e2ebb98c57ca6a03be17bdf65cf
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2029925
Tested-by: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Auto-Submit: Zach Reizner <zachr@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Zach Reizner <zachr@chromium.org>
The plan is to use shared mem cap for virtio-gpu.
BUG=chromium:924405
TEST=build
Change-Id: Id2829c2cd9883aca19641eff625c65a8db335e7a
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1963334
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Gurchetan Singh <gurchetansingh@chromium.org>
Commit-Queue: Gurchetan Singh <gurchetansingh@chromium.org>
When a non-sparse disk is resized, we should allocate storage for the
newly-expanded space when the disk is grown to maintain the
non-sparseness. To accomplish this, add a call to allocate in the
resize function in the block device.
BUG=chromium:858815
TEST=`crosvm disk resize ...` and verify disk image is fully allocated
Change-Id: If263aa2b5c9da11b8bfc0586e4ac1575f2bd7084
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2015829
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
This trait provides a generic interface for allocating space on the
filesystem within a given file. It is equivalent to the fallocate(2)
system call with the default mode (mode = 0).
BUG=chromium:858815
TEST=cargo build --features=composite-disk
Change-Id: I2f4e8aceb4878790e8dec2e3d539071915efd205
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2015828
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
Don't store the BAR value, as it can potentially be updated by the
guest. (This is not supported by our PCI device model just yet, but this
is still the correct thing to do and matches other crosvm PCI devices.)
BUG=None
TEST=Add USB device on nami
Change-Id: Ie42d08429e7ff124178c818877b4cee83003d66f
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1924782
Reviewed-by: Zach Reizner <zachr@chromium.org>
Add a function offset_from_base() which, given a GuestAddress, determines
the offset of that address within the backing memfd of the GuestMemory.
In other words, this lets you convert a GuestAddress into an offset that
can be understood by another process which has mapped the the memfd and
would like to read from that address.
BUG=chromium:968724
TEST=cargo test
Change-Id: I5b033ad29dd38090f74577c068cc62ee9c6effb6
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2015835
Tested-by: Fletcher Woodruff <fletcherw@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Fletcher Woodruff <fletcherw@chromium.org>
This change adds a CONTRIBUTING.md and some architectural documentation
for people new to submitting code to crosvm.
TEST=check the gittiles markdown
BUG=None
Change-Id: Ib792220ae50329413f487c5d87b29ad3b2f7c59c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2013213
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Commit-Queue: Stephen Barber <smbarber@chromium.org>
Auto-Submit: Zach Reizner <zachr@chromium.org>
Minijail's policy compiler complains when there's multiple
unconditional rules for a syscall. In most cases the rules
are redundant to common_device.policy. I don't know what
to do about the intentionally contradictory rules for open
and openat, other than to remove then from the common device
policy and add it to all the others.
BUG=None
TEST=Ran compile_seccomp_policy.py until it stopped
complaining.
Change-Id: I6813dd1e0b39e975415662bd7de74c25a1be9eb3
Signed-off-by: Matt Delco <delco@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1918607
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Change adds supports for providing pre-compiled bpf files as the policy
file for jailing. In short it's more effient to compile once on the
build machine than each time at runtime. Additionally libminijail's
support for more efficient bpfs (which use a binary tree instead of
a linear search) is currently only available via tools that are based
around pre-compiled use.
BUG=None
TEST=Ran build_test and verified that tests can pass with both bpf and
policy files (though the tests might only exercise the jail for the
plugin).
Change-Id: Idd93e3c802fc79da93850d6bad1db660576bc9ba
Signed-off-by: Matt Delco <delco@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1914416
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
gbm_bo_get_stride_or_tiling has been recently removed, so update
the bindings to reflect this and other changes.
BUG=chromium:1044341
TEST=build
Change-Id: Ieed3045bd05244a582660ecf9340128e8fa10090
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2013763
Reviewed-by: Manoj Gupta <manojgupta@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Manoj Gupta <manojgupta@chromium.org>
This will allow passing in other data sources for the qcow read methods,
without adding extra copies.
TEST=Unit tests
BUG=b:140069322
Change-Id: I2815fa6e416b554968b97959e4b6cd4c93a722f6
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1982829
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Cody Schuffelen <schuffelen@google.com>
As indicated in the comments, it seems that this warning is unnecessary.
We've added explicit handling for the UNSET case, and left the warning
intact to handle any out of range values.
BUG=chromium:1041054
TEST=builds.
Change-Id: I2d41159f2d4ccbb4d75d2a8f4bab54586ec65442
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1995308
Reviewed-by: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Noah Gold <nkgold@google.com>
Auto-Submit: Noah Gold <nkgold@google.com>
vhost set_owner fn only needs to be called once. Put it in activate
fn will block the vhost devices to be activated again in future.
on_device_sandboxed is a good place to put the set_owner as it only
run once. So put it there.
BUG=None
TEST=launch Crosvm guest with vhost-net and vsock. Both of them can work
TEST=cargo test -p devices
Change-Id: I45308e26b026c9141e4426d8b1bbe1944612a915
Signed-off-by: Chuanxiao Dong <chuanxiao.dong@intel.corp-partner.google.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1954173
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Activate_vqs is used to do the queue preparation before really
running. The virtio-vhost device might need to do some cleanup
to allow a second round activate in the future. How to do the
cleanup is depending on how the vhost virtio devices.
Just add an interface called cleanup_vqs to allow the vhost virtio
devices to do their own cleanup stuff.
BUG=None
TEST=launch Crosvm guest with vhost-net and vsock. Both of them can work
TEST=cargo test -p devices
Change-Id: I2472e79a8b63c9336f886cde55ffef6a78008ad8
Signed-off-by: Chuanxiao Dong <chuanxiao.dong@intel.corp-partner.google.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1954172
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
This is used in Rust 1.40.0's libstd in place of stat/fstat; update the
whitelists to allow the new syscall as well.
BUG=chromium:1042461
TEST=`crosvm disk resize` does not trigger seccomp failure
Change-Id: Ia3f0e49ee009547295c7af7412dfb5eb3ac1efcb
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2003685
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
We emulate some hardware now, so this statement isn't accurate.
BUG=none
TEST=none
Change-Id: Id8e0e1189001d5b5fe62e032a28fe797bfd9721b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2007998
Reviewed-by: Zach Reizner <zachr@chromium.org>
Commit-Queue: Stephen Barber <smbarber@chromium.org>
Tested-by: Stephen Barber <smbarber@chromium.org>
The Deref trait is usually only implemented by smart pointers or by
trivial wrappers around the underlying type. MsgSocket does not fit into
either category because it wraps a `UnixSeqPacket` to provide new
functionality. Having it implement can lead to confusing error messages,
especially for people who are new to rust and are not familiar with the
Deref trait and Deref coercion.
For example, calling `sock.send()` on a MsgSocket without first adding
`use msg_socket::MsgSender` leads to the compiler complaining about
mis-matched types for the `send` method. `UnixSeqPacket::send` expects a
`&[u8]` while `MsgSocket::send` expects a `&M`. The compiler also gives
no clues that it is implicitly coercing the socket to a `&UnixSeqPacket`
and using the `send` method from there.
Drop the `Deref` implementation. `MsgSocket` already implements
`AsRef<UniqSeqPacket>` so anything that _needs_ to access the underlying
`UnixSeqPacket` should just use that.
BUG=none
TEST=unit tests
Change-Id: If02ef7173ae21d85d517e808489ed4d6d09ae90b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2002997
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
We are inconsistent in when we print errors to stdout versus strerr and
syslog, with argument parsing errors from "crosvm run" subcommand only
logged to stdout whereas other types of errors going to stederr/syslog.
Let's make sure argument parsing errors will be logged to stderr/syslog as
well, otherwise it is very confusing to analyze crosvm failures when
started by VM concierge as it does not dump crosvm stdout/stderr anywhere.
BUG=None
TEST=Try "crosvm run" with bad arguments when syslog is available,
see error messages in syslog.
Change-Id: Ie7a284f4a604716ecc655c5a38ec2147b55d63a3
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/2002677
Commit-Queue: Dmitry Torokhov <dtor@chromium.org>
Tested-by: Dmitry Torokhov <dtor@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Adds a stub display that emulates a display without actually
displaying contents anywhere.
This is needed for transitioning Cuttlefish to always using minigbm
as its gralloc implementation. Cuttlefish currently uses a custom
gralloc and hwcomposer implementation when running without hardware
acceleration. The Cuttlefish team would like to start with removing
our custom gralloc implementation and use minigbm. For this, we need
to add a virtio 2D backend to crosvm. Our hwcomposer implementation
currenlly sends framebuffers from the guest to the host via sockets.
The gpu backend still requires a display so we need a stub display
to use with the 2D backend for the period of time while we are
either still using our hwcomposer implementation or until our
hwcomposer implementation is updated to use the virtio backend for
display.
BUG=b:123764798
BUG=chromium:1033787
TEST=built and launched with Cuttlefish locally
Change-Id: I1a7e259d914a53252200c59589c4142e76c6b96b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1993947
Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Commit-Queue: Jason Macnak <natsu@google.com>
This allows us to use export a directory to a VM with the
'--shared-dir tag:/dir' crosvm command line flag without relying
on seneschal. The fs device's policy already does the same.
BUG=b:123309049
TEST=Start tot ARCVM, run 'mkdir /var/run/arc/arcvm && mount -t 9p
-o "trans=virtio,version=9p2000.L,cache=none,access=any"
host_generated /var/run/arc/arcvm && ls /var/run/arc/arcvm',
verify ls prints files.
Change-Id: I8f8b265fc8a7de159508afbee5114b6a3f084d01
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1995319
Tested-by: Yusuke Sato <yusukes@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Lepton Wu <lepton@chromium.org>
Reviewed-by: Chirantan Ekbote <chirantan@chromium.org>
Commit-Queue: Yusuke Sato <yusukes@chromium.org>
Add a new disk-specific DiskGetLen trait which uses io::Seek instead of
File::metadata() to determine the length so that it works on raw block
devices (e.g. /dev/sda) as well as regular files.
BUG=b:146811529
TEST=`crosvm run --disk /dev/sda` and verify block device length
Change-Id: I6936863490efaa479a3c8745c75c373748c800a1
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1990855
Reviewed-by: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Trent Begin <tbegin@chromium.org>
Commit-Queue: Daniel Verkamp <dverkamp@chromium.org>
With command "version", we can dump version information via "crosvm version".
By default it would dump the version specified in Cargo.toml like following:
"crosvm package version 0.1.0".
And if the environment varable "PKG_VERSION=123456" is given during building crosvm,
it would dump followed by a package version, like following:
"crosvm package version 0.1.0-123456".
Sometimes, we need to know which exact version does a crosvm binary come
from for developing and testing. It is useful if the git sha is built-in a
crosvm binary.
BUG=none
TEST=PKG_VERSION=xxxxxx Cargo build && crosvm version
TEST=PKG_VERSION=xxxxx emerge-eve crosvm && crosvm version
TEST=./bin/fmt
TEST=./bin/clippy
TEST=./build_test.py --x86_64-sysroot /build/eve
no errors reported and all behavor is as expected.
v2: Refine version info.
Change-Id: I89686dbe6ab2888d8a6ce5752a37241b4c00160d
Signed-off-by: Yi Sun <yi.sun@intel.corp-partner.google.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1989256
Reviewed-by: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
The extra parens crept back in during a recent refactoring.
Change-Id: Iaba13ddea9b7bada09f6079db7e7f8133cbfc896
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1994726
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
Tested-by: Dylan Reid <dgreid@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
The `MsgSender` and `MsgReceiver` traits take a type parameter for the
message to be sent / received. However this ends up trickling down to
every user of these traits, who need to add these type parameters
whenever they want to use the trait.
Change the type parameters to associated types instead. The associated
types keep the same trait bounds but now users of the traits don't need
to care about the exact message being sent / received.
BUG=none
TEST=cargo test
Change-Id: I733a21877cbe49b7904040b8cc6c3436d5e3439f
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1993160
Tested-by: Chirantan Ekbote <chirantan@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Auto-Submit: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Dylan Reid <dgreid@chromium.org>
The only device that used user_command was Serial. This change makes
Serial device use a thread to read from its input instead of using
user_command.
BUG=chromium:1033787
TEST=./build_test
run crosvm with stdio serial with and without sandbox
Change-Id: Ia0f2ee83d94ad2fee3f1f4f89aa734b976e33507
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1966435
Tested-by: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Commit-Queue: Zach Reizner <zachr@chromium.org>
Auto-Submit: Zach Reizner <zachr@chromium.org>
Add a control queue for virtio_net, and implement the command to set
available networking offloads.
Set offloads initially when acking features from the guest. We previously set
offloads on unconditionally.
Add TUNSETOFFLOAD to the allowed ioctls for virtio_net.
BUG=chromium:1031413
TEST=boot 5.4 guest, check vmtap offloads enabled with ethtool
TEST=enable ip_forward in guest, check vmtap offloads disabled with ethtool
Change-Id: I4129aa03419798906bd95cf65a6a4ab63069f50b
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1968200
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Commit-Queue: Stephen Barber <smbarber@chromium.org>
Tested-by: Stephen Barber <smbarber@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
