This change adds an X11 backend to the gpu_display crate. With this
addition, the virtio-gpu device can display to traditional linux
desktops that only have X11 output.
Change-Id: I86c80cac91ca5bdc97588194a44040273ae69385
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1591572
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
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>
In Rust 2018 edition, `extern crate` is no longer required for importing
from other crates. Instead of writing:
extern crate dep;
use dep::Thing;
we write:
use dep::Thing;
In this approach, macros are imported individually from the declaring
crate rather than through #[macro_use]. Before:
#[macro_use]
extern crate sys_util;
After:
use sys_util::{debug, error};
The only place that `extern crate` continues to be required is in
importing the compiler's proc_macro API into a procedural macro crate.
This will hopefully be fixed in a future Rust release.
extern crate proc_macro;
TEST=cargo check
TEST=cargo check --all-features
TEST=cargo check --target aarch64-unknown-linux-gnu
TEST=local kokoro
Change-Id: I0b43768c0d81f2a250b1959fb97ba35cbac56293
Reviewed-on: https://chromium-review.googlesource.com/1565302
Commit-Ready: David Tolnay <dtolnay@chromium.org>
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 Tolnay <dtolnay@chromium.org>
Macros were previously imported through `#[macro_use] extern crate`,
which is basically a glob import of all macros from the crate. As of
2018 edition of Rust, `extern crate` is no longer required and macros
are imported individually like any other item from a dependency. This CL
fills in all the appropriate macro imports that will allow us to remove
our use of `extern crate` in a subsequent CL.
TEST=cargo check --all-features --tests
TEST=kokoro
Change-Id: If2ec08b06b743abf5f62677c6a9927c3d5d90a54
Reviewed-on: https://chromium-review.googlesource.com/1565546
Commit-Ready: David Tolnay <dtolnay@chromium.org>
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 Tolnay <dtolnay@chromium.org>
Separated out of CL:1513058 to make it possible to land parts
individually while the affected crate has no other significant CLs
pending. This avoids repeatedly introducing non-textual conflicts with
new code that adds `use` statements.
TEST=cargo check
TEST=cargo check --all-features
TEST=cargo check --target aarch64-unknown-linux-gnu
Change-Id: I290fc72e5624cf8b4b2bacaf124cc5b654255978
Reviewed-on: https://chromium-review.googlesource.com/1519696
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Tested-by: David Tolnay <dtolnay@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: David Tolnay <dtolnay@chromium.org>
This is an easy step toward adopting 2018 edition eventually, and will
make any future CL that sets `edition = "2018"` this much smaller.
The module system changes in Rust 2018 are described here:
https://doc.rust-lang.org/edition-guide/rust-2018/module-system/path-clarity.html
Generated by running:
cargo fix --edition --all
in each workspace, followed by bin/fmt.
TEST=cargo check
TEST=cargo check --all-features
TEST=cargo check --target aarch64-unknown-linux-gnu
Change-Id: I000ab5e69d69aa222c272fae899464bbaf65f6d8
Reviewed-on: https://chromium-review.googlesource.com/1513054
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 Tolnay <dtolnay@chromium.org>
The description method is deprecated and its signature forces less
helpful error messages than what Display can provide.
BUG=none
TEST=cargo check --all-features
TEST=cargo check --target aarch64-unknown-linux-gnu
Change-Id: I27fc99d59d0ef457c5273dc53e4c563ef439c2c0
Reviewed-on: https://chromium-review.googlesource.com/1497735
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>
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>
We updated the production toolchain from 1.30 to 1.31 in CL:1366446.
This CL does the same upgrade for the local developer toolchain and
Kokoro.
The relevant changes are in rust-toolchain and kokoro/Dockerfile.
The rest are from rustfmt.
TEST=cargo fmt --all -- --check
TEST=as described in kokoro/README.md
Change-Id: I3b4913f3e237baa36c664b4953be360c09efffd4
Reviewed-on: https://chromium-review.googlesource.com/1374376
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: David Tolnay <dtolnay@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Hopefully the changes are self-explanatory and uncontroversial. This
eliminates much of the noise from `cargo clippy` and, for my purposes,
gives me a reasonable way to use it as a tool when writing and reviewing
code.
Here is the Clippy invocation I was using:
cargo +nightly clippy -- -W clippy::correctness -A renamed_and_removed_lints -Aclippy::{blacklisted_name,borrowed_box,cast_lossless,cast_ptr_alignment,enum_variant_names,identity_op,if_same_then_else,mut_from_ref,needless_pass_by_value,new_without_default,new_without_default_derive,or_fun_call,ptr_arg,should_implement_trait,single_match,too_many_arguments,trivially_copy_pass_by_ref,unreadable_literal,unsafe_vector_initialization,useless_transmute}
TEST=cargo check --features wl-dmabuf,gpu,usb-emulation
TEST=boot linux
Change-Id: I55eb1b4a72beb2f762480e3333a921909314a0a2
Reviewed-on: https://chromium-review.googlesource.com/1356911
Commit-Ready: David Tolnay <dtolnay@chromium.org>
Tested-by: David Tolnay <dtolnay@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Now that cargo fmt has landed, run it over everything at once to bring
rust source to the standard formatting.
TEST=cargo test
BUG=None
Change-Id: Ic95a48725e5a40dcbd33ba6d5aef2bd01e91865b
Reviewed-on: https://chromium-review.googlesource.com/1259287
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>
The original methods for reading and writing to GPU buffers naively
assumed that the mappings returned by GBM were to the first byte in the
buffer. In fact, the returned mapping is to the first pixel of the
mapped rectangle. This would lead to segaults when the copy routine
would breeze past the end of the mapping into segault territory.
This change fixes the read and write algorithms and adds lots more guard
rails in to prevent future undefined behavior (hopefully).
TEST=boot kernel with VT and VIRTIO_GPU
BUG=None
Change-Id: Ia7c968b6dd274551b6d218e2f0b255af6e55bd35
Reviewed-on: https://chromium-review.googlesource.com/1102110
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Multi-plane DMABufs are useful for efficient video playback. The
guest can already use this but has to guess the stride and offsets
for the second and third plane as they are not passed by virtwl
to the guest kernel.
This extracts the correct strides and offsets for each buffer and
passes them back to the guest in the allocation response message.
BUG=chromium:837209
TEST=sommelier can use nv12 buffers without guessing stride/offset
Change-Id: I36ae2fad6605293c907802121676296cbc607a57
Reviewed-on: https://chromium-review.googlesource.com/1070799
Commit-Ready: David Reveman <reveman@chromium.org>
Tested-by: David Reveman <reveman@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
name/date/desc_len fields of drm_version struct are of type __kernel_size_t
and not unsigned long long.
BUG=chromium:837209
TEST=crosvm finds DRM device on kevin
Change-Id: If940b31cb730cbaa46ed781021cbe60189da9f65
Reviewed-on: https://chromium-review.googlesource.com/1064913
Commit-Ready: David Reveman <reveman@chromium.org>
Tested-by: David Reveman <reveman@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
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>
These bindings are needed to allocate dmabufs that will be used for
accelerated rendering and zero-copy virtio-wayland support.
TEST=cargo test -p gpu_buffer
BUG=chromium:837073
Change-Id: I96d7bcdeaa1eda616a25fdcfedcbb734cd585ae7
Reviewed-on: https://chromium-review.googlesource.com/1029410
Commit-Ready: David Reveman <reveman@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
