The get_type and get_direction helpers return Options, even though
they can only possibly return a non-None value; all bit patterns of the
fields they are interpreting are defined. Drop the Options and return
the enum values directly to simplify callers and remove dead code.
Fix up a typo ("recipienet" -> "recipient") while we're in the
neighborhood.
BUG=chromium:831850
TEST=Test adb in Crostini
Change-Id: Ie26a1ed1c15f5f17b5ae80be78ce5f8ff51fab28
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1593713
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>
The device to host and host to device branches of HostDevice's
handle_control_transfer function are basically identical, differing only
in whether to do a read or write and when to do it. Split this code out
into its own function, execute_control_transfer, to reduce code
duplication and prepare for future changes.
BUG=chromium:831850
TEST=Test adb in crostini
Change-Id: Ic659f18ca97e2c1c71f67f3543096fe69228969a
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1593712
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>
Rather than acquiring the lock twice, lock it once and hold it while
doing the check and potential follow-up call to interrupt(). This looks
like it could be a race to me, but I don't know if it can actually cause
problems in practice. In any case, it's better to only acquire the lock
once.
BUG=chromium:831850
TEST=Test adb in Crostini
Change-Id: Id7aa76e543cd5b858faf128f516e8d63e27cf3e7
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1592579
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>
Set the name of the thread created to run the Xhci controller event loop
so that it can be identified more easily in a debugger.
BUG=None
TEST=Attach to running crosvm with gdb and verify 'info threads' name
Change-Id: Id73a580b35231ec7fa7aec5bd51027d32e483bff
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1594192
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>
Always build the device tree, even if the Android fstab isn't specified.
Device tree is always required for Arm boards, unlike x86, where the
device tree is only needed for Android booting.
BUG=chromium:959921
TEST=Start Crostini on kevin
Change-Id: Ib775511786286200f4bfa360f9675a59451bb048
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1597348
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
Reviewed-by: Greg Hartman <ghartman@google.com>
The UsbHub::try_detach function, which is only called from the libusb
hotplug callback when devices are removed, calls into
port.get_backend_device(), which acquires the backend_device lock, and
then calls port.detach(), which also tries to acquire the backend_device
lock, while still holding onto the backend_device. This clearly leads to
a deadlock.
Add an extra block in try_detach to keep the backend_device lock scoped
so that it is dropped before calling port.detach().
BUG=chromium:958117
TEST=Hot remove usb device from Crostini; verify it is gone in lsusb
Change-Id: Ibbbf68623390e3d25576f544b815c2a5607934fc
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/1594158
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
1. Removed for device slot reset and evaluate context. The verification was
unnecessary and may cause some guest kernel operations to fail.
2. The context was updated after dequeue pointer set
3. Reset device when it's attached.
4. Add seccomp rules to allow the above reset.
The verification was copied from another implementation which works for
adb, but does not work with serial devices. The verification is also not
part of the spec, so we removed it here.
BUG=b:131336977
TEST=local build and test
Change-Id: Ifd7994ff5512346d1bab27654e60c97a602da8a6
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Signed-off-by: Zach Reizner <zachr@google.com>
Reviewed-on: https://chromium-review.googlesource.com/1558934
Tested-by: kokoro <noreply+kokoro@google.com>
We're changing the content of the low_mem margin file to handle
multiple values to support notification for multiple memory pressure
levels. The values will be from most critical to least, so we need to
handle this by fetching the first value.
BUG=chromium:736538
TEST=run vm.CrostiniStartEverything with and put memory pressure on the system
Change-Id: I0278ed492ddda1594d53750e0d4024a878210c9f
Reviewed-on: https://chromium-review.googlesource.com/1584644
Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Renames field memory_mb to memory_size. All usages of this
field treat it as a memory size in bytes, not megabytes.
BUG=None
TEST=cargo check
TEST=cargo check --package aarch64 --target aarch64-unknown-linux-gnu
Change-Id: I7b1aefe4f0b612d5eeb2987dc2a0fce6db0dd228
Reviewed-on: https://chromium-review.googlesource.com/1585617
Commit-Ready: Jakub Staroń <jstaron@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Originally, crosvm would list details about an attached usb device for a
given port. This change allows getting details about multiple ports at
once. This is intended to simplify command line usage and downstream
consumers like concierge.
TEST=various vmc commands
Chrome UI for handling USB devices
BUG=chromium:831850
Change-Id: I55681a7fea7425c897a22a579dcc15567683ef54
Reviewed-on: https://chromium-review.googlesource.com/1529765
Commit-Ready: Zach Reizner <zachr@chromium.org>
Tested-by: Zach Reizner <zachr@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Extracts BalloonAdjust from VmRequest into BalloonControlCommand.
BUG=None
TEST=cargo test
TEST=cargo test --package msg_socket
TEST=cargo test --package devices
TEST=cargo test --package vm_control
TEST=tast -verbose run ${IP} vm.CrostiniStartEverything
Change-Id: Ia9f5778c37c8fd4fa560df413134d1b441142f64
Reviewed-on: https://chromium-review.googlesource.com/1565298
Commit-Ready: Jakub Staroń <jstaron@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Stephen Barber <smbarber@chromium.org>
A few files were missing license blurbs at the top, so update them all
to include them.
BUG=none
TEST=none
Change-Id: Ida101be2e5c255b8cffeb15f5b93f63bfd1b130b
Reviewed-on: https://chromium-review.googlesource.com/1577900
Commit-Ready: Stephen Barber <smbarber@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Only clear signal when EINTR is indicated, rather than doing it after
each attempt to run the VM.
BUG=None
TEST=Local compile. Ran my diagnostic plugin and confirmed that pause
can still be trigger. Ran my benchmarking plugin and saw the time used
decrease by about 13%. The net reduction with 2 other changes is about
42%.
Change-Id: I118e05c6c62d1251946dd6432d4c933a3b8504fc
Signed-off-by: Matt Delco <delco@google.com>
Reviewed-on: https://chromium-review.googlesource.com/1573219
Commit-Ready: Matt Delco <delco@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Pipes have better performance than sockets, so switch the vcpu
communication over to pipes. The vm communication channels will
continue to use sockets since that communication isn't performance
critical (and those messages sometimes exchange file descriptors, and
that functionality requires sockets).
TEST=local compile and confirmed that my diagnostic plugin is still
happy. The time it takes to run my benchmark plugin has decreased by
20%. This combined with my prior commit results in a net wall-clock
time reduction of 32%.
BUG=None
Change-Id: I44c198d62a3bbe3b539ff6ac79707d02488876e3
Signed-off-by: Matt Delco <delco@google.com>
Reviewed-on: https://chromium-review.googlesource.com/1572873
Commit-Ready: Matt Delco <delco@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
This change helps to improve performance in plugin communications by
removing unnecessary communication exchange.
The existing protocol basically requires the plugin to send a request
msg and wait for a reply msg. Prior to this change a plugin had to send
a wait request before it got a wait reply (which typically contains an IO
event notication). Similarly, when the plugin sends a resume request
there's also a resume reply that's sent.
The reply to the resume message serves no worthwhile purpose and can be
removed. In the common case there's also no need for the plugin to send
a wait request message--the prior operation was a resume so both sides
know that the only next legal operation is a wait. Thereforce, crosvm
can send a wait reply message without waiting for the plugin's request.
Another way to look at the situation is that a resume request message is
now answered by a wait reply message, and the overall message exchange
pattern looks less like http and more like async I/O.
The plugin's first call to wait is the one time that a wait request is
sent. This in turn will receive an wait-init reply.
TEST=Ran my diagnostic plugin and confirmed that it still passes (after
working around an 8-byte limitation in crosvm). Run my benchmarking
plugin and observed the time it takes to complete go down by 16.5%.
BUG=None
Change-Id: I9c93ba1d3a8f7814ca952f3dc7239d48675192e2
Signed-off-by: Matt Delco <delco@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1571066
Tested-by: kokoro <noreply+kokoro@google.com>
Tested-by: Matt Delco <delco@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
The device memory SystemAllocator allocates device addresses past the
end of physical memory. If a device tries to actually use this address
to register a new PCI BAR, the kernel will fail with a "can't claim BAR,
no compatible bridge window" error. On ARM, the kernel must be informed
of where PCI bars are allowed to be allocated through the Device Tree.
This CL adds a new PCI memory region to the fdt for device memory.
BUG=chromium:936567
TEST=see CL:1493014. Run on ARM.
Change-Id: I0faa6f7082ae53f7a792cec53a21adba109bc00d
Reviewed-on: https://chromium-review.googlesource.com/1558940
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
The current error doesn't provide sufficient information to debug
InvalidRange errors; add the size of the region so that the bounds of
the comparison can be determined from the error message.
BUG=None
TEST=cargo test -p sys_util
Change-Id: I8e7fbd750ab84c43bbf0435230b7d3cf466783da
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1574964
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>
Fix up the Display impl for ExecuteError so that it's clear which
direction data is moving for the Read and Write variants.
BUG=None
TEST=cargo build
Change-Id: Ide4ea5cb453e4d7f6bd2812a1696df96daec511b
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1574963
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>
Add capture support in AC'97 PCI device. Only capture at 48kHz is
supported.
BUG=chromium:932268
TEST=cargo test -p device start_capture
TEST=Run crosvm with `--cras-audio` option to run a guest vm then test
audio capture by command
$ arecord -D hw:0,0 -r 48000 -f dat -c 2 /tmp/test.raw
Change-Id: Ie3aab1004695f0df607fef8fc337fa58cb723b65
Reviewed-on: https://chromium-review.googlesource.com/1573600
Commit-Ready: Chih-Yang Hsia <paulhsia@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
AddressAllocator now maintains a HashMap<Alloc, (u64, u64, u64)>,
which uniquely maps a Allocation enum (e.g: PciBar(bus, dev, bar),
GpuRenderNode, etc...) to it's address, size, and human-readable tag
/ description.
The interface has also been modified to use Error instead of Option.
Aside from improving debugging, tracking allocations will have
numerous uses in the future. For example, when allocating guest memory
over VmControl sockets, it will be possible to restrict allocations to
pre-allocated slices of memory owned by the requesting device.
To plumb through PCI information to PCI devices, this CL necessitated
the addition of a PciDevice method called `assign_bus_dev`, which
notifies PCI devices of their uniquely assigned Bus and Device numbers.
BUG=chromium:936567
TEST=cargo test -p resources && cargo build --features="gpu gpu-forward"
Change-Id: I8b4b0e32c6f3168138739249ede53d03143ee5c3
Reviewed-on: https://chromium-review.googlesource.com/1536207
Commit-Ready: Daniel Prilik <prilik@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Fixes a warning:
warning: use of deprecated item 'std::sync::atomic::ATOMIC_BOOL_INIT':
the `new` function is now preferred
BUG=None
TEST=emerge-nami crosvm
Change-Id: Ic2c7d07fc87c80c853a5d47e37b6fd32a5ce6dd4
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1573245
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>
Cargo 1.34.0 insists on adding a header comment to Cargo.lock on each
invocation to indicate that the file is not meant to be edited by hand.
Add the header to our checked-in copy of Cargo.lock so it doesn't
continually dirty the working copy.
BUG=None
TEST=cargo build
Change-Id: I2ef10bfd997a9a1f7d4928467daa830d227cf165
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1568829
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>
SMBIOS allows to pass down system information from the BIOS to the OS.
Its information is used on Linux to construct modalias entries for the
system in order to facilite module autoloading on specific hardware.
Adding it also allows package management software to target specific
packages when crosvm is used as the hypervisor (e.g. to pre-install
the helper daemons or a special vTPM driver).
This change has only been tested with Linux and implements the bare
minimum necessary to make a crosvm hypervisor detectable through DMI
data. As such it also skips over some required structures like BIOS
information that do not technically apply. The result is a hodgepodge
of standards: SMBIOS 3.0 provides a convenient 64-bit entrypoint
that we implement. However the structures are cut short to SMBIOS 2.0
standards as most of the fields are skipped. Linux deals just fine
with this, although some of the dmi/id files in sysfs will be empty
as a result.
The resulting modalias looks like this:
dmi:bvncrosvm:bvr0:bd:svnChromiumOS:pncrosvm:pvr:
The kernel prints this as part of startup:
SMBIOS 3.2.0 present.
DMI: ChromiumOS crosvm, BIOS 0
And for oops/panic:
Hardware name: ChromiumOS crosvm, BIOS 0
dmidecode's view on the tables (which uses its own parser):
Getting SMBIOS data from sysfs.
SMBIOS 3.2.0 present.
Table at 0x000F0018.
Handle 0x0001, DMI type 0, 20 bytes
BIOS Information
Vendor: crosvm
Version: 0
Release Date: Not Specified
ROM Size: 64 kB
Characteristics:
PCI is supported
System is a virtual machine
Handle 0x0002, DMI type 1, 27 bytes
System Information
Manufacturer: ChromiumOS
Product Name: crosvm
Version: Not Specified
Serial Number: Not Specified
UUID: Not Settable
Wake-up Type: Reserved
SKU Number: Not Specified
Family: Not Specified
TEST=cargo test
Change-Id: Ie27105711a9bc14941d387b720da350349dff265
Reviewed-on: https://chromium-review.googlesource.com/1571565
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: Daniel Verkamp <dverkamp@chromium.org>
This CL fixes four cases of what I believe are undefined behavior:
- In vhost where the original code allocates a Vec<u8> with 1-byte
alignment and casts the Vec's data pointer to a &mut vhost_memory
which is required to be 8-byte aligned. Underaligned references of
type &T or &mut T are always undefined behavior in Rust.
- Same pattern in x86_64.
- Same pattern in plugin::vcpu.
- Code in crosvm_plugin that dereferences a potentially underaligned
pointer. This is always undefined behavior in Rust.
TEST=bin/clippy
TEST=cargo test sys_util
Change-Id: I926f17b1fe022a798f69d738f9990d548f40c59b
Reviewed-on: https://chromium-review.googlesource.com/1566736
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>
As described in:
https://doc.rust-lang.org/edition-guide/rust-2018/ownership-and-lifetimes/default-match-bindings.html
which also covers the new mental model that the Rust Book will use for
teaching binding modes and has been found to be more friendly for both
beginners and experienced users.
Before:
match *opt {
Some(ref v) => ...,
None => ...,
}
After:
match opt {
Some(v) => ...,
None => ...,
}
TEST=cargo check --all-features
TEST=local kokoro
Change-Id: I3c5800a9be36aaf5d3290ae3bd3116f699cb00b7
Reviewed-on: https://chromium-review.googlesource.com/1566669
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>
Protoc_rust emits this into every file it generates:
#![cfg_attr(feature = "cargo-clippy", allow(clippy))]
which is the old style of tool attribute. It is deprecated in favor of
actual tool attributes that stabilized in rust 1.31.
#![allow(clippy::all)]
Without this PR, the warning when running bin/clippy looks like:
warning: lint name `clippy` is deprecated and may not have an effect in the future.
--> /chromiumos/src/platform/crosvm/target/debug/build/protos/out/trunks/interface.rs:6:10
|
6 | #![cfg_attr(feature = "cargo-clippy", allow(clippy))]
| ^^^^^^
|
= note: #[warn(renamed_and_removed_lints)] on by default
TEST=bin/clippy
Change-Id: I1a484379a8f53d76d3667590cd8458588492d2b1
Reviewed-on: https://chromium-review.googlesource.com/1567849
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>
Still TODO: Interrupt routing (and tests for that).
BUG=chromium:908689
TEST=Unit tests in file. Integration testing is blocked on rest of split-irqchip being implemented.
Change-Id: I08c187c44e49889ffc47322ede0f1223c6265757
Reviewed-on: https://chromium-review.googlesource.com/1565306
Commit-Ready: Miriam Zimmerman <mutexlox@chromium.org>
Tested-by: Miriam Zimmerman <mutexlox@chromium.org>
Reviewed-by: David Tolnay <dtolnay@chromium.org>
AddressRanges' name doesn't suggest that it's a SystemAllocator builder.
This CL renames it to SystemAllocatorBuilder, and adds a
SystemAllocator::builder() that removes the need to have a separate
import for the Builder.
A minor change, but it cleans up the interface a bit.
BUG=chromium:936567
TEST=cargo test -p resources && cargo build
Change-Id: I6d14368490c0d3c4018858f541e4ae5390995878
Reviewed-on: https://chromium-review.googlesource.com/1540398
Commit-Ready: Daniel Prilik <prilik@google.com>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Zach Reizner <zachr@chromium.org>
Only allocate using minigbm if scanout bind is request (which can
indicate that the buffer is to be shared until a proper virgl bind flag
for shared is available), but if that fails because the format is not
supported for scanout, retry the minigbm allocation with the scanout
flag.
BUG=chromium:945033
TEST=None
Change-Id: Ib99bf01c8b9c2a98b1c0d1a8592d5f7c6e1aa859
Reviewed-on: https://chromium-review.googlesource.com/1569025
Commit-Ready: David Riley <davidriley@chromium.org>
Tested-by: David Riley <davidriley@chromium.org>
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-by: Zach Reizner <zachr@chromium.org>
We have:
unsafe trait AlignedNew: Sized + DataInit {...}
unsafe trait DataInit: Copy + Send + Sync {...}
trait Copy: Clone {...}
trait Clone: Sized {...}
Since Sized is already indirectly a supertrait of DataInit, including it
again as a supertrait of AlignedNew has no effect. This CL removes the
redundant Sized bound.
TEST=cargo check
Change-Id: I8ee2a9ee8892c95e6b0dd4bac1b662cd97441984
Reviewed-on: https://chromium-review.googlesource.com/1568077
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>
Before the new borrow checker in the 2018 edition, we sometimes used to
have to manually insert curly braced blocks to limit the scope of
borrows. These are no longer needed.
Details in:
https://doc.rust-lang.org/edition-guide/rust-2018/ownership-and-lifetimes/non-lexical-lifetimes.html
TEST=cargo check --all-features
TEST=local kokoro
Change-Id: I59f9f98dcc03c8790c53e080a527ad9b68c8d6f3
Reviewed-on: https://chromium-review.googlesource.com/1568075
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>
